GEODATASPECIFIKATION. Byggnad. Version Markanvändning och Marktäcke. Vatten. Bild. Väg och Järnväg Byggnad Adress Stompunkter

Transkript

1 GEODATASPECIFIKATION Byggnad Version Bild Vatten Markanvändning och Marktäcke Markdetaljer Höjd Väg och Järnväg Byggnad Adress Stompunkter

2 Styrgruppen 2 (145) UPPHOVSMAN DOKUMENTANSVARIG Maria Andersson Tema Byggnad DOKUMENTNUMMER DOKUMENTDATUM BETECKNING Dnr /3027 VERSION FASTSTÄLLD VERSION DOKUMENTDATUM ÄNDRING NAMN Grundversion framtagen Uppdragsledare Geodataspecifikation: Ulrika Roos, Lantmäteriet Maria Andersson, Lantmäteriet Uppdragsledare Samverkansprocess: Linn Varhaugvik, Lantmäteriet Arbetsgrupp: Jerry Sandin, Borås kommun Per Larsson, Nyköpings kommun Emma Kjernald, Göteborgs stad Jan Karlsson, Hässleholms kommun Josefina Persson, Hässleholms kommun Marcus Josefsson, Gislaveds kommun Marie Malmberg, Falu kommun Patrik Johansson, Eskilstuna kommun Allan Almqvist, Malmö stad Britt-Marie Eriksson, Lantmäteriet Jimmy Svensson, Lantmäteriet Madeleine Bergvall, Lantmäteriet Terese Domesjö, Lantmäteriet Karin Ericsson, Lantmäteriet Magnus Linnér, Lantmäteriet Slutversion från projektet Svensk geoprocess. Maria Andersson, Lantmäteriet Geodataspecifikationerna i version är resultat från projektet. Specifikationerna är testade och harmoniserade med hjälp av framtagna datautbytesmodeller (XML-scheman) och exempel (XML). XML-scheman finns tillgängliga för tester på hemsida Projektet avslutade juni 2016 och Samverkan ansvarar nu för förvaltning och vidareutveckling av geodataspecifikationerna. Inför version 3.0 kommer under hösten pilotinföranden och fortsatta tester att genomföras, vilket kan komma att påverka innehållet i geodatasspecifikationerna.

3 3 (145) Styrgruppen Bakgrund I samverkansprojektet utarbetas geodataspecifikationer för nio utvalda geodatateman. Målet med arbetet är att kunna leverera enhetliga geodata oavsett administrativa gränser, vilket bidrar till enklare och effektivare myndighetsutövning för till exempel planarbete, fastighetsbildning och bygglovshantering, miljö- och krisarbete samt infrastrukturbyggande. Figur 1 Enhetliga geodata bidrar till enklare myndighetsservice. Arbetet med att utforma och förvalta specifikationerna bedrivs i samverkan mellan kommuner, Lantmäteriet och för temat andra berörda myndigheter. Specifikationerna baseras i stort på standarden SS-EN ISO 19131:2008, Geografisk information Specifikation av datamängder även om avsteg görs. Specifikationerna utnyttjar både internationella och svenska standarder samt är i möjligaste mån överensstämmande med Inspire:s dataspecifikationer för motsvarande geodatateman. Introduktion till Geodataspecifikation Byggnad Geodataspecifikationen för Byggnad är ett dokument som tagits fram i samverkan mellan Sveriges Kommuner och Landsting (SKL), Lantmäteriet och kommunerna. Specifikationen innehåller informationsmodell och krav på geodata som beskriver Byggnad. Geodataspecifikationen skildrar tillsammans med processbeskrivningen ett framtida scenario av temat Byggnad och ett arbetsflöde där flera aktörer samverkar för att effektivisera samhällsbyggnadsprocessen (processbeskrivningen innehåller en redogörelse av hur samverkan kring insamling, lagring och tillhandahållande ska gå till och tas också fram inom ). Med byggnad avses varaktiga konstruktioner som består av tak eller av tak och väggar och som är varaktigt placerad på mark eller helt eller delvis under mark eller är varaktigt placerad på en viss plats i vatten samt är avsedd att vara konstruerad så att människor kan uppehålla sig i den. Dessa byggnader påverkar processer inom samhällsbyggnadsområdet, t.ex. detaljplanering och bygglov.

4 4 (145) Styrgruppen Geodataspecifikationen avser de geodata om byggnad som Lantmäteriet och kommunerna samlar in, lagrar och tillhandahåller. Specifikationen för Byggnad ska, tillsammans med andra datamängder möjliggöra en s.k. baskarta. Baskartan ska utgöra en grund för framställning av kommunens olika kartprodukter. Objekt beskrivna i specifikationen kan även ingå i andra typer av kommunala produkter. Figur 2 bidrar med geodatateman till Samhällsbyggnadskartor. Byggnadsdatas beståndsdelar läses enklast ur avsnitt 5 som innehåller både en informationsmodell (grafisk beskrivning i UML, Unified Modelling Language) samt en objekttypskatalog med ingående objekttyper (klasser), deras attribut och relationer till andra objekttyper. Vilka objekttyper och attribut som är obligatoriska eller frivilliga framgår av informationsmodellen. Både en informationsmodell och en objekttypskatalog ökar möjligheterna att fler tänkta användare ska kunna förstå Byggnadsdatas informationsmodell. Informationsmodellen kan ses som en avgränsning av vilka naturliga företeelser som ingår i temat. Som ett komplement till denna avgränsning så finns i specifikationen även illustrationer av andra närliggande företeelser som identifierats i arbetet med specifikationen. I den mån de närliggande företeelserna omfattas av andra teman inom går detta att utläsa. I de fall de närliggande företeelserna inte omfattas av andra teman inom så är de dokumenterade och förslag på informationsansvariga aktörer pekas ut. Informationsmodellen är i stor utsträckning baserad på: Kommunala processer Informationsutbytesmodell som används i ABT-samverkan Inspire D2.8III.2 Data specifications on buildings technical guidelines Inspire - Tillägg till genomförandebestämmelser gällande datamängders och datatjänsters interoperabilitet OGC-standarden CityGML Projektet Nationella geodata i 3D Plan och Bygglagen (PBL)

5 5 (145) Styrgruppen Standardisering, t.ex. SIS-TS :2014 Specifikationer, informationsmodeller och XML-scheman som tas fram i är tänkta att kunna användas för utbyte av geodata i många olika sammanhang. Detta medför att de i mångt och mycket har karaktären av en bruttolista av allt som kan tänkas utbytas enligt specifikationernas teman. Verksamhetsregler som i många fall kan ses som tekniska realiseringar av avtal eller överenskommelser är inte en del av då det skulle begränsa möjliga användningsområden för specifikationer med mera. Detta innebär dock att man i många fall kommer att behöva göra begränsningar av vad ur specifikationer som får utbytas och tydligare regler kring hur detta ska ske. Visar det sig att samma begränsningar och striktare regler kring utbyte återkommer i många fall nationellt sett så är det en fråga för Samverkan att besluta om dessa begränsningar och striktare regler ska införlivas i specifikationer, informationsmodeller och XML-scheman. Krav på data enligt denna specifikation uttrycks i respektive tillämpligt avsnitt av specifikationen. Krav skrivs på egen rad med fet stil i röd färg undantaget datakvalitetskrav. Rekommendationer skrivs på egen rad med fet stil i blå färg. Datakvalitetskrav uttrycks i tabellform enligt den internationella datakvalitetsstandarden SS-EN ISO 19157:2013, Geografisk information Datakvalitet under avsnitt 7 i geodataspecifikationen. Denna geodataspecifikation är tillgänglig som ett dokument (.pdf) från

6 Styrgruppen 6 (145) Innehållsförteckning 1 GEODATASPECIFIKATIONENS OMFATTNING 8 2 ÖVERSIKT 8 3 BYGGNADSDATAS OMFATTNINGAR 16 4 IDENTIFIERING AV BYGGNADSDATA 21 5 DATAINNEHÅLL OCH STRUKTUR 22 6 REFERENSSYSTEM 67 7 KVALITETSKRAV 69 8 METADATA 71 9 TILLHANDAHÅLLANDE DATAFÅNGST OCH AJOURHÅLLNING PRESENTATIONSREGLER ÖVRIG INFORMATION REFERENSER BILAGOR Bilaga A. Test av specifikationsuppfyllelse Bilaga B. av UML för informationsmodeller Bilaga C. Fullständig informationsmodell Bilaga D. Kodlistor Byggnadsändamål Bilaga E. på olika samverkansformer 89

7 Styrgruppen 7 (145) 14.5 Bilaga F. Krav och rekommendationer Bilaga G. Objekttypskatalog 94

8 8 (145) Styrgruppen 1 Geodataspecifikationens omfattning Detta dokument utgör en gemensam geodataspecifikation för Byggnad som framställts på uppdrag av Lantmäteriet och kommunerna. Specifikationen omfattar grundläggande geografiska data om byggnader som tillsammans med andra data (beskrivna inom eller utanför ) ska kunna utgöra ett underlag för användning inom statlig, kommunal och privat verksamhet där man behöver uppgifter om enskilda byggnader. 2 Översikt 2.1 Information om geodataspecifikationen Titel Geodataspecifikation Byggnad Datum Ansvarig part Lantmäteriet i samverkan med kommuner och SKL Lantmäteriet, Division Geodata, enheten Geografisk information Adress Gävle Telefon E-post URL specifikationer@lm.se Språk Svenska Ämnesområde Syfte 017 Byggnader och byggnadskonstruktioner Ämnesområde ur den nationella metadataprofilen (tabell 33) Specifikation av de nationella krav som ställs på utbyte av Byggnadsdata mellan kommuner och LantmäterietUtbyte kan avse både från producent till datalager eller från datalager till användare. på olika samverkansformer: 1. Inom en kommun 2. Inom Lantmäteriet 3. Flera kommuner i samverkan i kommunkluster 4. Kommuner och Lantmäteriet i samverkan 5. Kommuner och infrastrukturbyggare i samverkan I bilaga E redovisas de olika samverkansformerna för datautbyte mer detaljerat. Med utbyte avses utbyte av information

9 9 (145) Styrgruppen om byggnader samt associerade objekttyper. I ett separat dokument beskrivs framtida samverkansprocessen mellan Lantmäteriet och kommunerna. Denna geodataspecifikation riktar sig i första hand till dataproducenter, systemleverantörer och systemutvecklare som ansvarar för att utbyta datamängder. Geodataspecifikationen ska också kunna vara ett stöd för användare av data i att få större förståelse för framförallt levererade datamängders användbarhet. Informationsmodellerna i kap 5 erbjuder ett snabbt sätt att se huvudelementen i specifikationen och deras relationer. Fullständig informationsmodell finns i bilaga C. Informationsmodellen ska ses som en bruttomodell som innehåller grundläggande information om byggnader som Lantmäteriet och kommunerna hanterar. För respektive samverkansform finns en datautbytesmodell som innehåller den del av bruttoinformationen som hanteras i just det utbytet. Aggregerad byggnadsinformation kan redovisas som Bebyggelseområden som ingår i temat Markanvändning/Marktäcke. Byggnadsverk som inte räknas som byggnader ingår i temat Markdetaljer (t.ex. master). DPS:en utgår från den informationsmodell som används i datautbytet mellan kommunerna och Lantmäteriet i ABT-samverkan. Kompletteringar är gjorda bl.a. med fler attribut på byggnad och byggnadsdel, byggnadstillbehör och geometrisk representation i 3D. Förutom anpassning till behoven i har fakta hämtats från Inspires Data specification on Buildings v3.0 som i sin tur bygger på CityGML. Eftersom CityGML baseras på ISO TC 211 och OGC-koncept så är det en naturlig kandidat för modellering av 3D-byggnader Termer och beskrivningar Termerna är uppdelade i två tabeller. Tabell 1 beskriver termer från denna specifikation, Tabell 2 innehåller generella termer som används i flera specifikationer. Källa om annan än anges inom parentes efter beskrivning. Objekttyper med attribut beskrivs i bilaga G. Med 3D-uppdraget avses rapporten Förutsättningar för att tillhandahålla kart- och bildinformation i tre dimensioner UML-specifika termer och vissa modelleringstekniska termer beskrivs i 14.2 Bilaga B.

10 Styrgruppen 10 (145) Tabell 1. Temaspecifika termer Byggnad Termer ur Geodataspecifikation Byggnad 2D-data Punkter, linjer och ytor som endast har plana koordinater. (3D-uppdraget) 2,5-data Punkter, linjer och ytor som endast har ett höjdvärde per plan-koordinat (3D-uppdraget) 3D-data Samlingsbegrepp för geografisk informations som hanterar höjder tillsammans med plankoordinater, t.ex. 2,5-data, 3Ddata, 3D-datakälla, 3D-bildmodell, landskapsmodell och stadsmodell. (3D-uppdraget) 3D innebär att det kan finnas flera höjdvärden per plankoordinat. LevelofDetail (LoD) CityGML LoD0 (enligt CityGML ) LoD1 (enligt CityGML ) LoD2 (enligt CityGML ) LoD3 (enligt CityGML ) LoD4 (enligt CityGML ) av detaljeringsgrad/komplexitet i 3D-objekt. (3D-uppdraget) OGC-standard avseende överföringsformatet som bl.a. syftar till att ta fram gemensamma definitioner av företeelser, attribut och relationer i stadsmodeller (3D City Model) för att underlätta underhåll och användning för många olika aktörer. Inspires dataspecifikation för byggnader har starka kopplingar till CityGML när det gäller 3D-byggnader. (3Duppdraget) 2,5-D (höjdsatt yta) flygande tak eller fotavtryck på marken. (3D-uppdraget) 3D-data (volym) i form av en låda. (3D-uppdraget) 3D-data med förenklad takkonstruktion och fasad. (3D-uppdraget) 3D-data med detaljerad takkonstruktion och fasad där även struktur ingår. (3D-uppdraget) 3D-data som även beskriver byggnaden invändigt. (3D-uppdraget)

11 11 (145) Styrgruppen BIM En Byggnadsinformationsmodell (BIM) är en objektbaserad 3D-modell med tillhörande datainformation om ingående byggnadsdetaljer t.ex. fabrikat, typ, material och dimensioner. (3D-uppdraget) Tabell 2. Generella termer i Generella termer Term Abstrakt objekttyp Abstraktion Applikationsschema Association Attribut Attributtyp Baskarta Baskarteområde Begreppsmodell (och eventuella kommentarer) Objekttyp som inte själv kan ha några instanser : Används ofta för att modelltekniskt undvika redundans av attributtyper genom att låta en abstrakt klass bära alla gemensamma attributtyper och associationer och därefter låta andra objekttyper ärva dem. Teoretisk konstruktion/tankeskapelse Avser vanligtvis representerande av en Företeelsetyp som en Objekttyp eller en Egenskap som en Attributtyp formell beskrivning av datastruktur, regler och innehåll för information inom ett visst tillämpningsområde Källa: SIS/STANLI (TK 323) Samverkande GIS med ISO En handbok om tekniskt ramverk för geografisk information, utg 1, 2004 Samband mellan objekttyper Instans av Attributtyp : Ett värde som representerar det observerade värdet av en Egenskap hos en Företeelse Egenskap hos Objekt : Representerar en eller flera Egenskaper hos en Företeelsetyp : Det rekommenderas att en attributtyp endast motsvarar en Egenskap för att undvika att man använder attributtypen felaktigt, att problem uppstår i relation till andra modeller (vid mappning etc.) samt svårigheter att definiera användbara värdelistor. Ett vanligt förekommande fall då en attributtyp representerar flera egenskaper är olika typer av klassificeringar. : Maxhöjd vid insamlingstillfälle Digitala data (storskaliga) som redovisar grundläggande förhållanden ovan mark, som är av gemensamt intresse för samhällsbyggandet och som ajourhålls kontinuerligt. Område som ajourhålls med storskalig kartinformation, t.ex. inom tätortsområde eller inom område där kartunderlag för grundkarta, nybyggnadskarta eller förrättningskarta tas fram. Vanligtvis grafisk beskrivning av uppträdande hos en avgränsad del av verkligheten utifrån ett visst syfte.

12 12 (145) Styrgruppen Coverage Datamodell Egenskap Företeelse Företeelsetyp Geodataspecifikation Informationsmodell Termen coverage i samband med geografisk information har ingen allmänt spridd svensk översättning. I ISO definieras coverage på följande sätt: Feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain. som anges är rasterbild, polygon-lager, digital höjdmatris. Det pågår arbete inom SIS att ta fram en svensk term och definition. Begreppet blir tillgängligt i termdatabasen Ekvator när det är färdigt. för hur data ska struktureras och innehålla vid till exempel lagring eller utbyte Format i vilket attribut anges : Olika datatyper har olika egenskaper och kan användas i olika typer av operationer Ej samma sak som stereotypen <<DataType>> i grafiska modellleringsnotationer : Textsträng Heltal Decimaltal Sanningstyp (Ja/Nej) Inneboende karakteristik hos en företeelse som kan användas för att beskriva företeelsen och/eller särskilja en företeelse från en annan : Barr/Löv Art Höjd Solitärt träd Ett i verkligheten förekommande fenomen : Kan vara ett ting eller en process. Kan vara ett naturligt eller konstgjort fenomen. Är en instans av en Företeelsetyp : Trädet utanför huset Grupp av Företeelser med samma egenskaper : Träd Ett dokument som beskriver alla krav som ställs på datamängder enligt geodataspecifikationen. Krav avser struktur på data vid utbyte, obligatoriska element, hur data ska produceras och tillhandahållas samt datakvalitetskrav. En systemoberoende modell som beskriver, strukturerar och definierar den information som ska hanteras och vilka verksamhetsregler som ska gälla. Struktur för informationsinnehåll beskriven som objekttyper, sambandstyper och attributtyper. Föregås oftast av en begreppsmodell, för aktuellt verksamhets- och tillämpningsområde.

13 13 (145) Styrgruppen Kvalitetsmått (engelska, quality measure) Kvalitetsparameter (engelska, quality element) Kvalitetstema (engelska, data quality element category) Kodlista Metadata Modellelement Objekt Objekttyp Objekttypskatalog Kvantitativ bestämning som ligger till grund för utvärderingen av en kvalitetsparameter Källa: HMK Ordlista Detaljerad indelning av geodatakvalitetens olika aspekter; grupperas ihop till kvalitetsteman och mäts med kvalitetsmått Källa: HMK Ordlista Övergripande indelning av geodatakvalitetens olika aspekter (aktualitet, fullständighet, användbarhet etc.); delas in i kvalitetsparameterar, som mäts med kvalitetsmått Källa: HMK Ordlista Uppräknade värden som en attributtyp kan anta : Implementeras oftast i konceptuella modeller som <<codelist>> (utökningsbar) eller <<enumeration>> (icke utökningsbar). Synonymer: Värdelista Värdemängd Värdeförråd Data som definierar och beskriver andra data : Metadata kan förekomma både på datamängdsnivå och objekttypsnivå. Metadata används också för data som beskriver en tjänst. Komponent som bygger upp en modell. : Objekttyper och attributtyper. Instans av Objekttyp : Representerar en individ i verkligheten : Ek id: 21 (Id är egentligen ett attribut men behövs för att identifiera just den ek vi avser) Abstraktion av Företeelsetyp : Representation i datamängd (faktisk eller konceptuell) av en eller flera Företeelsetyper Grupp av Objekt med samma egenskaper Innehåller delmängd av Företeelsers egenskaper utvalda utifrån vad som är möjligt att beskrivas och som utifrån användningsfall identifierats vara betydelsefulla för syftet med abstraktionen. : Lövträd Vedartade växter En sammanställning av en informationsmodell i tabellform Förkortningar Tabell 3. Förkortningar ABT Adress Byggnad Topografi

14 Styrgruppen 14 (145) DGNSS EPSG GALILEO GLONASS GML GNSS GPS HMK GNSS GPS GUM INSPIRE Samverkansavtal kring ABT mellan kommunerna och Lantmäteriet. Differentiell GNSS. Relativ GNSS-mätning där korrektioner för systematiska felkällor beräknas på referensstation och sänds till mobila GNSS-mottagare, som korrigerar sina mätningar. European Petroleum Survey Group System för satellitnavigering som utvecklas på uppdrag av EU och Europeiska rymdorganisationen (ESA). Globalnaja navigatsionnaja sputnikovaja sistema Geographic Markup Language En profil av XML med fördefinierad hantering av geometrier och referenssystem med mera.gps Global Navigation Satellite System. Samlingsbegrepp för GPS, GLONASS och GALILEO. Global Positioning System Handbok i mät- och kartfrågor. Samverkan mellan Lantmäteriet och andra myndigheter, främst kommuner och Trafikverket, som arbetar för enhetlig och standardiserad insamling av geodata i form av handböcker. Se HMK:s hemsida Global Navigation Satellite System. Samlingsbegrepp för GPS, GLONASS och GALILEO. Global Positioning System Guide to the Expression of Uncertainty in Measurement. Standard för mätning. Uttrycket standardosäkerhet kommer från GUM. Standard för redovisning av mätosäkerhet vid olika slags vetenskapliga mätningar. Infrastructure for Spatial Information in Europe RH 2000 Rikets Höjdsystem 2000 SKL SWEREF 99 SWEREF 99 TM SWEREF 99 dd mm UUID XML Sveriges Kommuner och Landsting. Är en intresseförening för kommuner och landsting. Swedish Reference Frame Svenskt tredimensionellt referenssystem Swedish Reference Frame 1999 Transversal Mercator. Rikstäckande kartprojektion i svenskt tredimensionellt referenssystem Swedish Reference Frame Svenskt tredimensionellt referenssystem, lokala projektionszoner Universal Unique IDentifier extensible Markup Language Ett textbaserat överföringsformat för data där man själv definierar struktur och regler för data med hjälp av ett XML-schema (.xsd). I huvudsak avsett för att vara maskinläsbart men kan även läsas av människor.

15 15 (145) Styrgruppen 2.2 Information om Byggnadsdata Namn Byggnad Förkortning - av innehåll Utsträckning i tid och rum Syfte I Fastighetsregistrets Byggnadsdel finns aktuell information om byggnader. Med byggnad avses varaktiga konstruktioner som består av tak eller av tak och väggar och som är varaktigt placerad på mark eller helt eller delvis under mark eller är varaktigt placerad på en viss plats i vatten samt är avsedd att vara konstruerad så att människor kan uppehålla sig i den. Data innehåller de objekttyper som har identifierats utgöra underlag vid planering, bygglovshantering samt framställning av kartprodukter. Objekttyperna kan användas för att bl.a. beskriva befintliga byggnaders geometrier, användning/ändamål, area, mätmetoder samt höjdvärde. Datakvaliteten för byggnaderna varierar beroende på kommunernas avtalsnivå i samverkansavtalet ABT mellan kommunerna och Lantmäteriet. För att möta samhällets behov av 3D information för byggnader innehåller dataprodukten även information kring detta. Hela Sverige Byggnadsdata är väl beskriven och rymmer data om byggnader som behövs som underlag vid framförallt detaljplanering och bygglovshantering samt framställning av kartprodukter. Genom enkelt tillgängliga och väl beskrivna data ökar möjligheterna att både snabbt och effektivt fatta rätt beslut och minimera riskerna att felaktiga beslut fattas i brist på underlag eller på grund av att underlaget tolkas fel. Byggnadsdata kan också bidra till att annan myndighetsutövning underlättas, t.ex. för SCB. Datakällor Kommunala databaser, Lantmäteriets databaser Produktionsprocesser Dataproduktion hos kommunerna (insamling och ajourhållning) utförs i första hand i samband med bygglovshanteringen. Kommunerna registrerar nya byggnader och ansvarar för byggnadsgeometrier inom angivna/avtalade ansvarsområden, oftast inom tätorterna. Insamlingen utförs också med fotogrammetriska metoder och flygbilder som underlag.

16 16 (145) Styrgruppen Dataproduktionen hos Lantmäteriet sker endast genom tolkning i flygbilder med fotogrammetriska metoder. Dataproduktionen utförs inom angivna/avtalade ansvarsområden, oftast på landsbygden. Ajourhållning Ajourhållning sker kontinuerligt hos kommunerna i samband med, i första hand, bygglovshanteringen. Byggnadsgeometriernas aktualitet kan variera beroende på om det är inom eller utanför kommunens ansvarsområde. Ajourhållningen hos Lantmäteriet sker periodiskt. Aktualiteten beror då på bildförsörjningsprogrammet där intervallen är 2, 4-6 eller 6-10 år beroende på vilken del av landet det gäller. 3 Byggnadsdatas omfattningar Förutom hela Byggnadsdata har 8 delomfattningar (B1-B6 och C1-2) identifierats som beskrivs nedan. Omfattningen avser alla kommuner med följande delomfattningar: Ansvarsområden där objekt skapas och ajourhålls av Lantmäteriet respektive kommunerna med olika krav när det gäller ajourhållningsintervall (Aktualitet). Geometrisk representation ABT-avtalet mellan kommunerna och Lantmäteriet omfattar samverkan om ajourhållning av de nationella grundläggande databaserna för adresser och byggnader. Avtalet innehåller tre olika samverkansnivåer och innebär olika omfattande kommunala insatser. I huvudsak påverkas de tre nivåerna av fullständighet och aktualitet. 3.1 Omfattning A - Byggnadsdata Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Byggnader 005 Datamängd Byggnader Datamängd beskrivande byggnader. Utsträckning Data förekommer inom hela Sverige. Coverages - Ingående omfattningar Delomfattning B - Aktualitet Delomfattning B1 Lantmäteriet periodiskt - Ajourhållningsintervall 2 år

17 17 (145) Styrgruppen Delomfattning B2 Lantmäteriet periodiskt - Ajourhållningsintervall 4-6 år Delomfattning B3 Lantmäteriet periodiskt - Ajourhållningsintervall 6-10 år Delomfattning B4 Kommun kontinuerligt Bygglovsprocessen Delomfattning B5 Kommun - Vid behov Delomfattning B6 Kommun periodiskt Olika ajourhållningsintervall Delomfattning C Geometrisk representation Delomfattning C1 Lantmäteriet Geometrisk representation Delomfattning C2 Kommun Geometrisk representation 3.2 Delomfattning B Aktualitet Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Aktualitet 005 Datamängd Aktualitet Aktualitet beskriver hur ofta uppdatering sker. Kommuner ajourhåller i huvudsak kontinuerligt och Lantmäteriet periodiskt utifrån intervallen i bildförsörjningsprogrammet. Figur 3 Plan för Lantmäteriets bildförsörjningsprogram.

18 Styrgruppen 18 (145) Utsträckning Överordnad omfattning Data förekommer över hela Sverige. Hela dataprodukten Delomfattning B1 Lantmäteriet periodiskt Ajourhållningsintervall 2 år Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Ajourhållningsintervall 2 år 005 Datamängd Ajourhållningsintervall 2 år Inom Lantmäteriets ansvarsområde sker planerad ajourhållning av byggnaders detaljerade geometri med intervall på 2 år. Södra Sverige, Öland, Gotland och Norrlands kustland Aktualitet Delomfattning B2 Lantmäteriet periodiskt - Ajourhållningsintervall 4-6 år Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Ajourhållningsintervall 4-6 år 005 Datamängd Ajourhållningsintervall 4-6 år Inom Lantmäteriets ansvarsområde sker planerad ajourhållning av byggnaders detaljerade geometri med intervall på 4-6 år. Data förekommer i Svealands och Norrlands inland, exklusive fjälltrakterna. Aktualitet Delomfattning B3 Lantmäteriet periodiskt - Ajourhållningsintervall 6-10 år Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Ajourhållningsintervall 6-10 år 005 Datamängd Ajourhållningsintervall 6-10 år Inom Lantmäteriets ansvarsområde sker planerad ajourhållning av byggnaders detaljerade geometri med intervall på 6-10 år. Data förekommer i fjälltrakterna.

19 Styrgruppen 19 (145) Överordnad omfattning Aktualitet Delomfattning B4 Kommun kontinuerligt - Bygglovsprocessen Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning kommun bygglovsprocessen 005 Datamängd kommun bygglovsprocessen Kommuners kontinuerliga ajourhållning när en förändring blir känd. Ofta i samband med ett administrativt förfarande t.ex. bygglovsprocessen. Byggnader som beviljats bygglov lagras med attribut bl.a. identitet, ändamål, nybyggnadsår, schablongeometri och status planerad. När byggnaden är kontrollmätt lagras den med detaljerad geometri (inom kommunens ansvarsområde) och status gällande. Data förekommer i hela Sverige. Aktualitet Delomfattning B5 Kommun Vid behov Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Kommun Vid behov 005 Datamängd Kommun Vid behov När ett område behöver dokumenteras inför en förändring, t.ex. inför en detaljplanering, ombyggnation etc. Data förekommer i hela Sverige. Aktualitet Delomfattning B6 Kommun periodiskt Olika ajourhållningsintervall Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Kommun periodiskt Olika ajourhållningsintervall 005 Datamängd Kommun Olika ajourhållningsintervall Ajourhållning av förändringar med olika ajourhållningsintervall. Data förekommer i hela Sverige. Aktualitet

20 Styrgruppen 20 (145) 3.3 Delomfattning C Geometrisk representation Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Geometrisk representation 005 Datamängd Geometrisk representation Beskriver byggnaders geometriska representation i 2D eller 2,5D (LoD0) och 3D (LoD1-3). Data förekommer i hela Sverige. Hela dataprodukten Delomfattning C1 Lantmäteriet Geometrisk representation Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Geometrisk representation 005 Datamängd Lantmäteriet Geometrisk representation Byggnader redovisas nationellt med flygande tak i 2.5 D eller med förenklad takkonstruktion. Taken är mätta i takkant. Volymer kan beräknas med hjälp av nationella höjdmodellen. Data förekommer i hela Sverige. Geometrisk representation Delomfattning C2 Kommun Geometrisk representation Identifiering av omfattning Hierarkisk nivå Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Kommun Geometrisk representation 005 Datamängd Kommun Geometrisk representation Byggnader redovisas i 2D och 3D. Större kommuner har både geodetiskt inmätt fasad i 2D och 3D-modeller baserade på fotogrammetri. Redovisningen i 3D kan variera mellan olika kommuner; från LoD1 (lådmodell) till LoD3 (detaljerade takkonstruktioner och fasad där även struktur ingår). Data förekommer i hela Sverige. Geometrisk representation

21 21 (145) Styrgruppen 4 Identifiering av Byggnadsdata Titel Byggnad Alternativ titel Byggnad Produktnummer - Versionsnummer Sammanfattning Byggnadsdata beskriver de geodata om byggnad som Lantmäteriet och kommunerna samlar in, lagrar och tillhandahåller. Fastighetsregistrets Byggnadsdel är ett nationellt register över Sveriges byggnader. Med byggnad avses varaktiga konstruktioner som består av tak eller av tak och väggar och som är varaktigt placerad på mark eller helt eller delvis under mark eller är varaktigt placerad på en viss plats i vatten samt är avsedd att vara konstruerad så att människor kan uppehålla sig i den. Dessa byggnader påverkar processer inom samhällsbyggnadsområdet, t.ex. detaljplanering, bygglov, kartproduktion. Större delen av processerna ägs av kommunerna t.ex. bygglovsprocessen som regleras av PBL (Plan och Bygglagen). Data om byggnader ska, tillsammans med andra data, möjliggöra en baskarta som ajourhålls regelbundet och fungerar som underlag inom flera delar inom samhällsbyggnadsprocessen. Viss byggnadsinformation ingår även i andra myndigheters uppdrag, t.ex. SCB statistikframställning. Syfte Dataprodukten Byggnad är en väl beskriven dukt som rymmer data om byggnader som underlag vid framförallt detaljplanering och hantering och syftar till att skapa en natione gande datamängd för byggnader. Genom enkelt tillgängliga och väl beskrivna möjligheterna att både snabbt och effektivt beslut och minimera riskerna att felaktiga b brist på underlag eller på grund av att unde fel. Dataprodukten Byggnad kan också bidra nan myndighetsutövning underlättas. Ämnesområde Byggnader och byggnadskonstruktioner Ämnesområde ur den nationella metadataprofilen (tabell 33).

22 22 (145) Styrgruppen Typ av geometrisk representation 001 Vektor Ur den nationella metadataprofilen (tabell 52). Rumslig upplösning 1:500-1:50000 Geografisk utsträckning Byggnadsdata förekommer inom hela Sverige. Kompletterande information För ajourhållningen av datamängden finns handböcker tillgängliga på Lantmäteriets webbplats 5 Datainnehåll och struktur 5.1 Beskrivande text Byggnadsdata är uppbyggd av en informationsmodell som består av objekttyper för byggnad, byggnadsdel, fysisk byggnad, aggregerad byggnad och byggnadstillbehör. Till dessa objekttyper finns ett antal attribut t.ex. ändamål, nybyggnadsår, antal våningar och geometri. Vissa attribut kan användas både för byggnad och byggnadsdel, medan andra endast kan förekomma på hela byggnadsobjektet. Den geometriska representationen av byggnader kan vara punkt, linje, yta eller kropp. Från byggnadsobjektet finns samband med objekttyperna Registerenhet, Adressplats, Lägenhet samt Taxerings- och Värderingsenhet. I kapitel 5.2 nedan beskrivs i detalj alla ingående objekttyper, attribut och relationer som ingår i dataprodukten. sker med hjälp av figurer (UML-diagram), förklarande text och en objekttypskatalog. Inom har inga applikationsscheman (enligt ISO 19109) tagits fram utan det sätt som Byggnadsdatas innehåll är grafisk dokumenterat med är en informationsmodell. Informationsmodellen är dokumenterad med UML ( och är framförallt avsedd att vara läsbar för människor och är därför i vissa avseenden inte konsekvent eller tekniskt korrekt modellerad. Se bilaga B för information om hur UML har använts i. 5.2 Informationsmodell och objekttypskatalog Informationsmodellen är uppdelad i flera figurer för att belysa de olika delarna av modellen. Hela informationsmodellen återfinns i 14.3 bilaga C. I avgränsandet av Byggnadsdata så har företeelser identifierats som Byggnadsdatas objekttyper har beroenden eller associationer till men som inte omfattas av Byggnadsdata. Dessa företeelser är Registerenhet, Adressplats och Lägenhet. informationsmodeller är framförallt skapade för att visa informationen utifrån ett verksamhetsperspektiv vilket redovisas i specifikationerna. För att

23 23 (145) Styrgruppen kunna skapa datautbytesmodeller i form av XML-scheman motsvarande informationsmodellerna har en del avgränsningar och uppdelningar behövt göras. Dessa nya schemagrundande informationsmodeller redovisas ej i specifikationerna utan tillhandahålls tillsammans med XML-scheman, kodlistor och exempel via projektets hemsida De schemagrundande informationsmodellerna tillhandahålls som html eller som en.eap-fil (Sparx systems Enterprise Architecht). I objekttypskatalogen ingår endast objekttyper skapade för Byggnadsdata och ej objekttyper från annan modell eller standard även om dessa syns i figurerna med UMLdiagram. I svensk geoprocess informationsmodeller används benämningen kodlista för att beskriva tillåtna värden ett attribut kan anta. Kodlistorna är utökningsbara. Färgsättning av objekttyper görs enligt Figur 4. class Färgsättning «FeatureType» Temagemensam objekttyp/klass «DataType» Temagemensam datatyp «codelist» Temagemensam kodlista «conceptual» Begrepp «FeatureTy... Egen Objekttyp/Klass «DataType» Egen datatyp «codelist» Egen kodlista Objekt «conceptual» Tema «FeatureTy... Importerad Objekttyp/klass «DataType» Importerad datatyp «codelist» Importerad kodlista Figur 4 Färgsättning av klasser i diagram. Krav 1. Krav 2. Krav 3. Krav 4. Krav 5. Informationsmodellens obligatoriska attribut och associationer ska finnas med i datamängd enligt denna geodataspecifikation (Se kapitel 7.1, Nr. 3). Informationsmodellens angivelser om multiplicitet ska följas för datamängder enligt denna geodataspecifikation (Se kapitel 7.1, Nr. 3). Endast värden från kodlistor ska användas för attribut vars typ är en kodlista (Se kapitel 7.1, Nr. 4). Kodlistor är utökningsbara. Utökad kodlista ska tillhandahållas av ansvarig part. Koder/värden i utökade kodlistor ska inte stå i konflikt med värden i ursprunglig kodlista.

24 24 (145) Styrgruppen Krav 6. Utökning av kodlistor ska ske i samverkan mellan alla identifierade intressenter. Rekommendation 1. Gemensamma kodlistor ska förvaltas av Lantmäteriet Okända värden I specifikationer används inte okänt, ospecificerat eller liknande värden i kodlistor. Istället används den inbyggda funktionen nillable från XML-schemaspecifikationen från W3C. Detta har gjorts med tanke på att det huvudsakliga utbytet som förväntas ske enligt specifikationerna är maskin till maskin. Det är sedan upp till respektive organisation att i sitt eget system hantera detta på lämpligt sätt utifrån egna behov. Att ett element (huvudsakligen en objekttyp eller ett attribut) är nillable betyder att de inte behöver fyllas med ett värde utan kan få attributet xsi:nil= true. Till detta hör också ett annat attribut nilreason (Tabell 4), orsaken till att värdet saknas. Tabell 4. NilReason (fetmarkerade värden används inom ). nilreason inapplicable missing template unknown withheld other<briefexplanation> Betydelse Ej tillämpbart, värdet saknas Värdet saknas hos dataproducenten men kan gå att bestämma Värdet finns och kommer att kompletteras senare Värdet kan finnas men dataproducenten kan varken bestämma värdet eller om det går att bestämma. Avslöjas ej av sekretesskäl Annat skäl i normalfallet då ett värde finns <SG_Objekt> <id>xxxxx</id> <typ xlink.href= </SG_Objekt> då värde saknas och nil används: <SG_Objekt> <id>yyyyy</id> <typ xsi:nil= true nilreason= unknown /> </SG_Objekt> Alla element I XML-scheman är nillable.

25 25 (145) Styrgruppen Rumsliga referenssystem För att hantera rumsliga referenssystem för data enligt specifikationer används de inbyggda funktionerna i GML där varje geometri har ett referenssystem. Detta innebär att referenssystem inte behöver hanteras som ett eget attribut på den objekttyp som bär en geometri. Referenssystemet anges med EPSG-kod (se Fel! Hittar inte referenskälla.). : <SG_Objekt> <Geometri srsname= epsg:3006> <gml:polygon> <gml:outerboundaryis> <gml:linearring> <gml:coordinates>0,0 100,0 100,100 0,100 0,0</gml:coordinates> </gml:linearring> </gml:outerboundaryis> </gml:polygon> </Geometri> <SG_Objekt>

26 26 (145) Styrgruppen Beroenden till andra specifikationer pkg SG_ByggnadPaketBeroenden SG_Adress SG_GemensammaKlasser (from SvenskGeoprocess) (from SvenskGeoprocess) SG_Markanv ändningmarktäcke (from SvenskGeoprocess) SG_Byggnad Buildings SG_MarkDetaljer (from SvenskGeoprocess) SG_VägJärnv äg (from SvenskGeoprocess) (from Annex III) (from SvenskGeoprocess) ISO 19115:2006 Metadata (Corrigendum) (from ISO TC211) ISO 19107:2003 Spatial Schema + Geometry + Topology (from ISO TC211) Figur 5 Paketdiagram visande Byggnadsdatas beroenden Gemensamma objekttyper För att skapa enhetlighet bland de specifikationer som tas fram inom har en uppsättning gemensamma objekttyper skapats som kan användas av alla specifikationer. De gemensamma klasserna medför att identifierare, livcykelinformation, geometrier och beskrivning av datamängder och metadata hanteras enhetligt SG_BasKlass SG_BasKlass (figur 6) är en abstrakt superklass (objekttyp) som äger de mest grundläggande attributen som krävs vid utbyte av geodata. Nästan alla andra objekttyper i alla specifikationer inom kan vara specialiseringar av typen SG_Bas- Klass. Att skapa superklasser på detta sätt är en vanligt förekommande metod för att undvika upprepning i modeller och därmed göra modellerna mer lättlästa. SG_BasKlass har ett obligatoriskt attribut, id, som är av typen SG_Id. Man kan ange ett eller två id:n. en SG_Id medger att man kan välja mellan två olika id:n, ett nationellt-id eller ett verksamhets-id. Båda är av datatypen Identifier (figur 7) som kommer från Inspire och består av en namnrymd (namespace) och ett id (localid) som tillsammans ger ett unikt id vilket förklaras djupare längre ner i detta kapitel. För nationelltid ska namespace inte peka ut en organisation utan en datamängd enligt en viss specifikation. För verksamhetsid ska namespace peka ut en organisation men

27 27 (145) Styrgruppen kan även peka ut en viss datamängd som förvaltas av organisationen. Se ytterligare om identifierare i Attributet externreferens, av typen SG_ExternReferens ger möjlighet att associera ett objekt enligt en specifikation med ett annat objekt enligt en annan specifikation, exempel: möjlighet att koppla en byggnad till ett ortnamn ur Ortnamnsregistret. Objekt enligt olika specifikationer i kan representera samma verkliga företeelse men ur olika aspekter. Associationen representerarsammaföreteelse ger möjlighet att tala om att ett objekt enligt en specifikation i representerar samma verkliga företeelse som ett annat objekt ur en annan specifikation i. : En vägs utbredning beskrivs som Markanvändning men inte dess beläggning (asfalt, grus etc.) vilket istället beskrivs som Marktäcke. För att till exempel kunna använda samma geometri som representerar båda objekten kan associationen representerarsammaföreteelse användas. class SG_Basklass +representerarsammaföreteelse 0..* «FeatureType» SG_GemensammaKlasser::SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime «union» SG_GemensammaKlasser:: SG_Id + nationelltid: Identifier + verksamhetsid: Identifier «DataType» SG_GemensammaKlasser:: SG_ExternReferens + id: CharacterString Figur 6 SG_BasKlass class Inspire_Id «datatype» Base Types::Identifier + localid :CharacterString + namespace :CharacterString «lifecycleinfo, voidable» + versionid :CharacterString [0..1] Figur 7 Inspires identifierare, Identifier Identifierare Unika identifierare kan uppnås på olika sätt, antingen med UUID som är en universellt unik identifierare bestående av 32 hexadecimala tecken separerade i fyra grupper av bindestreck (-). Ett annat sätt är att med en URI (Unique Resource Identifier) identifiera

28 28 (145) Styrgruppen en datamängd i något som kallas Namespace och därefter identifiera ett objekt i datamängden med en för datamängden unik identifierare. Det senare sättet används av typen Identifier från Inspire med hjälp av attributen namespace och localid. Trots att localid inte måste vara universellt unik så rekommenderar denna geodataspecifiaktion att UUID används. Arbete pågår i Sverige med att ta fram riktlinjer för namespace for geodata. Arbetet leds av Lantmäteriet. Föreslaget är en lösning enligt nedan: identifier}/{localid} på ett nationellt id skulle då kunna bli: fd5e-90ec-e040-ed8f66333c3f på ett verksamhets-id skulle då kunna bli: Krav 4. Alla objekt i en datamängd enligt denna geodataspecifikation ska ha en identifierare (Id) (Se kapitel 7.1, Nr. X). Krav 5. Då endast en identifierare anges skall den vara av typen nationellid. Krav 6. Då två identifierare anges skall de vara ett av varje typ, nationelltid och verksamhetsid. Krav 7 nationelltid:s namespace ska identifiera en datamängd. Krav 8. verksamhetsid:s namespace ska identifiera en organisation. Krav 9 Identifierare ska vara av typen Identifier (Inspire - Generic conceptual model - BaseTypes) (Se kapitel 7.1, Nr. X). Krav 10. Identifieraren ska vara unik och stabil över objektets livstid. Rekommendation 1 LocalId som är ett attribut till typen Identifier ska vara av typen UUID (ISO/IEC :2005) Livscykelinformation Inspire har skapat attributen beginlifespanversion och endlifespanversion som tillsammans med ett versionsnummer, valfritt attribut på identifieraren Identifier, på ett objekt kan användas vid versionshantering och åtkomst till äldre versioner av objektet. Krav 13. Då attributet endlifespanversion förekommer får dess värde inte inträffa före värdet attributet beginlifespanversion.

29 Styrgruppen 29 (145) Rekommendation 3. Attributet beginlifespanversion ska finnas för samtliga objekt i datamängd enligt denna geodataspecifikation. Rekommendation 4. Datum, för när objekt skapades i databas hos ansvarig part, ska användas för attributet beginlifespanversion och alla objekt i en datamängd enligt denna geodataspecifikation Objekttyper SG_BasKlass Sammanhållande abstrakt klass för attribut som är grundläggande vid utbyte av geodata och som kan användas som superklass för en modells samtliga objekttyper Attribut Multiplicitet id Identifierare [1..2] SG_Id beginlifespanversion Datum då objekt först skapades i datamängd. [0..1] DateTime endlifespanversion externreferens aktualitet Datum från när objekt inte längre ingår i datamängd. [0..1] DateTime Referens till Referens annan objekttyp till annan i objekttyp [0..*] i eller [0..*] SG_ExternReferens SG_ExternRefere eller utanför utanför Svensk. geopro-cess. Datum då objektet senast befanns [1] DateTime vara korrekt er SG_Id Identifierare Attribut Multiplicitet nationelltid verksamhetsid Nationell identiferare : namespace pekar ut datamängd, ej ansvarig organisation Lokal identifierare skapad utifrån specifika verksamheters behov : namespace pekar ut ansvarig organisation, ej specifikation. [1..1] Identifier [1..1] Identifier SG_ExternReferens Referens till annan objekttyp i eller utanför. Attribut Multiplicitet id Identifierare för extern objekttyp som refereras till. [1] CharachterString

30 Styrgruppen 30 (145) SG_Projekt SG_Projekt, Figur 8, är en objekttyp som kan användas i olika teman inom. SG_Projekt är en subtyp till SG_BasKlass och ärver därifrån id och livscykelinformation. SG_Projekt innehåller flera attribut som hänförs till myndigheter eller företag som på något sätt deltar i projekten som utförare eller beställare. Informationen lagras i en datatyp Related Party, vilken importerats från Inspire Generic Conceptual Model, Figur 9. class SG_Projekt «FeatureType» SG_GemensammaKlasser::SG_BasKlass + id :SG_Id [1..2] + beginlifespanversion :DateTime [0..1] + endlifespanversion :DateTime [0..1] «FeatureType» SG_GemensammaKlasser::SG_Projekt + geodataproducent :RelatedParty [0..*] + geodataägare :RelatedParty [1..*] + projektid :CharacterString + projektnamn :CharacterString [0..1] + projektrapportlänk :URI [0..1] + uppdragsgivare :RelatedParty [0..*] Figur 8 SG_Projekt. class RelatedParty «datatype» Base Types 2::RelatedParty «voidable» + individualname :PT_FreeText [0..1] + organisationname :PT_FreeText [0..1] + positionname :PT_FreeText [0..1] + contact :Contact [0..1] + role :PartyRoleValue [0..*] «datatype» Base Types 2::Contact «voidable» + address :AddressRepresentation [0..1] + contactinstructions :PT_FreeText [0..1] + electronicmailaddress :CharacterString [0..1] + hoursofservice :PT_FreeText [0..1] + telephonefacsimile :CharacterString [0..*] + telephonevoice :CharacterString [0..*] + website :URL [0..1] Figur 9 RelatedParty

31 Styrgruppen 31 (145) Objekttyper SG_Projekt Information om dataskapande/-insamlande verksamhet som bedrivs i projektform Attribut Multiplicitet geodataproducent geodataägare Organisation som producerar geodata. Rättighetsinnehavare till datamängd [0..*] RelatedParty [1..*] RelatedParty projektid Unik identifiering av projekt. [1..1] CharacterString projektnamn projektrapportlänk Namn på projektområdet, t.ex. ortnamn Länk till en adress där projektrapport är tillgänglig [0..1] CharacterString [0..1] URI uppdragsgivare Beställare av projekt [0..*] RelatedParty Geometrityper För spcifikationer har en grunduppsättning geometrityper tagits fram, Figur 10. De är i huvudsak specialiseringar av geometrityper från SS-ISO 19107:2003 Modell för att beskriva rumsliga aspekter. class SG_Geometri «FeatureType» SG_GemensammaKlasserInformation:: SG_Geometri + geometriid: SG_Id [1..2] + lägesosäkerhetplan: SG_LägesOsäkerhet [0..1] + lägesosäkerhethöjd: SG_LägesOsäkerhet [0..1] + geometrikälla: RelatedParty + geometrimetadata: SG_GeometriMetadata [0..1] «FeatureType» SG_GemensammaKlasserInformation: :SG_Punkt + punkt: GM_Point + ärcentroid: Boolean [0..1] «FeatureType» SG_GemensammaKlasserInformation: :SG_Yta + yta: GM_MultiSurface «FeatureType» SG_GemensammaKlasserInformation: :SG_Kropp + kropp: GM_Solid «FeatureType» SG_GemensammaKlasserInformation::SG_Linje + linje: GM_MultiCurve + typavlinje: SG_TypAvLinje + /kartografiskrepresentation: SG_KartografiskRepresentationLinjeTyp [0..*] + kantlinjeegenskap: SG_KantlinjeEgenskapTyp [0..1] «codelist» SG_GemensammaKlasserKodlistor: :SG_TypAv Linje + Kantlinje + Mittlinje + AnnanLinje «codelist» SG_GemensammaKlasserKodlistor:: SG_KartografiskRepresentationLinjeTyp «codelist» SG_GemensammaKlasserKodlistor: :SG_KantlinjeEgenskapTyp + Kantsten + Släntfot + Släntkrön Figur 10 geometrityper.

32 32 (145) Styrgruppen Grundtanken i är att en företeelses abstraktion inte är knuten till hur den representeras geometriskt. Detta ger möjlighet att representera en företeelse med flera geometrier. Ett dike kan ha både två kantlinjer, en mittlinje och en yta. I många fall så skapas abstraktioner av företeelser utifrån hur man tänker sig att de ska representeras geometriskt och geometrin blir en del av typen, till exempel Dikeskant. I så ligger inte möjligheten att tala om detta på typen, ett dike är ett dike, inte en linje. Om det är en kantlinje, en mittlinje eller en yta ges istället av geometrin Alla geometrier (SG_Geometri) i har flera egenskaper men det är endast attributen geometriid och geometrikälla som är obligatoriska. Det finns möjlighet att beskriva lägesosäkerheten för en enskild geometri i både plan och höjd (Fel! Hittar inte referenskälla.) samt vilken metod som har använts för att fastställa lägesosäkerheten. Figur 11 Lägesosäkerhet för geometrier. GeometriId anges på samma sätt som för SG_BasKlass (Fel! Hittar inte referenskälla.). GeometriKälla anges med Inspire-klassen RelatedParty (Fel! Hittar inte referenskälla.). class RelatedParty «datatype» Base Types 2::RelatedParty «voidable» + individualname :PT_FreeText [0..1] + organisationname :PT_FreeText [0..1] + positionname :PT_FreeText [0..1] + contact :Contact [0..1] + role :PartyRoleValue [0..*] «datatype» Base Types 2::Contact «voidable» + address :AddressRepresentation [0..1] + contactinstructions :PT_FreeText [0..1] + electronicmailaddress :CharacterString [0..1] + hoursofservice :PT_FreeText [0..1] + telephonefacsimile :CharacterString [0..*] + telephonevoice :CharacterString [0..*] + website :URL [0..1] Figur 12 RelatedParty

33 33 (145) Styrgruppen I många kommunala verksamheter används inte ytor (polygoner) för att representera företeelser med ytutbredning i verkligheten utan istället används linjer, till exempel begränsningslinje eller kantlinje. För att kunna tala om vad en linje representerar gällande en verklig företeelse så är attributet typavlinje obligatoriskt för alla linjer. En linje kan vara: Kantlinje, en linje som används för att beskriva ytterkant på en företeelse. Till exempel kan ett dike representeras av två kantlinjer. Mittlinje, en linje som representerar en utsträckt företeelses mitt. Till exempel så kan ett dike i tillägg till två kantlinjer även ha en mittlinje. Annan linje, alla övriga typer av linjer. Till exempel kan man låta en linje representera ett mindre vattendrag i en småskalig presentation oavsett om den avser vattendragets mitt eller kant. Då man inte hanterar ytor utan linjer som geometrisk representation för ytutbredda företeelser i verkligheten så förekommer de ofta tillsammans med en centroid (SG_Punkt med attributet ärcentroid=true) och topologier för att avgränsa en företeelses utbredning. Centroiden tillsammans med linjer kan användas för at konstruera en yta vid behov. En linje kan behöva presenteras i till exempel en karta. För en del linjer kan detta behöva ske utan att ytan som den delvis avgränsar ritas ut. Hur linjen ska presenteras (portrayal/manér) beror på vilka typer av företeelser den avgränsar. Attributet kartografiskrepresentation på objekttypen SG_Linje ger möjlighet att beskriva hur en linje är tänkt att representeras kartografiskt med kodlistan SG_KartografiskRepresentationLinjeTyp utifrån omgivande typer av företeelser. Ska till exempel en kantlinje mellan en åker och en väg presenteras som åkerkant eller vägkant. SG_KartografiskRepresentationLinjeTyp kommer att implementeras olika för olika specifikationer utifrån de behov som respektive specifikation representerar. Andra egenskaper som förekommer på kantlinjer är till exempel förekomst av kantsten. Denna och liknande egenskaper kan tillskrivas linjen med hjälp av attributet kantlinje- Egenskap som använder kodlistan SG_KantlinjeEgenskapTyp.

34 34 (145) Styrgruppen Figur 13 Geometrimetadata I Fel! Hittar inte referenskälla. så beskrivs ytterligare egenskaper till SG_Geometri. Det största skälet till att SG_GeometriMetadata finns är att kunna använda SG_Geometri i så många sammanhang där de frivilliga egenskaperna som beskrivs i SG_Geometri- Metadata ej behövs och därmed inte verkar skrämmande för läsare av aktuell modell eller specifikation. En geometri kan ha ett namn, geometrinamn, om behovet finns. GeometriSyfte anges i nuläget med fritext och kan vara till exempel: modellunderlag, representation för objekt i detaljplan etc. Attributet inmätningsläge gör att man kan tala om hur en företeelse är inmätt och representerad geometriskt. Standardalternativet för inmätningsläge är enligt mätningsanvisningar men för att inte exkludera utbyte av gamla geodata som mätts in enligt okända regler finns möjlighet att ange flera alternativ. Detta gör det också möjligt att belysa om mätningsanvisningar saknas. Attributet tänktupplösningpresentation talar om vilken skala en geometri är tänkt att presenteras i, används främst om detta är viktigt för förståelsen och användandet av geometrin. Det finns också möjlighet att beskriva aktualitet för enskilda geometrier, aktualiteten beskrivs som det datum då geometrin senast befanns vara korrekt.

35 35 (145) Styrgruppen Det finns flera attribut som beskriver de olika tillfällen som ligger bakom skapandet av en geometri och som kan vara bra att känna till vid användning av geometrier. Insamlingsdatum avser det datum då en flygbild tagits (eller en geodetisk fältmätning utförts etc.) och som sedan legat till grund för skapande av en geometri. BeginLifeSpanversion avser det datum då själva geometrin tolkats/skapats och lagrats i en databas. På liknande sätt anger endlifespanversion när en geometri ersatts av en nyare geometri databas eller beslutats inte längre vara aktuell eller användbar. I vissa fall kan en företeelse vara skymd, helt eller delvis, i en flygbild eller ett ortofoto och den som skapar geometrin gör en uppskattning av geometrin utifrån erfarenhet, regler och/eller andra indikatorer i bilden. När så inträffar skall attributet osäkert läge (skymd geometri) sättas till True (standardvärde för attributet är False ) och attributet osäkertlägeanledning skall anges Objekttyper SG_Geometri Geometrityper och kvalitetsmärkning av ett objekts geometri - framtagna för ändamål. Attribut Multiplicitet geometriid Identifierare för geometri [1..2] SG_Id LägesOsäkerhetPlan LägesOsäkerhetHöjd geometrikälla Mätmetod och standardosäkerhet för geometris läge i plan Mätmetod och standardosäkerhet för geometris läge i höjd Organisation ansvarig för geometri [0..1] SG_LägesOsäkerhet [0..1] SG_LägesOsäkerhet [1..1] RelatedParty geometrimetadata Metadata för geometri [0..1] SG_GeometriMetadata SG_Punkt Endimensionell geometri som beskriver en punkt Attribut Multiplicitet punkt Geometri [1..1] GM_Point ärcentroid Talar om huruvida punkten används som centroid hållande identifierare för ytutbrett objekt och som tillsammans med linjer kan användas vid skapande av ytgeometri. [0..1] Boolean SG_Linje Linjegeometri Attribut Multiplicitet linje Geometri [1..1] GM_MultiCurve typavlinje kartografiskrepresentation Kategorisering av linjegeometri utifrån användningssyfte av hur en linje är tänkt att representeras kartografiskt. [1..1] SG_TypAvLinje [0..1] SG_KartografiskRepresentationLinjeTyp

36 Styrgruppen 36 (145) kantlinjeegenskap Anger om kantlinjen har speciella egenskaper [0..1] SG_KantlinjeEgenskap- Typ SG_Yta Tvådimensionell ytgeometri Attribut Multiplicitet yta Geometri [1..1] GM_MultiSurface SG_Kropp Tredimensionell geometri som avgränsas av gränsytor Attribut Multiplicitet kropp Geometri [1..1] GM_Solid er SG_GeometriMetadata Geometrityper och kvalitetsmärkning av ett objekts geometri - framtagna för ändamål. Attribut Multiplicitet geometrinamn Namn på geometri [0..1] CharacterString geometrisyfte inmätningsläge tänktupplösningpresentation aktualitet insamlingsdatum beginlifespanversion osäkertläge Syfte för vilket geometri skapats av hur en geometri är inmätt Tänkt skala/upplösning för presentation av geometri Datum då geometrin senast befanns vara korrekt Datum då data samlats in : Avser vanligen det datum då flygbild tagits eller geodetisk fältmätning utförts Datum då objekt skapades i datamängd : Avser vanligen det datum då ett objekt lagras i en databas men kan också avse det datum då mätning i bild eller tolkning av fältdata görs Markering om att direkt mätning av geometri inte kunnat ske : Kallas även skymd geometri, False = ej osäkert läge är standardval [0..1] CharacterString [0..1] SG_InmätningsLäge [0..1] MD_Resolution [0..1] DateTime [0..1] DateTime [0..1] DateTime [1..1] Boolean osäkertlägeanledning endlifespanversion Anledning till att en geometri betraktats som skymd/osäkert läge. Datum då objekt ersatts av annat objekt i datamängd eller [0..1] CharacterString [0..1] DateTime

37 Styrgruppen 37 (145) beslutats inte längre vara aktuell eller användbar. : Objekt ersatta med nyare objekt/versioner är vanligtvis inte tillgängliga via normala sökningar/frågor mot datamängd. SG_LägesOsäkerhet av mätmetod och standardosäkerhet för lägesbestämning av en geometri. Attribut Multiplicitet lägesosäkerhet mätmetod tidpunktmätning Geometrins standardosäkerhet Metod för fastställning av geometrins läge. Tidpunkt för mätning. : Används då olika metoder används för mätning i plan och höjd, annars används bara insamlingsdatum på SG_GeometriMetadata [1..1] DQ_PositionalAccuracy [1..1] CharacterString [0..1] DateTime Kodlistor SG_typAvLinje Värden Kantlinje Mittlinje AnnanLinje Kategorisering av linjegeometri utifrån användningssyfte. Linje som representerar del av en företeelses yttre begränsning Linje som representerar en företeelses mitt Generell typ av linje som representerar en företeelse och som används då linjen ej representerar en företeelses kant eller mitt av hur en linje är tänkt att representeras kartografiskt. : Kodlistan kommer att variera i olika specifikationer och hur den ska implementeras beskrivs av respektive specifikation. SG_KartografiskRepresentationLinjeTyp SG_SG_KantlinjeEgenskapTyp Värden Egenskaper som en kantlinje kan ha Kantsten Släntfot Släntkrön SG_InmätningsLäge Värden av hur en geometri är inmätt : Kodlistan kommer att variera för olika specifikationer och hur den ska implementeras beskrivs av respektive specifikation. Startvärde ("default") är Enligt SGP mätningsanvisning.

38 38 (145) Styrgruppen Enligt SGP mätningsanvisning Företeelsen som geometri representerar är inmätt enligt mätningsanvisningar. Egna mätningsanvisningar Företeelse som geometri representerar är inmätt enligt egna mätningsanvisningar. : Vem "egen" avser ges av attributet geometrikälla på SG_Geometri. Marknivå Överkant Mätningsanvisningar saknas Företeelsen som geometri representerar är inmätt i marknivå. Företeelsen som geometri representerar är inmätt i överkant. Mätningsanvisningar saknas Höjd och 3D Efterfrågan på att veta höjd på företeelser i olika sammanhang ökar ständigt, till exempel 3D-modeller, översvämningsbedömning med mera. Höjd mäts idag inom olika verksamheter och på olika sätt, allt ifrån enstaka objekt till flygburen laserskanning över stora områden. Höjddata har traditionellt sett ofta hanterats som antingen ett ytterligare attribut på ett objekt eller som en höjdvärde på en geometri. I denna specifikation ges utrymme för att uttrycka höjd på flera sätt utifrån behov: Höjd som ett attribut (2D). En objekttyp kan ha ett attribut för att beskriva höjd, detta speglar oftast endast en aspekt av ett objekts höjd. Till exempel höjden på ett berg. Höjd som attribut följer de krav på referenssystem som anges i denna specifikation. Höjdvärden på geometri. o o Höjd kan anges som ett höjdvärde på en punkt och på brytpunkter ingående i en linje eller en yta (2,5D). Höjd kan representeras av en tredimensionell geometri, s k kropp (3D). I de fall mer yttäckande höjddatainsamling görs rekommenderas att resultatet uttrycks som en höjdmodell enligt geodataspecifikationen Höjd. För mer information om punkthöjder som referenshöjder se geodataspecifikationerna Höjd och Stompunkter. Det rekommenderas att inmätning av företeelser görs på deras högsta punkt (att attributet mätlägehögstapunkt på SG_GeometriMetadata sätts till True ) då läget på marken oftast kan fås av en höjdmodell. Detta förfarande medför att man i större utsträckning kan använda geometrin i frågeställningar som kräver 3D-representation av företeelser. Rekommendation 5 Företeelsers höjd ska mätas in på sin högsta punkt SG_Datamängd För att visa hur datamängder sätts ihop av objekttyper i teman inom samt för att visa hur metadata förhåller sig till en datamängd har en gemensam objekttyp för datamängd, SG_Datamängd, skapats (figur 14)

39 39 (145) Styrgruppen class SG_Datamängd «DataSet» SG_GemensammaKlasser:: SG_Datamängd + aktualitet :DateTime + sekretessad :Boolean = false +metadata Metadata entity set information::md_metadata Figur 14 SG_Datamängd. SG_Datamängd bär också en utökning av obligatorisk metadata i form av aktualitet samt information om datamängden är sekretessreglerad eller inte. SG_Datamängd håller samman datamängder av vektortyp och ingår därför inte i alla informationsmodeller för bild och höjd, med undantag av punktmoln, höjdpunkter, punkthöjder, brytlinjer och nivåkurvor Objekttyper SG_DataMängd SG_Datamängd visar hur metadata kopplas till datamängder. Attribut Multiplicitet aktualitet sekretessad Det datum datamängden senast befanns vara korrekt. Talar om huruvida en datamängd omfattas av sekretess. : Standardvärde är False [1..1] DateTime [1..1] Boolean Byggnad datamängd Det finns många datamängder i samhället som har information som kan knytas till byggnader. Nationell Byggnadsinformation med stabila unika identiteter gör det möjligt för andra myndigheter och organisationer att knyta sin information till en byggnad. Kommunerna har en central roll som ajourhållare av byggnadsinformationen.

40 40 (145) Styrgruppen Figur 15 Nuvarande och framtida samverkan. class Byggnad_Datamängd Aggregerad byggnad består av Fysisk byggnad består av Byggnad - byggnadsändamål - byggnadskaraktär består av Byggnadsdel - byggnadsändamål - geometri har Byggnadstillbehör - geometri Figur 16 Översikt för datamängd Byggnad Figur 16 visar översiktligt vad en datamängd med byggnadsdata enligt denna dataproduktspecifikation innehåller. Byggnad är huvudobjektet med nationell unik identitet. Byggnad består av byggnadsdelar där bl.a. attribut för geometrin finns. Fysisk byggnad sätts samman av Byggnader och Aggregerad byggnad sätts samman av Fysiska byggnader. Informationsmodellen

41 41 (145) Styrgruppen innehåller även ett antal attribut relaterade till tidsaspekter (nybyggnadsår, tillbyggnadsår, ombyggnadsår, rivningsår), topografisk/fysisk information (höjd, antal våningar, byggnadskaraktär) och klassificering enligt utseende och användning). I följande avsnitt beskrivs innehållet mer detaljerat. För att se en fullständig informationsmodell med alla klasser och attribut, se bilaga C Byggnad För att kunna möjliggöra objektorientering och distribuerade system utan stor central koordinering måste man vara överens om vad ett objekt omfattar och vad dess identitet är. Enligt PBL (2010:900) definieras byggnad som en varaktig konstruktion som består av tak eller av tak och väggar och som är varaktigt placerad på mark eller helt eller delvis under mark eller är varaktigt placerad på en viss plats i vatten samt är avsedd att vara konstruerad så att människor kan uppehålla sig i den. Utgående från byggnad enligt PBL har Lantmäteriet och kommunerna, i ABT-avtalen om samverkan om bl a byggnadsinformation, snävat in att en byggnad måste ligga i en och endast en 2D-fastighet/fastighetsområde. Som exempel måste en radhuslänga som är uppdelad i flera fastigheter också delas upp i flera byggnader med fastighetsgränsen som yttervägg - se figur 15. För 3D-fastigheter gäller andra regler. Följande varianter av byggnader är definierade i DPS Byggnad, version 1.0: a. Byggnad - dvs enligt ABT-avtal ovan b. Fysisk byggnad - en byggnadskonstruktion som hänger ihop över fastighetsgränser med gemensam byggnadsritning/infrastruktur t ex en radhuslänga över flera fastigheter c. Aggregerad byggnad flera fysiska byggnader som karterats som en enhet (förekommer vanligen i stenstaden med sammanhängande kvarter) Lantmäteriet har, för närvarande, endast variant a. byggnad (enligt ABT-avtal) som objekt och unika objektidentiteter på dessa. Skillnaden mellan b och c kan vara svår att tolka men utgår från om det är en eller flera byggnadskonstruktioner som karterats ihop.

42 42 (145) Styrgruppen Fysisk byggnad Förenklat kan sägas att objektet fysisk byggnad är en sammanhängande byggnad oberoende av fastighetsindelningen Figur 17 Fysisk byggnad som ligger på flera fastigheter. Geometrin för fysiska byggnaden genereras från Byggnad/Byggnadsdel. Alla fysiska byggnader som ligger i endast ett fastighetsområde är identiska med byggnad, vilket torde vara det vanligaste fallet idag Byggnadsdel En byggnad kan bestå av byggnadsdelar. En byggnadsdel är underindelning av en byggnad utifrån fysiska eller funktionella aspekter. Indelning i byggnadsdelar kan göras i både plan och höjd. Geometrin finns på byggnadsdelen och där finns även andra attribut som också kan finnas på hela byggnaden. Byggnadsdelen har en egen unik identitet. En byggnad med två byggnadsdelar. Figur 18 En byggnad kan bestå av byggnadsdelar. Figur 19 Indelning i byggnadsdelar utifrån olika höjd.

43 43 (145) Styrgruppen class Abstrakt_byggnad_del_fysisk_aggregerad SG_BasKlass «FeatureType» BY_AbstraktByggnad SG_BasKlass «FeatureType» BY_FysiskByggnad - /fysiskbyggnadgeometri - byggnadsändamål: BY_Byggnadsändamål [1..*] - namnbyggnadobjekt: BY_NamnByggnad [0..*] - status: BY_ByggnadStatus - nybyggnadsår: Date [0..1] - tillbyggnadsår: Date [0..*] - ombyggnadsår: Date [0..*] - rivningsår: Date [0..1] - antalvåningarövermark: Integer [0..1] - antalvåningarundermark: Integer [0..1] - höjd: BY_ByggnadHöjd [0..*] - höjdövermark: BY_HöjdÖverMark [0..*] - heltundermark: Boolean [0..1] - boarea: integer [0..1] - taktyp: BY_Taktyp [0..*] +beståravfysiskbyggnad 1..* SG_BasKlass «FeatureType» BY_AggregeradByggnad +beståravbyggnad 1..* «FeatureType» BY_Byggnad SG_BasKlass - /aggregeradbyggnadgeometri - byggnadsnummer: Integer [0..1] +harbyggnadsdel - undantagenfrånadressättning: Boolean [0..1] 1..* - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] «FeatureType» BY_Byggnadsdel - geometri2d: BY_ByggnadGeometri2D [0..*] - geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] - geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] - geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] Figur 20 Aggregerad byggnad - Fysisk byggnad Byggnad Byggnadsdel Klassen AbstraktByggnad är inte något eget byggnadsobjekt. Klassen är ett modelltekniskt sätt att beskriva vilka attribut som är gemensamma för både Byggnad och Byggnadsdel. Vissa attribut kan både finnas på byggnaden eller byggnadsdelen. Andra attribut kan endast finnas på byggnaden. Tabell 4 visar vilka attribut som kan finnas på byggnad respektive byggnadsdel. Tabell 4 Attribut på Byggnad och Byggnadsdel. Attribut på byggnad Attribut på byggnadsdel byggnadsnummer - undantagen från adressättning - belägen på oidentifierat område - byggnadskaraktär - byggnadsarea - ofri grund - byggnadsändamål namn status nybyggnadsår tillbyggnadsår ombyggnadsår byggnadsändamål namn status nybyggnadsår tillbyggnadsår ombyggnadsår

44 44 (145) Styrgruppen rivningsår rivningsår antal våningar över mark antal våningar under mark höjd höjd över mark helt under mark boarea taktyp antal våningar över mark antal våningar under mark höjd höjd över mark helt under mark boarea taktyp - geometri Aggregerad byggnad Flera fysiska byggnader som redovisas som en enhet benämns Aggregerad byggnad. Denna typ förekommer vanligen i stenstaden med sammanhängande kvarter Byggnadstillbehör Byggnadstillbehör är ofta mindre konstruktioner som är ihopbyggda med byggnaden. Byggnadstillbehöret sitter på byggnadsdelen och har egen identitet och geometri. på byggnadstillbehör är balkong och trappa. Byggnadstillbehör är vanliga i LoD0, men mindre vanliga i LoD1-2. Figur 21 på byggnadstillbehör.

45 45 (145) Styrgruppen class Byggnadstillbehör «FeatureType» BY_Byggnad BY_AbstraktByggnad SG_BasKlass - byggnadsnummer: Integer [0..1] - undantagenfrånadressättning: Boolean [0..1] - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] +harbyggnadsdel 1..* «FeatureType» BY_Byggnadsdel BY_AbstraktByggnad - geometri2d: BY_ByggnadGeometri2D [0..*] - geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] - geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] - geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] 1 +harbyggnadstillbehör 0..* «FeatureType» BY_Byggnadstillbehör SG_BasKlass - byggnadstillbehörtyp: BY_ByggnadstillbehörTyp - geometri2d: SG_Geometri [0..*] - geometri3d: SG_Geometri «codelist» BY_ByggnadstillbehörTyp - altan - balkong - brandmur - carport - förbindelsegång - lastbrygga - mast - skorsten - skärmtak - takfönster - takkupa - transportband - trappa - uterum Figur 22 En byggnadsdel kan ha byggnadstillbehör. Kodlistan beskriver vilka typer som finns Höjd En byggnad kan ha flera höjdvärden (höjd) som kan mätas vid olika lägen. Höjdläget ska beskrivas med attributet höjdläge genom att använda möjliga värden i kodlistan BY_HöjdLägeTyp t.ex. takkant eller takets högsta punkt. byggnadens högsta höjd takets högsta punkt generell takhöjd medelhöjd högsta skärning tak/fasad lägsta skärning tak/fasad högsta takkant lägsta takkant generell markhöjd

46 Styrgruppen 46 (145) byggnadens högsta höjd takets högsta punkt generell takkant entrénivå byggnadens lägsta punkt Figur 23 Höjdlägen. För mer information om höjdlägen se dokumentet Mätningsanvisningar. Det finns även ett attribut (höjdövermark) som redovisar differensen mellan höjd mätt vid ett högt höjdläge (t.ex. byggnadens högsta punkt, takkant) och en höjd mätt vid ett lågt höjdläge (t.ex. generell marknivå, färdigt golv, sockel). class Höjd «FeatureType» BY_AbstraktByggnad SG_BasKlass HÖJD - byggnadsändamål: BY_Byggnadsändamål [1..*] - namnbyggnadobjekt: BY_NamnByggnad [0..*] - status: BY_ByggnadStatus - nybyggnadsår: Date [0..1] - tillbyggnadsår: Date [0..*] - ombyggnadsår: Date [0..*] - rivningsår: Date [0..1] - antalvåningarövermark: Integer [0..1] - antalvåningarundermark: Integer [0..1] - höjd: BY_ByggnadHöjd [0..*] - höjdövermark: BY_HöjdÖverMark [0..*] - heltundermark: Boolean [0..1] - boarea: integer [0..1] - taktyp: BY_Taktyp [0..*] «FeatureType» BY_Byggnad - byggnadsnummer: Integer [0..1] - undantagenfrånadressättning: Boolean [0..1] - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] SG_BasKlass +harbyggnadsdel 1..* «FeatureType» BY_Byggnadsdel - geometri2d: BY_ByggnadGeometri2D [0..*] - geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] - geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] - geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] «DataType» BY_ByggnadHöjd - höjdläge: BY_HöjdLägeTyp - höjdvärde: DirectPosition «DataType» BY_HöjdÖv ermark - höjdvärde: Length - högstahöjdläge: BY_HöjdLägeTyp - lägstahöjdläge: BY_HöjdLägeTyp «codelist» BY_HöjdLägeTyp - byggnadens högsta punkt - takets högsta punkt - generell takkant - lägsta takkant - högsta takkant - generell skärning tak/fasad - lägsta skärning tak/fasad - högsta skärning tak/fasad - generell takhöjd medelhöjd - generell takhöjd 2/3 - generell takhöjd 1/3 - lägsta våning över mark - entrénivå - färdigt golv - sockel - generell markhöjd - byggnadens lägsta punkt - illustrativt läge - ospecificerat läge Figur 24 Det finns två attribut för höjd; höjd och höjdövermark.

47 47 (145) Styrgruppen på två olika höjddifferenser: BH1 = Generell takkant (H2) Generell markhöjd (Hmin) BH2 = Byggnadens högsta punkt (Hmax) Generell markhöjd (Hmin) Figur 25 Olika höjddifferenser Plan Läget där plankoordinaterna registreras ska beskrivas med attributet planläge. fasad/fotavtryck takkant Figur 26 Planlägetyper Figur 27 Kodlista med planlägetyper. Illustrativt läge innebär att byggnaden representeras med schablongeometri.

48 48 (145) Styrgruppen Klassificering Klassificering sker med två attribut: Byggnadsändamål hänvisar till byggnadens användning (t.ex. bostad, samhällsfunktion eller industri). I Bilaga D finns kodlistan för SG Byggnadsändamål. Kodlistan är hierarkiskt indelad i två nivåer; Översiktlig nivå och Detaljerad nivå. Informationsmodellen möjliggör att ett eller flera ändamål kan anges på hela byggnaden eller på enstaka byggnadsdelar. Byggnadskaraktär används för att beskriva att byggnaden har en till utseendet speciell karaktär t.ex. slott, herrgård. Ett syfte med byggnadskaraktär är att man kartografiskt vill kunna redovisa byggnaden med en särskild symbol. Figur 28 Kodlista med värden för Byggnadskaraktär Extern referens Attributet externreferens syftar till att möjliggöra länkning till andra informationssystem. Attributet innehåller objektets identifierare i det andra systemet. på tilllämpningkan vara länkning till byggnadens namn i Ortnamnsregistret. Om 2D-representation och 3D-representation av samma byggnad lagras i olika datamängder kan extern referens används för att länka objektet i 2D med objektet i 3D gällande samma byggnad. Idag används denna typ av koppling till Skatteverkets taxerings- och värderingsenheter. Den framtida inriktningen ska dock vara att byggnadens identitet enligt denna specifikation används för att sammanlänka information om byggnader i olika system.

49 Styrgruppen 49 (145) class Extern referens «DataType» SG_ExternReferens + id: CharacterString «FeatureType» SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime +refereartillbasklass 0..* 0..* «conceptual» Externt informationssystem BY_AbstraktByggnad «FeatureType» BY_Byggnad - byggnadsnummer: Integer [0..1] - undantagenfrånadressättning: Boolean [0..1] - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] Figur 29 Länkning mellan byggnad och andra informationssystem.

50 50 (145) Styrgruppen Geometrier allmänt Byggnaders geometriska representation kan vara antingen 2D, 2,5D eller 3D. Byggnadsinformation finns med flera olika detaljeringsnivåer både när det gäller geometri och andra egenskaper. Geometrityper som förekommer är punkt, linje, yta och kropp. Den vanligaste representationen är 2D-ytor insamlade i byggnadens takkant eller fasad (fotavtryck). 3D beskrivs ofta med OGC-standarden CityGML som indelas i detaljeringsnivåerna (Level of Details) LoD0-LoD4. Denna specifikation omfattar t.o.m. LoD3, vilket innebär att byggnaden endast betraktas utifrån. LoD0 LoD1 LoD2 LoD3 LoD4 Byggnaden är avbildad som en yta dvs. som i en traditionell 2D-karta. 2,5-D (höjdsatt yta) flygande tak (takkant) eller fotavtryck (fasad) på marken 3D-data (volym) i form av en låda. Den horisontella takytan kan avse olika höjder, från byggnadens högsta punkt till lägsta takkant, beroende på ändamål. 3D-data med förenklad tak- och fasadrepresentation. 3D-data med detaljerad tak- och fasadrepresentation där även struktur ingår. Detaljerad beskrivning av exteriör t.ex. skorstenar, takkupor, fönster och dörrar. 3D-data som även beskriver byggnaden invändigt. LoD4 ingår inte i denna specifikation. Varje LoD kan i sin tur konstrueras på olika sätt och ge olika varianter av byggnadsmodeller med olika egenskaper. Det är viktigt att med attribut beskriva vilken variant av en LoD-nivå som avses för varje enskild byggnadsmodell så att den kan användas på ett korrekt sätt. Det förekommer olika detaljeringsgrad på tak och fasad, s k LoD2-3 hybrider. LoD4 med invändig geometri är, än så länge, ovanlig i Geodata/GIS-sammanhang.

51 51 (145) Styrgruppen LoD0 Byggnadens yta i 2D, i form av ett fotavtryck (se röd linje i bilderna ovan), kan i LoD0 ha följande planläge: a. Fasad, dvs ett korrekt fasadläge b. Takkant, dvs ett fiktivt fasadläge som ger en för stor fasadutbredning Inmätning och konstruktion Variant a mäts vanligen in geodetiskt men kan även konstrueras ur ett punktmoln från t ex terrester eller fordonsburen laserskanning. Variant b kan mätas in fotogrammetriskt i lodbilder alternativt konstrueras ur ett punktmoln från flygburen laserskanning eller flygfotografering. Fotavtryck kan också härledas ur befintliga LoD1, LoD2 eller LoD3 modeller. Byggnader kan mätas in som flera byggnadsdelar baserat på olika takhöjd om så önskas. Det kan vara aktuellt om man indirekt vill visa att taken hos de olika byggnadsdelarna ligger på olika höjd. Användningsområden Framställning av 2D-kartor av olika slag (Fasad variant a och b). Fastighetsbildning (Fasad variant a). Fotnot: 2,5D LoD0 kan avse ytor i 3D, dvs en yta där varje brytpunkt även har ett höjdvärde i tillägg till plankoordinaterna. När en yta i 3D beskriver något som egentligen är en volym i 3D så kallas det i många sammanhang för 2,5D. Ett exempel är att vid fotogrammetrisk mätning av takytterkant erhålls även höjder i takkantens brytpunkter i plan, se röda linjen i bilden nedan. 2,5D beskrivningen sparas vanligen även om den bara ska användas för 2D-presentation av fotavtryck (gul linje i bilden nedan) eftersom den underlättar vid framtida fotogrammetrisk ajourhållning.

52 Styrgruppen 52 (145) LoD1 LoD1 avser byggnader representerade med horisontellt tak. Byggnadsmodeller av samma hus i LoD1 kan göras i ett stort antal varianter enligt bilden ovan. Väggytan i LoD1 kan ha följande planläge: a. Fasad, dvs ett korrekt fasadläge b. Takkant, dvs ett fiktivt fasadläge konstruerat lodrätt från takkant till DTM som ger en för stor fasadutbredning För LoD1 finns följande varianter för takets höjdläge: a. Generell takkant b. Lägsta takkant (används om takkanten har olika höjdvärden) c. Högsta takkant (används om takkanten har olika höjdvärden) d. Generell skärning skärningspunkt mellan tak och fasad e. Lägsta skärningspunkt mellan tak och fasad (används om olika höjdvärden) f. Högsta skärningspunkt mellan tak och fasad (används om olika höjdvärden) g. Generell takhöjd, tre olika varianter förekommer I. Takets medelhöjd (vanligast när höjd sätts ur laserpunktmoln och sammanfaller ofta med takets medianhöjd) II. 2/3-del av takets höjd III. 1/3-del av takets höjd h. Takets högsta punkt i. Byggnadens högsta punkt (t ex toppen av en skorsten) Även byggnadens bottenyta, dvs undre horisontella yta, kan ha olika höjdläge: a. Nivån för lägsta våning över markytan b. Entrénivå c. Generell markhöjd (vanligen tas höjd fram för en fiktiv bottenyta genom att ur en DTM interpolera fram fotavtryckets lägsta markhöjd) d. Byggnadens lägsta punkt (dvs bottenytan korrekta höjdläge, t ex källargolv)

53 53 (145) Styrgruppen Om en byggnads olika delar har stor höjdskillnad - t ex en kyrka - kan det vara aktuellt att mäta in byggnaden i olika byggnadsdelar. Varje byggnadsdel får en egen horisontell takhöjd för så att en mer realistisk modell kan tas fram. Inmätning och konstruktion LoD1 kan tas fram genom att komplettera en LoD0 modell med ett höjdvärde för det horisontella taket. Vid geodetisk inmätning av fasad kan ett generellt höjdvärde för takkant mätas separat (tak variant a). Vid fotogrammetrisk mätning av takkant kan höjdvärdet härledas ur den skapade 2,5D-polygonen (tak variant a, b eller c). Höjdvärdet kan också beräknas ur ett punkmoln från flygburen laserskanning eller flygbilder (tak variant g). Bottenytans höjd tas vanligen fram som en fiktiv bottenyta genom att ur en DTM interpolera fram fotavtryckets lägsta markhöjd (bottenyta variant c) Höjdvärden för tak och bottenyta kan också härledas ur befintliga LoD2 eller LoD3 modeller. Användningsområden Lämplig för översiktliga visualiseringar av landskap och stadsmiljö (tak variant g) och vid fastighetsbildning (vägg variant a) på enkla analyser är siktanalyser längs marken (vägg variant a), energiförbrukning (vägg variant a, tak variant e), buller (tak variant a), solpaneler på fasaden (tak variant a), skuggor (tak variant g), vågutbredning telefoni (tak variant h) och översvämning LoD2 a b c I princip finns tre grundmodeller att översiktligt beskriva en byggnad i LoD2 på. Huset längst till vänster i figuren ovan visar en byggnad i genomskärning. Sedan följer tre varianter av byggnadsmodell markerat med kraftigare blå linje. a. Hus med korrekt fasadläge men för liten takutbredning LoD2F b. Hus med korrekt takläge men för stor fasadutbredning LoD2T c. Hus med korrekt fasad- och takläge LoD2TF

54 54 (145) Styrgruppen Inmätning och konstruktion LoD2 variant - på inmätning+konstruktion - Resultat a. Hus med korrekt fasadläge men för liten takutbredning. - Fotavtryck kan tas fram med geodetiskt inmätt fasadläge. Innanför fotavtrycket kan tak rekonstrueras med hjälp av punktmoln från laser eller fotogrammetri och programvara med standardiserade takkonstruktioner. Sedan kan väggytor konstrueras lodrätt upp från DTM till taket. - Resultatet blir att husets volym blir korrekt men att eventuellt taköverhäng saknas eftersom taket klipps vid fasad. b. Hus med korrekt takläge men för stor fasadutbredning. - Takets utformning mäts och konstrueras först genom fotogrammetrisk mätning sedan kan fotavtryck och väggytor konstrueras lodrät från takkanten ner till DTM. - Resultatet blir att husets volym blir överskattat. Om detaljer som dörr och fönster eller textur ska läggas på fasaden kan också det bli svårt att få det korrekt eftersom fasaden ligger i fel läge. c. Hus med korrekt fasad- och takläge. - Både fasadläge och taket mäts in. Väggytor lyfts från fotavtryck och DTM till insidan tak. Både fasad och tak kan mätas geodetiskt eller ur punktmoln framtaget från både marken och luften. Vanligast idag är geodetiskt inmätt fasad och fotogrammetriskt inmätt tak. - Resultatet blir en byggnad med korrekt volym och taköverhäng. Om inmätningstekniker med olika lägesosäkerhet används - t ex geodetiskt inmätt fotavtryck av fasaden och fotogrammetriskt mätning av taket - kan problem uppstå, t ex att en takkant hamnar innanför fotavtrycket. Denna variant kan också härledas ur byggnadsritningars (LoD3) och inpassas i korrekt geografiskt läge. Det är tillåtet med takkupor i LoD2 men inte obligatoriskt. Bottenytans höjdläge tas vanligen fram på samma sätt som LoD1.

55 55 (145) Styrgruppen Användningsområden Ger mer realistiska visualiseringar än LoD1 av landskap och stadsmiljö och vid fastighetsbildning (vägg variant a). Ger bättre analyser för de flesta exempel under LoD1 samt en förutsättning för planering av solpaneler på tak LoD3 inklusive LoD2-3 hybrider a. b. c. d. LoD3 är en principiell arkitekturritning sett från utsidan och avser hus med korrekt fasad- och takläge, dvs taköverhäng är med. Det är tillåtet med tillägg av detaljer som ger hål i byggnaden - men inte obligatoriskt - t ex takkupor, takfönster, skorsten, master på taket och t ex fönster, dörrar, balkong på fasaden. Om LoD3 framställs genom inmätning handlar det i praktiken ofta om s k LoD3-hybrider där väggarna eller taket är LoD2 a. LoD2-3 hybrid - översiktlig fasad enligt LoD2 variant b och detaljerat tak enligt LoD3 b. LoD2-3 hybrid - detaljerad fasad enligt LoD3 och översiktligt tak enligt Lod2. c. LoD3 - utan dörr- och fönstersmyg, balkongräcken. d. LoD3 - med dörr- och fönstersmyg, balkongräcken Inmätning och konstruktion Variant a kan t ex tas fram vid stereokartering i flygbilder. Variant b kan t ex tas fram med fordonsburen eller terrester laserskanning. För variant a och b tas bottenytans höjdläge vanligen fram på samma sätt som för LoD1. Variant c och d härleds oftast fram ur befintliga arkitekturritningar, BIM- eller CAD-modeller. Bottenytans höjdläge kan då avse faktiskt läge. Variant c och d kan även mätas in, genom att t ex kombinera markburen- och flygburen laserskanning. Förfarandet är dyrbart och görs vanligen endast för enstaka signaturbyggnader i stadsmiljö. Användningsområden Lämplig för högkvalitetsvisualisering över mindre områden vid t ex stadsplanering, nyexploatering/bygglov, räddningstjänst (var finns dörr och fönster) samt VR-applikationer. Dörrar och fönster ger bättre analyser av energiförluster. Fönster ger möjlighet till analyser av dagsljusinsläpp och insyn.

56 56 (145) Styrgruppen LoD4 LoD4 är en principiell arkitekturritning sett från både utsidan (samma som LoD3) och insidan. Insidan kan i sin tur framställas i ett antal olika detaljeringsgrader, t ex enkla våningsplan eller lägenheter. LoD4 ingår inte i denna specifikation. Inmätning och konstruktion Härleds oftast fram ur befintliga arkitekturritningar, BIM- eller CAD-modeller. Bottenytan avser faktiskt höjdläge. Modellen kan även mätas in, genom att t ex kombinera markburen- och flygburen laserskanning utvändigt samt terrester laserskanning invändigt. Förfarandet är dyrbart och görs vanligen endast för enstaka signaturbyggnader i stadsmiljö. Användningsområden Lämplig för högkvalitetsvisualisering för räddningstjänst (inomhusnavigering), 3D-fastighetsbildning samt VR-applikationer. Generalisering I standarden för CityGML ges inga gränsvärden när olika detaljer ska vara med eller inte. Här ges förslag på gränsvärden baserade på empiriska undersökningar i några städer i Europa. a. Storlek på byggnadsdel - LoD0, LoD1 och LoD2 a. >4 m, 10 m² alternativt >2 m, 4 m² beroende på syfte b. Höjdskillnad på tak för att dela in i byggnadsdelar LoD0, LoD1 och LoD2 a. >2 m c. Storlek på taköverhäng LoD3 (och LoD2 om sådan önskas) a. >0,2 m d. Storlek på takkupa eller liknande LoD3 (och LoD2 om sådan önskas) a. >2 m, 2 m² e. Höjd på skorsten LoD3 a. >1 m f. Storlek på takfönster och fönster LoD3 a. >1 m, 1 m² g. Storlek på balkong LoD3 a. >1 m h. Storlek på fönstersmyg och andra detaljer LoD3 om så önskas a. >0,2 m i. Även storlek på byggnad brukar ha ett gränsvärde som kan vara olika beroende på tillämpning.

57 57 (145) Styrgruppen Textur Med textur avses en bild som läggs utanpå varje geometrikomponent för att ge ett visst utseende. Det kan göras med fiktiva bilder eller med aktuella fotografier för att få en mer fotorealistisk 3D-modell. För att få bästa resultat med fotografier behöver tak och väggar ligga i korrekt läge samt att eventuella fotografiska bilder är rektifierade så att de blir skalenliga D-Byggnad i sitt sammanhang Figur 30 3D-byggnad i sitt sammanhang från insamling till tillhandahållande. Syftet med DPS Byggnad i är ytterst att ta fram en svensk de-facto standard för utbytesmodell - import och export av byggnadsinformation mellan olika aktörer ur ett geodata/gis perspektiv, t ex insamlare till databasägare, databasägare till användare, användare till annan användare osv. Datautbytesmodellen (XML) är framtagen utifrån informationsmodellen (UML). Utbyte kan ske till och från databasägarens datalager i ett visst system (röda pilarna). I mätanvisningarna specificeras hur företeelsen i verkligheten ska representeras geometriskt (geometrityp, planläge, höjdläge) i utbytet.

58 58 (145) Styrgruppen Lagring En 3D-byggnadmodell kan i princip lagras på följande sätt: a. i en färdigt sammansatt 3D-modell (så kallad solid) b. i 3D-modellens alla olika delkomponenter var för sig, t ex fotavtryck, väggar, tak, takdetaljer, fasaddetaljer (så kallad multi surface) c. i ett minimum av delkomponenter (som behövs för att vid leveransen konstruera en 3D-modell av önskad detaljeringsgrad med hjälp av en DTM och ett eventuellt fotavtryck) Leverans Med lagring variant a kan endast en modell identiskt med den lagrade levereras. Med lagring variant b tas olika byggnadsmodeller fram vid leveransen beroende användarbehoven. Olika detaljeringsgrader kan väljas beroende på behoven. I många tilllämpningar räcker enklare varianter av byggnader. Man kan undvika parallellagring av samma byggnad i olika detaljeringsgrader. Med lagring variant c minskas det lagringsutrymme som krävs. Ett exempel kan vara att spara fotogrammetriskt inmätta flygande tak i 3D och vid leverans skapa ett fotavtryck lodrätt från takkant till DTM samt väggar.

59 59 (145) Styrgruppen Ett annat exempel av variant c kan vara att spara fotogrammetriskt inmätta flygande tak i 3D och geodetiskt inmätta fotavtryck. Vid leverans kan ett fotavtryck skapas lodrätt från takkant till DTM samt väggar alternativt kan det befintliga fotavtrycket användas till att skapa väggar i korrekt läge samt taköverhäng. Leveransformat Några vanliga 3D leveransformat är: a. CityGML b. KML /KMZ c. Collada d. Shape e. DXF f. IFC

60 60 (145) Styrgruppen Geometrier i informationsmodellen För den geometriska representationen av byggnaden finns attributet geometri2d för 2D och 2.5D-redovisning med en eller flera ytor. För 3D-redovisning finns attributen geometri3dlod1, geometri3dlod2, geometri3dlod3 för de olika detaljeringsnivåerna LoD1-3. För LoD3 ingår då även detaljer på tak som skorsten och takkupor. Attrubuten antalvåningarövermark, antalvåningarundermark, höjd och höjdövermark ger indirekt information om byggnadens höjd. class Geometri «FeatureType» BY_Byggnadsdel BY_AbstraktByggnad - geometri2d: BY_ByggnadGeometri2D [0..*] - geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] - geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] - geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] «DataType» BY_ByggnadGeometri2D - geometri: SG_Geometri - planläge: BY_PlanLägeTyp - höjdläge: BY_HöjdLägeTyp [0..1] «DataType» BY_ByggnadGeometri3DLoD - geometrimultiyta: SG_Yta [0..1] - geometrikropp: SG_Kropp [0..1] - terrängskärning: SG_Linje [0..1] - höjdläge3dbotten: BY_HöjdLägeTyp [0..1] «DataType» BY_ByggnadGeometri3DLoD1 - planläge: BY_PlanLägeTyp [0..1] - höjdläge3dtopp: BY_HöjdLägeTyp [0..1] «DataType» BY_ByggnadGeometri3DLoD2 - planläge: BY_PlanLägeTyp [0..1] Figur 31 Attribut för geometrisk representation. Multipla geometrier är tillåtna. En byggnad kan representeras med en punkt, linjer, en eller flera ytor t.ex. bottenyta och takyta. 2D 2D och 2,5D: Läget där plankoordinater mäts ska dokumenteras med attributet planläge Läget där Z-koordinaten mäts ska dokumenteras med attributet höjdläge (se figur X)

61 61 (145) Styrgruppen 3D Det är möjligt att t.ex. - Ha en LoD-nivå för alla byggnader i en datamängd - LoD1 för några och LoD2 eller LoD3 för några byggnader i en datamängd. - Ha flera representationer för samma byggnad t.ex. en i LoD2 och en i LoD3 Informationsmodellen föreskriver att byggnaden representeras av minst en av LoD-nivåerna som kropp eller multi-yta. Om kropp väljs är byggnaden eller byggnadsdelen sammansatt av slutna icke överlappande ytor. Fördelen är att en volym kan beräknas (a). I praktiken finns sällan sådana toplogiskt perfekta modeller. Så är t.ex. fallet om byggnaden mäts fotogrammetriskt och bottenytan saknas. För dessa fall tillåts en representation med multiytor (b). En byggnad kan bestå av flera sammansatta ytor (multiyta/multisurface/) eller en enhetlig volym (kropp/solid). Med multisurface kan olika attribut sättas på de olika ytorna medan en solid endast kan ha attribut på hela byggnaden.

62 Styrgruppen 62 (145) class Begränsningsytor «FeatureType» BY_Byggnadsdel BY_AbstraktByggnad - geometri2d: BY_ByggnadGeometri2D [0..*] - geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] - geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] - geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] 1 +harbyggnadstillbehör 0..* «FeatureType» BY_Byggnadstillbehör SG_BasKlass - byggnadstillbehörtyp: BY_ByggnadstillbehörTyp - geometri2d: SG_Geometri [0..*] - geometri3d: SG_Geometri 0..* 0..* SG_BasKlass «FeatureType» BY_Öppning - geometri3d: SG_Yta +Öppning 0..* +byggnadsdelbegränsasav 0..* 0..2 SG_BasKlass «FeatureType» BY_Begränsningsyta - geometri3d: SG_Yta +byggnadstillbehörbegränsasav 0..* «FeatureType» BY_Dörr «FeatureType» BY_Fönster «FeatureType» BY_Takyta «FeatureType» BY_Bottenyta «FeatureType» BY_SkymdGolv yta «FeatureType» BY_SkymdTakyta «FeatureType» BY_Väggyta «FeatureType» BY_Stängningsyta Figur 32 Olika typer av begränsningsytor med öppningar. Begränsningsyta avser de delar som bygger upp ett hus se bild nedan. Öppning avser fönster och dörrar i väggytan i LoD3 Figur 33 Begränsningsytor Bottenytan är vanligen fiktiv och konstrueras som ett fotavtryck av fasaden dvs en horisontell yta med höjd satt där markytan är som lägst runt byggnaden.

63 63 (145) Styrgruppen En byggnad kan bestå av följande delar (om vi betraktar den utifrån) Bottenyta (vanligen horisontellt fotavtryck) kan vara i fasadläge och/eller takkantsläge Tak kan vara horisontalt plan (lod1) och i plan vara i fasadläge eller takkantläge enligt ovan i höjd avse lägsta takkant och takets högsta punkt eller annan höjd) takkonstruktion (lod2) och Skorsten, kupor takdetaljer som är byggnadstillbehör i 3D Vägg kan vara i fasadläge eller takkantsläge och ha Dörr och fönster fasaddetaljer som avser hål i fasaden i 3D Balkong fasaddetaljer som är byggnadstillbehör i 3D Byggnadstillbehör - skärmtak, trappa Som tillägg till representationen av en byggnad med begränsningsytor finns skärningen med terrängen representerad som en linje. För detta används attributet terrängskärning. Figur 34 Terrängskärningen redovisas i svart. För alla LoD-nivåer ska nivån som representerar bottenytan dokumenteras genom attributet höjdläge3dbotten och något värde från kodlistan med höjdlägetyper. Vid LoD1 och LoD2 är byggnadens representation generaliserad. Därför ska planläget dokumenteras. Punktreferens är inte tillåtet för 3D. Det planläget är inte nödvändig för LoD3 eftersom 3D-geometrin ska representera den exakta och detaljerade formen av byggnaden. Därför finns attributet bara för LoD1 och Lod2. Vid LoD1 ska nivån som använts för att representera toppytan dokumenteras med attributet höjdläge3dtopp. Något av följande värden ska användas: takkant,.. Denna information är inte nödvändig för andra LOD-nivåer där byggnaden representeras av dess takform. Därför finns attributet endast för LoD1.

64 64 (145) Styrgruppen Taktyp Det finns ett antal olika taktyper fördefinierade t.ex. sadeltak, brutet tak.. Figur 35 på olika taktyper Namn Koppling till Ortnamnsregistret kan ske via ExternReferens från SG_BasKlass. Innan sådan koppling är möjlig kan ett särskilt namnattribut användas. class Namn «DataType» SG_ExternReferens + id: CharacterString «FeatureType» SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime «FeatureType» BY_AbstraktByggnad - byggnadsändamål: BY_Byggnadsändamål [1..*] - namnbyggnadobjekt: BY_NamnByggnad [0..*] - status: BY_ByggnadStatus - nybyggnadsår: Date [0..1] - tillbyggnadsår: Date [0..*] - ombyggnadsår: Date [0..*] - rivningsår: Date [0..1] - antalvåningarövermark: Integer [0..1] - antalvåningarundermark: Integer [0..1] - höjd: BY_ByggnadHöjd [0..*] - höjdövermark: BY_HöjdÖverMark [0..*] - heltundermark: Boolean [0..1] - boarea: integer [0..1] - taktyp: BY_Taktyp [0..*] «DataType» BY_NamnByggnad + namn: CharacterString + namntyp: BY_NamnByggnadTyp + fastställare: BY_NamnByggnadFastställare + huvudnamn: Boolean «codelist» BY_NamnByggnadTyp + godkänt byggnadsnamn + föreslaget byggnadsnamn + övrigt byggnadsnamn «codelist» BY_NamnByggnadFastställare + Kommun + Lantmäteriet Figur 36 Namn på byggnad.

65 Styrgruppen 65 (145) Övriga Attribut På både Byggnad och Byggnadsdel class Övriga Attribut SG_BasKlass SG_BasKlass «FeatureType» BY_ByggnadInformation::BY_AbstraktByggnad - byggnadsändamål: BY_Byggnadsändamål [1..*] - namnbyggnadobjekt: BY_NamnByggnad [0..*] - status: BY_ByggnadStatus - nybyggnadsår: Date [0..1] - tillbyggnadsår: Date [0..*] - ombyggnadsår: Date [0..*] - rivningsår: Date [0..1] - antalvåningarövermark: Integer [0..1] - antalvåningarundermark: Integer [0..1] - höjd: BY_ByggnadHöjd [0..*] - höjdövermark: BY_HöjdÖverMark [0..*] - heltundermark: Boolean [0..1] - boarea: integer [0..1] - taktyp: BY_Taktyp [0..*] «FeatureType» BY_ByggnadInformation::BY_Byggnad - byggnadsnummer: Integer [0..1] - undantagenfrånadressättning: Boolean [0..1] - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] SG_BasKlass «FeatureType» BY_ByggnadInformation::BY_Byggnadsdel - geometri2d: BY_ByggnadGeometri2D [0..*] +harbyggnadsdel - geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] - geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] 1..* - geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] Figur 37. Övriga byggnadsattribut. Byggnadsändamål Namn Status Nybyggnadsår, Tillbyggnadsår, Ombyggnadsår, Rivningsår AntalVåningaÖverMark, AntalVåningaUnderMark Helt under mark Boarea Taktyp Endast på Byggnad Byggnadsnummer UndantagenfrånAdressättning Belägen på oidentifierat område Byggnadskaraktär Byggnadsarea Ofri grund

66 Styrgruppen 66 (145) Relationer Registerenhet (fastighet eller samfällighet) class Registerenhet «conceptual» Registerenhet «conceptual» Enhetsutrymme +liggerpå 1 +tillhör berörsav 0..* 0..* 0..* «FeatureType» BY_Byggnad BY_AbstraktByggnad SG_BasKlass - byggnadsnummer: Integer [0..1] - undantagenfrånadressättning: Boolean [0..1] - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] Figur 38 Relationer mellan byggnad och registerenhet. Adress class Adress «FeatureType» BY_Byggnad BY_AbstraktByggnad SG_BasKlass - byggnadsnummer: Integer [0..1] - undantagenfrånadressättning: Boolean [0..1] - knkodoidentifieratområde: Integer [0..1] - byggnadskaraktär: BY_Byggnadskaraktär [0..1] - byggnadsarea: Integer [0..1] - ofrigrund: Boolean [0..1] +hörtill 1 «conceptual» Entré +nås via 1 +har 0..1 «conceptual» Adressplats «conceptual» Lägenhet Figur 39 Relationer mellan byggnad, adress och lägenhet Objekttypskatalog Se bilaga G.

67 67 (145) Styrgruppen 6 Referenssystem Information om det geodetiska referenssystemet för Byggnadsdata ska anges, referenssystem enligt Fel! Hittar inte referenskälla. är tillåtna (se Fel! Hittar inte referenskälla. för utbredning av referenssystem). Transformation till andra referenssystem eller överräkning till andra projektionszoner ska ske med Gtrans eller annan programvara som innehåller godkända algoritmer. Tabell 5. Tillåtna referenssystem Geodetiskt referenssystem EPSG-kod EPSG:3006 EPSG:3007 EPSG:3008 EPSG:3009 EPSG:3010 EPSG:3011 EPSG:3012 EPSG:3013 EPSG:3014 EPSG:3015 EPSG:3016 EPSG:3017 EPSG:3018 EPSG:5613 EPSG:5846 EPSG:5847 EPSG:5848 EPSG:5849 EPSG:5850 EPSG:5851 EPSG:5852 EPSG:5853 EPSG:5854 EPSG:5855 EPSG:5856 EPSG:5857 Benämning SWEREF 99 TM SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 Se figur 39 för en karta med de lokala SWEREF 99-zonerna. Temporalt referenssystem Gregorianska kalendern UTC ±0 UTC +1 normaltid (CET) UTC +2 sommartid (CEST)

68 Styrgruppen 68 (145) Referenssystemets omfattning Data enligt omfattning A, B, B1, B2, B3, C, C1 görs i referenssystem SWEREF 99, kartprojektion SWEREF 99 TM (EPSG:3006) och höjdsystem RH 2000 (EPSG:5613). Data enligt delomfattning B4, B5, B6 och C2 görs antingen i referenssystem SWEREF 99, kartprojektion SWEREF 99 TM (EPSG:3006) och höjdsystem RH 2000 (EPSG:5613) eller i RH 2000 i höjd samt lokal zon av referenssystem i plan (EPSG:3007 EPSG:3018, EPSG:5846 EPSG:5857) Krav 22. Datamängder enligt denna specifikation ska tillhandahållas med referenssystem Sweref 99 TM och RH Figur 40 Rekommenderade lokala SWEREF-zoner för kommuner.

69 69 (145) Styrgruppen Tabell 6. Benämning på plankoordinater. Koordinatsystem Nordlig koordinat (Northing) Östlig koordinat (Easting) SWEREF 99 N E RT 90 x y I RH 2000 benämns höjden över havet (Normaal Amsterdam Peil) med H. För ytterligare beskrivning av höjd se motsvarande kapitel i geodataspecifikation Stompunkter. 7 Kvalitetskrav 7.1 Datakvalitet Fel! Hittar inte referenskälla. anger datakvalitetskrav för Byggnadsdata. Referenser inom parentes anger tabeller och Id i bilaga D i ISO för vilka kvalitetsmått som ska användas vid redovisning av datakvalitet. I HMK Geodatakvalitet beskrivs utförligare teori och terminologi rörande geodatakvalitet samt exempel på metoder för kvalitetsutvärdering. Tabell 7. Datakvalitetskrav N r Kvalitetstema Kvalitets-parameter Kvalitetsmått 1 Fullständighet Datamängdens innehållsmässiga överensstämmelse med gedataspecifikationen; brist eller övertalighet för objekt, attribut eller relationer. 2 Fullständighet Datamängdens innehållsmässiga överensstämmelse Brist För få Övertalighet För många Delomfattning A-C Hela dataprodukten Fullständighet avseende byggnad beroende på värdet i attributet byggnadsändamål. För Byggnad med byggnadsändamål bostad, industri, verksamhet och samhällsfunktion är kravet % beroende på delomfattning (se nedan Ingående omfattningar ) och på vilken metod/process som kommunerna och Lantmäteriet använder vid insamlingen. För byggnad med byggnadsändamål ekonomibyggnad finns inget krav på fullständighet. Omfattning A Övertalighet ska inte förekomma, men beroende på delomfattning (se

70 Styrgruppen 70 (145) med geodataspecifikationen; brist eller övertalighet för objekt, attribut eller relationer. 3 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). 4 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer. (till exempel sammanhängande nätverk och slutna ytor). 5 Lägesosäkerhet Noggrannhet/mätosäkerhet i position. Konceptuell konsistens Giltiga kombinationer av värden, som stämmer med informationsmodellen. Domän-konsistens Giltig värdemängd. Absolut osäkerhet I förhållande till referenssystemet. nedan Ingående omfattningar ) och på vilken metod/process som kommunerna och Lantmäteriet använder vid insamlingen så är kravet satt till 3-4 %. Omfattning A 100 % av förekomsterna ska överensstämma med informationsmodellen. (D.13, Id 13). Omfattning A 100 % av förekomsterna ska överensstämma med värden i kodlistor. (D.17, Id 17). HMK-standardnivåer Global/ nationell bevakning av miljö och naturvård Nationell/ regional över-siktlig planering Detaljplanering av tätort 1m 1m 0,1 m 3 Projektering och byggande av infrastruktur och byggnader 0,05 m 6 Tematisk noggrannhet Noggrannhet hos kvantitativa (mätbara) attribut och huruvida kvalitativa (icke mätbara) attribut och klassificeringar är korrekta. Ingående omfattningar Domänkonsistens Giltig värdemängd. Omfattning A 100 % av förekomsterna ska överensstämma med Byggnader kodlista, Bilaga D. Omfattning A Hela dataprodukten Delomfattning B - Aktualitet Delomfattning B1 Lantmäteriet periodiskt - Ajourhållningsintervall 2 år Delomfattning B2 Lantmäteriet periodiskt - Ajourhållningsintervall 4-6 år Delomfattning B3 Lantmäteriet periodiskt - Ajourhållningsintervall 10 år Delomfattning B4 Kommun kontinuerligt - Bygglovsprocessen Delomfattning B5 Kommun - Vid behov Delomfattning B6 Kommun periodiskt Olika ajourhållningsintervall

71 Styrgruppen 71 (145) Delomfattning C Geometrisk representation Delomfattning C1 Lantmäteriet Geometrisk representation Delomfattning C2 Kommun Geometrisk representation 8 Metadata Metadata anges på datamängdsnivå enligt den nationella metadataprofilen (aktuell version). För detaljplanering, fastighetsbildning och bygglovshantering är aktualitet en mycket viktig parameter. Aktualitet betraktas i många fall som ett datakvalitetselement, dock inte i ISO Eftersom denna DPS använder ISO för att beskriva datakvalitet hanteras aktualitet som en del av metadata som inte avser datakvalitet. Metadata kan också anges på objektnivå framförallt när det gäller geometrier (se kapitel ). Krav 25. anges. Aktualitet för datamängder enligt denna geodataspecifikation ska Krav 26. Specifikationsuppfyllelse ska anges i metadata för datamängd enligt denna geodataspecifikation. 9 Tillhandahållande Detta kapitel innehåller rekommenderade sätt för att tillhandahålla datamängder enligt denna specifikation. De rekommenderade formaten och leveransmedierna är de som kommer att kunna testas i samband med framtagandet av specifikationen. Användande av andra sätt för tillhandahållande sker utifrån överenskommelse mellan leverantör och mottagare. Det är framförallt aktuella data som ska tillhandahållas via de medium och format som anges i detta kapitel. Historiska data kan med fördel följa denna specifikation men åtkomst behöver inte vara allmän utan kan göras utifrån specialiserade anrop till en tjänst eller via beställning av datauttag från ansvarig part. 9.1 Leveransmedium Leveransmedium WFS Indelnings-alternativ Medium Geografiska områden utifrån behov (Web Feature Service)

72 72 (145) Styrgruppen Leveransmedium WMS Indelnings-alternativ Medium Geografiska områden utifrån behov (Web Map Service) 9.2 Leveransformat Leveransformat GML Beteckning GML (Geography Markup Language) Version Leverantör och mottagare kommer överens om version Specifikation - Filstruktur - Språk Svenska Teckenuppsättning Utf Leveransformat Bild (för WMS) Beteckning : Bitmap (rastergrafik) PNG (rastergrafik) Gif (rastergrafik) Jpeg (rastergrafik) Svg (vektorgrafik) Krav 23. WMS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar. Rekommendation 7. WFS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar av denna geodataspecifikation. 10 Datafångst och ajourhållning I detta kapitel beskrivs de krav som finns på de processer som skapar Byggnadsdata.

73 73 (145) Styrgruppen Dataproduktion på Lantmäteriet utnyttjar till stor del fotogrammetrisk detaljmätning vid insamling och ajourhållning t.ex. stereokartering och skärmbildsdigitalisering på digitalt ortofoto. För vissa teman som byggnader och adresser görs en stor del av produktionen hos kommunerna och data förs över till Lantmäteriet enligt så kallade ABT-avtal. Dataproduktion på kommunerna består av mer detaljerad mätning genom både geodetisk och fotogrammetrisk detaljmätning. Även andra metoder förekommer, t ex konstruktion ur laserskannade punktmoln. Lantmäteriet utför periodisk regelbunden datainsamling och produktion medan kommunerna utför datainsamling och dataproduktion utifrån behov och vid handläggning för detaljplanering, fastighetsbildning, bygglovshantering med mera Datafångstkrav För att nå enhetlighet för geodata behöver företeelser mätas in enhetligt och de objekt (framförallt objektens geometrier) som skapas för att representera företeelserna behöver skapas enligt gemensamma regler. Det behöver också i informationsmodeller och datamodeller finnas möjlighet att beskriva hur data har samlats in och om eventuella avsteg från regler har gjorts. För nationella data som samlas in, lagras och ajourhålls av Lantmäteriet finns tydliga regler för hur företeelser ska mätas in och hur geometrier som representerar de ska skapas. Det finns dock inte regler för alla företeelsetyper. För mer information om Lantmäteriets regler hänvisas till specifikationen för grundläggande geografiska data på Lantmäteriet (GGD spec.) För data som samlas in, lagras och ajourhålls hos kommuner finns inga nationella regler utan det är upp till varje kommun att fastställa hur insamling sker. I en del (företrädesvis större) kommuner finns tydliga regler och handböcker för hur datainsamling sker. I många kommuner finns å andra sidan inga nedtecknade regler alls utan reglerna finns i huvudet på mätingenjörer/-tekniker. I vissa kommuner finns en del regler nedtecknade och en del är muntligt nedärvda. Det finns således en väldigt stor spridning på hur detta hanteras av kommunala verksamheter och det finns ingen landstäckande sammanställning av hur det skiljer sig åt. Mätningsanvisningar är en specifikation som tas fram för att sammanställa och fastställa regler för inmätning, skapande av objekt och geometrier för geodata både på en nationell nivå och för geodata som skapas i kommunala verksamheter. Med Mätningsanvisningar fylls en lucka igen i arbetet med att skapa enhetliga geodata. 11 Presentationsregler Det är tänkt att dataprodukter som specificeras inom ska kunna visas tillsammans, men hur detta ska ske har ännu inte fastställts. När detta är beslutat kommer presentationsregler att beskrivas gemensamt för alla dataprodukter. 12 Övrig information

74 74 (145) Styrgruppen 13 Referenser DPS Laserdata och höjdmodell () DPS Stompunkter () insamlingsregler () Specifikation för Grundläggande Geografiska Data (GGD - Lantmäteriet) HMK Fotogrammetrisk detaljmätning HMK Geodatakvalitet HMK Ordlista HMK Introduktion Inspire dataspecifikation för Byggnad, version 3.0 SIS/TK 489 N247 Geodata- Nationell metadataprofil DPS och vägledning version SIS-TR 14:2012 Geografisk information Metadata på svenska SIS-TR 40:2012 Geografisk information Tekniskt ramverk Handbok för Dataproduktspecifikation SS-EN ISO 19107:2005 Geographic information Modell för att beskriva rumsliga aspekter SS-EN ISO 19108:2005 Geographic information Modell för att beskriva tidsaspekter SS-EN ISO 19109:2006 Geografisk information för applikationsschema SS-EN ISO 19110:2006 Geografisk information - Struktur för katalogisering av objekttyper SS-EN ISO :2014 Geografisk information Metadata Del 1:Grunder SS-EN ISO :2010 Geographic information Metadata Del 2: Metadata för rasterdata SS-EN ISO 19131:2008 Geographic information Specifikation av datamängder SS-EN ISO 19157:2013 Geografisk information Datakvalitet av de olika detaljeringsgraderna och dess varianter i kapitel 5 bygger- något förenklad - på den formella standarden CityGML v från OGC med tillägg från Data specifications on buildings technical guidelines från Inspire. [1] OGC City Geography Markup Language (CityGML) En-coding Standard, version.0 [2] Inspire D2.8.III.2 Data specifications on buildings technical guidelines [3] Stoter et al. (2015): An improved LOD specification for 3D building models and its CityGML realisation with the Random3Dcity procedural modelling engine, draft version. [4] Biljecki, F., Ledoux, H., Stoter, J. (2014): Height references of CityGML LOD1 buildings and their influence on applications. In: Proceedings of the ISPRS 3D GeoInfo 2014 conference. Breunig, M. et al. (eds.). November 2014, Dubai, UAE. [5] Biljecki, F., Ledoux, H., Stoter, J., Zhao J. (2014): Formalisation of the level of detail in 3D city modelling. Computers, Environment and Urban Systems, vol. 48, pp [6] Biljecki, F., Stoter, J., Ledoux H., Zlatanova S., Çöltekin A. (2015): Applications of 3D City Models: State of the Art Review, ISPRS Int. J. Geo-Inf. 2015, 4, [7] Handbok Byggnad, Version 10.2, , Lantmäteriet

75 Styrgruppen 75 (145) Bilderna i kapitel 5 kommer främst från referens [3], [4], [5] och någon enstaka bild från referens [2], [7] samt bilder från Kartverket Norge, Ordnance Survey, Storbritannien och Malmö stad.

76 76 (145) Styrgruppen 14 Bilagor 14.1 Bilaga A. Test av specifikationsuppfyllelse Kommer att utvecklas av mottagande/förvaltande organisation Bilaga B. av UML för informationsmodeller av de i använda modellelementen. Modellerna visualiseras med modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa. Figur 1.Symbol för diagram. Modellerna visualiseras av modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa. class Beskriv ning av UML Klass 1 +kännertill +kännertill Klass * Klass 2 Figur 2. Klasser, associationer och generaliseringar. De vanligast förekommande elementen i informationsmodellen är klasser, associationer och generaliseringar/specialiseringar. En klass motsvarar en objekttyp i informationsmodellen och representeras vanligen av en tabell i en databas för en datamängd. En klass har ett namn. Associationer uttrycker att en klass känner till en annan klass (exempel Klass 1 kännertill Klass 3. Hur klasserna känner till varandra ges av rollerna de har i associationen. Man kan även specificera multiplicitet för parterna i associationen, i Fel! Hittar inte referenskälla. uttrycks att Klass 1 känner till noll till många (0..*) av Klass 3 medan Klass 3 endast känner till en och endast en (1) av Klass 1. Om ingen multiplicitet är angiven förutsätts den vara en och endast en (1). En generalisering/specialisering är en vanligt förekommande association, så vanlig att en egen symbol skapats för associationen, en ofylld triangel som pekar ut generaliseringsriktningen. Generaliseringar/specialiseringar skapas oftast då flera klasser har gemensamma egenskaper,

77 77 (145) Styrgruppen istället för att upprepa egenskaperna på varje klass så skapar men en superklass (Klass 1) med de gemensamma egenskaperna. De specialiserade klasserna (Klass 2) ärver då superklassens egenskaper (attribut och associationer med mera). Om det inte finns något behov av superklassen i övrigt så görs den ofta abstrakt vilket innebär att man inte kan skapa objekt (instanser) av den. Att en klass är abstrakt syns på att klassens namn är skrivet med kursiv stil. Om man har behov av att kunna skapa objekt av olika konceptuella detaljeringsnivåer i en modell kan man använda generaliseringar/specialiseringar, ett exempel kan vara träd och barrträd. I vissa fall kanske man kan säga att det är ett barrträd som avses men i vissa andra fall kanske man bara vet att det är ett träd. På så vis kan man bygga upp en struktur som motsvarar den bild av verkligheten som en datamängd sedan kommer att beskriva/representera. class Beskriv ning av UML «FeatureType» Klass 10 + attribut a :Boolean + attribut b :Klass 11 + attribut c :CharacterString [0..*] «DataType» Klass 11 + attribut x :Klass 12 «voidable» + attribut y :Integer «codelist» Klass 12 + värde 1 + värde 2 + värde 3 + värde 4 Figur 3. Attribut, stereotyper, datatyper och kodlistor. Klasser kan ha andra egenskaper än associationer. I figur 3 visas stereotyper, attribut, datatyper och kodlistor. Attribut på en klass beskriver enkla eller komplexa egenskaper på klassen. I de enklaste fallen så är de av enkla fördefinierade typer. Attribut a på Klass 10 är av datatypen Boolean (kan anta värdena true eller false ), attribut c är av datatypen Character- String vilket motsvarar en textsträng. Man kan även ange multiplicitet på ett attribut vilket talar om hur många gånger attributet får förekomma på ett objekt /attribut c på Klass 10 för förekomma noll till många gånger, 0..*). Ett attribut kan också spegla en mer komplex egenskap som inte kan anges med en siffra, en text eller liknande. Man kan då ange en komplex datatyp som typ för attributet (attribut b på Klass 10). Den komplexa datatypen kan man definiera själv som en klass med stereotypen <<DataType>> (se nedan) eller så kan man använda någon av de i standarder fördefinierade komplexa datatyperna. vis finns i metadatastandarden ISO :2014 en komplex datatyp för att tala om ansvarig part för en datamängd eller del av datamängd (CI_ResponsibleParty). Attribut kan också vara av en typ som kallas kodlista. En kodlista är en lista med värden som attributet får anta. Kodlistor är utökningsbara under premissen att utökningen görs tillgänglig tillsammans med datamängden.

78 78 (145) Styrgruppen Stereotyper (exempel <<FeatureType>> på Klass 10) är ett sätt att gruppera klasser, attribut och associationer i en modell. I modeller förekommer fyra stereotyper på klasser och en stereotyp på attribut eller associationer (<<voidable>>). De är: <<conceptual>>, anger att klassen motsvarar ett begrepp som identifierats vid skapandet av den helhetsbild som använts för att avgränsa ett tema i Svensk geoprocess. <<FeatureType>>, anger att klassen är en rumsligt förekommande objekttyp med en identitet. <<DataType>>, anger att klassen är en identitetslös datatyp som ofta används för att beskriva komplexa egenskaper på klasser. <<codelist>>, anger att klassen innehåller tillåtna värden för ett attribut. Kodlistor förutsätts finnas tillgängliga. class Beskriv ning av UML Klass 4 Klass Klass Klass 7 Figur 4. Aggregering och komposition Det finns även andra associationer som är så vanligt förekommande att de har fått egna symboler. Aggregering representeras av en ofylld diamant och innebär att Klass 4 kan bestå av en Klass 5. Om en instans av klass 4 raderas kan ändå instansen av klass 5 finnas kvar. En komposition representeras av en fylld diamant och innebär på liknande sätt som en aggregering att Klass 6 kan bestå av en Klass 7. Om en instans av klass 6 raderas skall instansen av klass 7 också raderas. vis så kan inte ett personnummer finnas utan att det finns en person att koppla det till. class Beskriv ning av UML Klass 8 Klass 9 Klass 12 Figur 5. Beroende och realisering

79 79 (145) Styrgruppen Beroende och realisering) är två andra specialiserade associationer som förekommer i modeller. Dessa associationer används för att belysa vissa aspekter men de implementeras inte själva direkt i en datamodell som övriga associationer. Ett beroende (streckad pil med öppen spets) innebär att Klass 8 har ett beroende till Klass 9. Ett konkret exempel är att respektive tema pekar ut de standarder som används i temat, detta görs med ett beroende, tema Hydrografi är till exempel beroende av den svenska vattensystemstandarden (SS637008:201x). Realisering (streckad pil med stängd, ofylld spets). Innebär att Klass 12 implementeras som Klass 9 i informationsmodell eller datamodell. I används realiseringar framförallt för att tala om hur de konceptuella begreppen realiseras i informationsmodellen. Figur 6 Paketstruktur i Alla modellelement är indelade i paket (mappar). I förekomer följande paket under huvudpaketet ( hela modellen = Svenskgeoprocess): SG_Paketberoenden Innehåller diagram som visar hur olika paket är beroende av varandra och av andra standarder och modeller. SG_GemensammaKlasser Innehåller gemensamma klasser och egenskaper som återkommer i alla teman i., geometrier och identifierare. SG_Temanamn Innehåller den enskilda modellen för varje tema inklusive kringinformation. o o o TemanamnAnvändningsfall Innehåller användningsfall för aktuellt tema, antingen uppräknade eller mer fullständigt modellerade, efter behov. Användningsfallen är underlag vid avgränsande av temat. TemanamnHelhetsbild Innehåller en helhetsbild (begreppsmodell) över alla de för temat identifierade viktiga företeelser. I helhetsbilden framgår också vilka företeelser som bedömts ligga utanför ett tema. I diagrammet TemanamnHelhetRealisering visas hur respektive företeelse från helhetsbilden som ska ingå i temat realiseras i informationsmodellen. SG_TemanamnInformation Innehåller ett eller flera diagram som visar den informationsmodell som beskriver temat. Informationsmodellen utgöt underlag för datamodell.