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 LANTMÄTERIET SVERIGES KOMMUNER OCH LANDSTING 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. Test Gemensamma klasser utbrutet till eget dokument. Bilaga A kompletterad. För ändringar i informationsutbytesmodell, se kap 5. Ändringar efter remissynpunkter och harmonisering med Mätningsanvisningar. Maria Andersson, Lantmäteriet Maria Andersson, Lantmäteriet Maria Andersson, Lantmäteriet Thomas Lithén, Lantmäteriet Ulrika Roos, Lantmäteriet

3 1 (121) Styrgruppen Projektet avslutades juni 2016 och Samverkan ansvarar nu för förvaltning och vidareutveckling av geodataspecifikationerna. I version har förbättringar och vidareutvecklingar gjorts jämfört med version 2.0 och version TEST 1. Fortsättningsvis kan det komma att tas fram uppdaterade versioner. Se hemsida för mer information. XML-scheman finns tillgängliga för tester på hemsida

4 2 (121) Styrgruppen Samverkan Svensk Geoprocess I samverkansprojektet utarbetas geodataspecifikationer för nio utvalda geodatateman. Målet med arbetet är att kunna utbyta 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 För att nå målen ingår även en samverkansprocess där samverkansaktiviteter beskrivs och där geodataspecifikationen används i processtegen. Arbetet med att utforma och förvalta specifikationerna bedrivs i samverkan mellan kommuner, Lantmäteriet och för temat andra berörda myndigheter. Introduktion till Geodataspecifikation Byggnad Specifikationens dokumentation 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 Inspires dataspecifikationer för motsvarande geodatateman. Inspire är ett EU-direktiv med regler för hur infrastruktur för geodata i EU ska byggas upp. 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 informationsutbytesmodell och krav på geodata som beskriver Byggnad. Geodataspecifikationen skildrar tillsammans med processen ett framtida scenario av temat Byggnad och ett arbetsflöde där flera aktörer samverkar för att effektivisera samhällsbyggnadsprocessen Processen som tas fram inom innehåller en redogörelse av hur samverkan kring insamling, lagring och tillhandahållande ska gå till.

5 3 (121) Styrgruppen 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. Geodataspecifikationen avser de geodata om byggnad som Lantmäteriet, kommunerna och andra myndigheter och aktörer t.ex. byggherrar och entreprenörer utbyter information om. Byggnadsdatas beståndsdelar läses enklast ur kapitel 5 som innehåller både en informationsutbytesmodell (grafisk 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 informationsutbytesmodellen. Både en informationsutbytesmodell och en objekttypskatalog ökar möjligheterna att fler tänkta användare ska kunna förstå Byggnadsdatas informationsutbytesmodell. Informationsutbytesmodellen kan ses som en avgränsning av vilka företeelsetyper som ingår i temat. Informationsutbytesmodellen är i stor utsträckning baserad på: Kommunala processer Informationsutbytesmodell som används inom samverkan ABT mellan kommunerna och Lantmäteriet. Inspire D2.8.III.2 v Data specification on buildings technical guidelines Inspire - Tillägg till genomförandebestämmelser gällande datamängders och datatjänsters interoperabilitet OGC-standarden CityGML 2.0 Projektet Nationella geodata i 3D Plan och Bygglagen PBL (2010:900) Standardisering, t.ex. SIS-TS :2014 Kommuners dataleveranser efter beslut enligt plan- och bygglagen Läs mer i avsnitt Specifikationen har koordinerats med HMK Handbok i mät- och kartfrågor. Specifikationer, informationsutbytesmodeller och XML-scheman som tas fram i Svensk geoprocess ä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 Svensk geoprocess att besluta om dessa begränsningar och striktare regler ska införlivas i Svensk geoprocess specifikationer, informationsutbytesmodeller 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.

6 4 (121) Styrgruppen 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

7 5 (121) Styrgruppen Innehållsförteckning 1 GEODATASPECIFIKATIONENS OMFATTNING 7 2 ÖVERSIKT Information om geodataspecifikationen Information om Byggnadsdata 14 3 BYGGNADSDATAS OMFATTNINGAR Omfattning - Byggnadsdata (hela temat) 14 4 IDENTIFIERING AV SPECIFIKATION BYGGNAD 15 5 DATAINNEHÅLL OCH STRUKTUR Beskrivande text Informationsutbytesmodell och objekttypskatalog Beskrivning av Basmodell Beskrivning av Byggnad Beroenden till andra specifikationer Ordning på attribut och roller 53 6 REFERENSSYSTEM Plansystem Höjdsystem 54 7 KVALITETSKRAV Datakvalitet 54 8 METADATA 56 9 TILLHANDAHÅLLANDE 56

8 6 (121) Styrgruppen 9.1 Leveransformat DATAFÅNGST OCH UNDERHÅLL PRESENTATIONSREGLER ÖVRIG INFORMATION REFERENSER HMK Handbok för mät och kartfrågor Standarder och tekniska rapporter utgivna genom SIS Övriga referenser 58 BILAGA A. TEST AV SPECIFIKATIONSUPPFYLLELSE 59 BILAGA B. FULLSTÄNDIG INFORMATIONSUTBYTESMODELL 61 Bilaga B.1 Objekttyper 61 Bilaga B.2 er och kodlistor 62 Bilaga B.3 Kodlistor Byggnadsändamål 63 BILAGA C. OBJEKTTYPSKATALOG 77 Bilaga C.1 Objekttyper 77 Bilaga C.2 er 94 Bilaga C.3 Kodlistor 102 BILAGA D. KRAV OCH REKOMMENDATIONER 118 Bilaga D1. Krav 118 Bilaga D2. Rekommendationer 119

9 7 (121) Styrgruppen 1 Geodataspecifikationens omfattning Detta dokument utgör en geodataspecifikation för utbyte av data om byggnader som framställts på uppdrag av Lantmäteriet, kommunerna, SKL och andra myndigheter. 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 svenskgeoprocess@lm.se URL 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 byggnader mellan kommuner, leverantörer och myndigheter. Utbyte kan avse både från producent till informationsägare och från informationsägare till användare. Med utbyte av Byggnad avses utbyte av information om byggnader samt associerade objekttyper. Denna geodataspecifikation riktar sig i första hand till dataproducenter, systemleverantörer och systemutvecklare som ansvarar för att utbyta datamängder enligt denna specifikation. 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 Termer och ar 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. Modelleringstekniska termer beskrivs i Basmodellen. Källa om annan än anges inom hakparentes [ ] efter definition.

10 8 (121) Styrgruppen Objekttyper med attribut beskrivs i bilaga C. Med 3D-uppdraget avses rapporten Förutsättningar för att tillhandahålla kart- och bildinformation i tre dimensioner redovisning av uppdrag enligt regeringsbeslut den 17 oktober 2013 Tabell 1. Temaspecifika termer Termer ur Geodataspecifikation Byggnad Byggnad (och eventuella kommentarer) 2D-data 2,5-data 3D-data punkter, linjer och ytor som endast har plana koordinater. [3D-uppdraget] punkter, linjer och ytor som endast har ett höjdvärde per plan-koordinat [3D-uppdraget] Även kallad 3D-yta där vertikala ytor inte är tillåtna [HMK-TR 2016:4, avsnitt 3.2.3] I denna specifikation ingår 2,5D i 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] Geometrisk representation avseende vektordata i 3D kan bestå av: 3D-volymer; från enkla lådor till komplexa byggnader 3D-ytor; från 2D-polygoner med en horisontell höjd, via TIN till komplexa terrängmodeller med tunnlar och håligheter 3D-linjer; t.ex. vägnät med olika komplexitet 3D-punkter; en punkt med ett höjdvärde. [HMK-TR 2016:4, avsnitt 3.2.3] LevelofDetail (LOD) av detaljeringsgrad/komplexitet i 3D-objekt. [3D-uppdraget]

11 9 (121) Styrgruppen CityGML LOD0 [CityGML 2.0] LOD1 [CityGML 2.0] LOD2 [CityGML 2.0] LOD3 [CityGML 2.0] LOD4 [CityGML 2.0] BIM Byggnadsverk Byggnad 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] byggnaden avbildad som en 2D-yta eller som en horisontell 3D-yta (yta med samma höjdvärde i alla brytpunkter) på marknivå och/eller taknivå. 3D-data (3D-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] 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] självständig enhet i byggd miljö med karakteristisk form och rumslig struktur avsedd att stödja minst en funktion eller verksamhet. Byggnadsverk indelas i byggnad respektive anläggning. [Svensk Byggtjänst] 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. [PBL (2010:900)] Byggnadsverk med uppbyggt tak. [Svensk Byggtjänst]

12 10 (121) Styrgruppen Anläggning CoClass byggnadsverk som inte är en byggnad. [Svensk Byggtjänst] I ingår anläggningar som är byggnadsverk i tema Markdetalj. digitalt klassificeringssystem för all byggd miljö i Sverige. [Svensk Byggtjänst] Tabell 2. Generella termer i Generella termer Term Abstrakt klass Applikationsschema Association Attribut Attributtyp Baskarta Baskarteområde Begreppsmodell Datamodell klass som inte motsvarar en verklig företeelse [Ekvator] Kommentar: representerar gemensamma egenskaper för klasser t.ex. attribut och roller formell av datastruktur, regler och innehåll för information inom ett visst tillämpningsområde [Ekvator] samband mellan klasser [Ekvator] Kommentar: beskrivs med roller i egenskap för en klass beskriven genom de värden den kan anta [Ekvator] Kommentar: Ett värde som representerar det observerade värdet av en egenskap hos en företeelse typ av karakteristik eller för en objekttyp [Ekvator] karta som har ett för ändamålet anpassat innehåll och som utgör underlag för fortsatt kartframställning vid planering, projektering och redovisning [Ekvator] 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. modell som beskriver begrepp, deras egenskaper och inbördes relationer [Ekvator] på logisk nivå över hur data är organiserade i en databas [GIS-ordbok] specifikation av värdedomän och de operationer som är tilllåtna på värdena [Ekvator]Kommentar: I UML representeras en datatyp av en klass vars dataförekomster inte har egen identitet Exempel: SG_, Boolean (sant/falskt)

13 11 (121) Styrgruppen Egenskap Företeelse Företeelsetyp Generic Conceptual Model Geodataspecifikation Informationsmodell Informationsutbytesmodell Kvalitetsmått Kvalitetsparameter Kvalitetstema Kodlista Lägesosäkerhet Metadata Modellelement Multiplicitet Nätverks-RTK Objekt Objekttyp 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 någonting som finns i den verkliga världen eller en tänkt värld och som kan avgränsas som en egen enhet[ekvator] grupp av företeelser med samma egenskaper motsvarande basmodell i Inspire som beskriver gemensamma objekttyper, datatyper och kodlistor ett dokument som beskriver alla krav som ställs på datamängder. Krav avser struktur på data vid utbyte, obligatoriska element samt datakvalitetskrav. begreppsmodell som beskriver de olika objekttyper som är av intresse för en viss verksamhet [Ekvator] informationsmodell specifikt anpassad för informationsutbyte kvantitativ bestämning som ligger till grund för utvärderingen av en kvalitetsparameter [HMK Ordlista] detaljerad indelning av geodatakvalitetens olika aspekter; grupperas ihop till kvalitetsteman och mäts med kvalitetsmått [HMK Ordlista] övergripande indelning av geodatakvalitetens olika aspekter (aktualitet, fullständighet, användbarhet etc.); delas in i kvalitetsparameterar, som mäts med kvalitetsmått [HMK Ordlista] diskret värdedomän där varje värde tilldelats en inom listan unik beteckning [Ekvator] osäkerhet i positionsangivelser, en utvidgning av termen mätosäkerhet till att även omfatta positioner beräknade ur mätdata [HMK-Ordlista] data som definierar och beskriver andra data [Ekvator] Kommentar: Metadata kan förekomma både på datamängdsnivå och objekttypsnivå samt av tjänster. komponent som bygger upp en modell. Exempel: Objekttyper, associationer och datatyper anger hur många förekomster som ska eller kan förekomma bärvågsmätning i realtid med flera permanent placerade referensstationer som samverkar för att optimera hanteringen av felkällor representation av en företeelse i den verkliga världen [Ekvator] abstraktion av en grupp av företeelser med likartade egenskaper [Ekvator]

14 12 (121) Styrgruppen Objekttypskatalog Yttäcke förteckning över objekttyper samt deras attribut- och sambandsanalyser [Ekvator] ett rumsligt objekt som genom sin funktion returnerar värden från sin värdemängd för alla direkta positioner inom sin rumsliga, och/eller tidsmässiga utsträckning, i enlighet med ISO 19123:2007. [Inspire 1089/2010 tillägg 1289] Kommentar: den svenska översättningen av Coverage kan ge syftningsfel, även linje och punkt-format kan förekomma Tabell 3. Källor GIS-Ordbok GIS-Ordbok SIS/STANLI (TK 323) Samverkande GIS med ISO En handbok om tekniskt ramverk för geografisk information, utg 1, 2004 HMK Ordlista HMK Ordlista och förkortningar, 2017 Inspire1089/2010 Ekvator förordning (EU) nr 1089/2010 om genomförande av direktiv 2007/2/EG vad gäller interoperabilitet för rumsliga datamängder och datatjänster termdatabas med geodatarelaterade termer från svenska standarder, tekniska rapporter, tekniska specifikationer och andra rapporter på geodataområdet samt översatta termer från ISO/TC 211 Multilingual glossary of terms. Exempel: Svensk standard (SS), för geografisk information i serien och tekniska rapporter (TR) utgivna av SIS, t.ex. 23, 24, 25, Förkortningar Tabell 4. Förkortningar ABT BSAB DGNSS EPSG GALILEO GLONASS GML Adress Byggnad Topografi Samverkansavtal kring ABT finns mellan kommunerna och Lantmäteriet. Byggandets Samordning AB, kodsystem för beteckning av byggdelar eller produktionsresultat 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, allmänt använd databas med koder över referenssystem [HMK ordlista modifierad] europeiskt satellitbaserat positioneringssystem [HMK-ordlista] Globalnaja navigatsionnaja sputnikovaja sistema, ryskt satellitbaserat positioneringssystem Geographic Markup Language, en profil av XML med fördefinierad hantering av geometrier och referenssystem med mera.

15 13 (121) Styrgruppen GNSS GPS GUM HMK LOD Nätverks-RTK OGC Global Navigation Satellite System, samlingsbegrepp för satellitbaserade navigations- och positioneringssystem [HMK-ordlista] Global Positioning System, amerikanskt satellitbaserat positioneringssystem [HMK-ordlista] 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. 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 Level of Detail. Detaljeringsnivå hos exempelvis 3D stadsmodeller; kommer från informationsmodellen CityGML, som är en standard framtagen av OGC. Kommentar: Begreppet förekommer även i andra sammanhang, till exempel i en delvis annan betydelse i metadatastandarden ISO Bärvågsmätning i realtid med flera permanent placerade referensstationer som samverkar för att optimera hanteringen av felkällor The Open Geospatial Consortium, internationell standardiseringsorganisation för geodata [HMK-ordlista] RH 2000 Rikets Höjdsystem 2000 RMS RTK SKL SWEREF 99 SWEREF 99 TM SWEREF 99 dd mm UML URI UUID Root Mean Square, en typ av (kvadratiskt) medeltal [HMK- Ordlista] Real Time Kinematic, bärvågsmätning i realtid Sveriges Kommuner och Landsting Swedish Reference Frame 1999, svensk realisering av det europeiska geodetiska referenssystemet ETRS 89 Swedish Reference Frame 1999 Transversal Mercator, nationellt plant koordinatsystem erhållet genom projektion av SWEREF 99 Swedish Reference Frame 1999, nationella plana koordinatsystem (12 stycken) för storskaliga tillämpningar erhållna genom projektion av SWEREF 99 Unified Modeling Language, modelleringsspråk som i Svensk geoprocess används för att grafiskt utrycka informationsutbytesmodeller Uniform Resource Identifier, identifierare av resurs Universal Unique IDentifier, kodningsprincip där en sekvens på 128 bitar genereras enligt regler i ISO/IEC 11578:1996 [Ekvator]

16 14 (121) Styrgruppen XML extensible Markup Language, 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 2.2 Information om Byggnadsdata Byggnad Förkortning - Beskrivning av innehåll Byggnadsdata innehåller de objekttyper som har identifierats utgöra underlag vid planering, bygglovshantering, miljöarbete, krisarbete, infrastrukturbyggande och fastighetsbildning. Objekttyperna kan användas för att bl.a. beskriva befintliga byggnaders geometrier, användning/ändamål, area, mätmetoder samt höjdvärde. 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. Utsträckning i tid och rum Syfte Uppgifterna beskrivs i de metadata som följer leveransen. Byggnads specifikation beskriver data om byggnader som behövs som underlag vid framförallt planering, bygglovshantering, miljöarbete, krisarbete, infrastrukturbyggande och fastighetsbildning. 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. 3 Byggnadsdatas omfattningar Specifikationen anger inga delomfattningar, innehåller bara den generella omfattningen. 3.1 Omfattning - Byggnadsdata (hela temat) Identifiering av omfattning Byggnader

17 15 (121) Styrgruppen Hierarkisk nivå på hierarkisk nivå Beskrivning av hierarkisk nivå Utsträckning 005 Datamängd Byggnader Datamängd beskrivande byggnader. Data förekommer över hela Sverige. Omfattningen avser alla Sveriges kommuner. Yttäcken - Ingående omfattningar - 4 Identifiering av specifikation Byggnad 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:s statistikframställning.

18 16 (121) Styrgruppen Syfte Ämnesområde Byggnadsdata är väl beskriven och rymmer data om byggnader som används som underlag vid framförallt planering, bygglovshantering, miljöarbete, krisarbete, infrastrukturbyggande och fastighetsbildning och syftar till att skapa en nationell datamängd för byggnader. 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 at underlaget tolkas fel. Byggnadsdata kan också bidra till att annan myndighetsutövning underlättas. Byggnader och byggnadskonstruktioner Ämnesområde ur den nationella metadataprofilen (tabell 33). Typ av geometrisk representation 001 Vektor Ämnesområde ur den nationella metadataprofilen (tabell 52). Rumslig upplösning Geografisk utsträckning Byggnadsdata förekommer över 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 I kapitlet Informationsutbytesmodell och objekttypskatalog nedan beskrivs i detalj alla ingående objekttyper, attribut och associationer som ingår i Byggnadsdata. Beskrivning sker med hjälp av figurer (UML-diagram), förklarande text och en textversion av objekttypskatalog i bilaga C. Fullständig modell och objekttypskatalog presenteras på webbplatsen. Inom har inga applikationsscheman (enligt ISO 19109) tagits fram utan det sätt som Byggnadsdatas innehåll är grafiskt dokumenterat med är en informationsutbytesmodell. Informationsutbytesmodellen ä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 i Specifikation för Basmodell för information om hur UML har använts i Sammanfattning av förändringar I version TEST 1 har ytterligare anpassning gjorts till de XML-scheman som togs fram inför version 2.0. De informationsmodeller som redovisas är informationsutbytesmodeller.

19 17 (121) Styrgruppen Version 2.0 till version TEST 1 Gemensamma klasser för flera teman har flyttats till separata dokumentet Basmodell. Bilaga A Test av specifikationsuppfyllelse har kompletterats. Klassen SG_Datamängd och BY_ByggnadDatamängd har lagts till. Den abstrakta klassen BY_AbstraktByggnad har tagits bort. De gemensamma attribut som fanns där har flyttats till BY_Byggnad respektive BY_Byggnadsdel. Byggnadsnamnen har en ny datatyp som heter SG_ och är en generell klass under SG_Bas. I klassen BY_ByggnadStatus har gällande under utredning tagits bort. Attributen höjd och höjdövermark har ändrat namn till AbsolutHöjd och RelativHöjd. Attributet KnKodOidentifieratOmråde är borttaget. Attributet byggnadanmärkning har lagts till tillsammans med datatypen BY_ByggnadAnmärkningTyp som kan ha värdena belägenpåoidentifieratområde, forskningsstation, hembygdsgård, hjälptelefon, naturum, observatorium. Attributet externreferens flyttat från SG_BasKlass till BY_Byggnad, BY_FysiskByggnad och BY_AggregeradByggnad. Attributet coclass har lagts till i SG_BasKlass. Attributet byggnadnummerdel har lagts till i BY_Byggnadsdel. Relationerna från BY_Byggnadsdel och BY_Byggnadstillbehör till BY_begränsningsyta har ändrat riktning. Kodlistor med plan- och höjdlägen flyttade till SG_Bas. Borttagna värden i kodlistan BY_ByggnadTillbehörTyp: cistern/silo, kapell, hotell/pensionat, rastskydd. Nya värden i kodlistan BY_ByggnadTillbehörTyp: religiös byggnad, tempel Borttaget i kodlistan BY_ByggnadTIllbehörTyp: förbindelsegång Version TEST 1 till version Objekttyper Å,Ä,Ö ändrat till A,A,O i klassnamn, rollnamn, attributnamn. Attributet coclass flyttat från SG_BasKlass till alla byggnadsklasser. Attributet externreferens har lagts till i alla klasser. Tidigare fanns det endast i BY_Byggnad. BY_ByggnadDatamangd består av 0..* BY_Byggnad i stället för 1..*. Ska vara samma multiplicitet för associationer bestårav från BY_ByggnadDatamangd. Nya associationer från BY_ByggnadDatamangd till BY_FysiskByggnad och BY_AggregeradByggnad. Livscykelattribut från olika skeden i bygglovsprocessen har lagts till genom attributet bygglovstatus. Attributet heltundermark borttaget från BY_Byggnad. Finns endast på BY_Byggnadsdel. Attributet heltundermark är frivilligt och har ändrat multiplicitet till [0...1]. Attributet status har lagts till på BY_Byggnadsdel och BY_Byggnadstillbehor. Multipliciteten för associationen från BY_Begransningsyta till BY_Byggnadsdel och BY_Byggnadstillbehor har ändrats från 1 till 0..1.

20 18 (121) Styrgruppen Multipliciteten för datatypen till attributet geometrilod0 har ändrat multiplicitet från [0..1] till [0..*]. Nya attribut för bygglovstatus på byggnad och byggnadsdel. Ersätter nybyggnadsår, tillbyggnadsår, ombyggnadsår och rivningsår. sättning med Typ har setts över. Kodlistor som används av datatyper har Typ i namnet. Ändrat namn på geometriattibuten för BY_Byggnadstillbehor. er Typ har lagts till namn på attribut och kodlista för byggnadsändamål. er för relativ höjd och absolut höjd har flyttats från Basmodell. Ny datatyp BY_BygglovStatus. er för geometri har anpassats till ändrad geometrimodell. Punkt är ny geometrityp för LoD0. Kodlistor Kodlistor för planläge och höjdläge har uppdaterats och flyttats från Basmodell. Hjälptelefon och observatorium har tagits bort från BY_ByggnadAnmarkningTyp. Nya kodlistor: BY_BygglovAtgardTyp och BY_BygglovStatusTyp. Värdena för detaljerat byggnadsändamål har uppdaterats. Carport, skärmtak och uterum har tagits bort från BY_ByggnadTillbehor. Fyr har ändrats till fyrbyggnad och enslig stuga i fjällen har lagts till i BY_ByggnadKaraktar Underlag som informationsutbytesmodellen baseras på Grunderna avseende objektindelning och förhållandet mellan byggnad och byggnadsdel har hämtats från informationsutbytesmodellen som används vid tjänstebaserad uppdatering i samverkan mellan kommunerna och Lantmäteriet enligt ABT-avtalet. De delar som hanterar den geometriska representationen i 2D och 3D baseras på Inspires Data Specification on Buildings Technical Guidelines. Den specifikationen är starkt påverkad av CityGML, vilket är en företagsoberoende tillämpningsstandard för 3D-GIS från OGC baserad på serien från ISO. Exempel på likheter mellan, Inspire och CityGML är de olika detaljeringsnivåerna LOD0-LOD4 samt möjligheten att ge extern referens för att länka till andra informationssystem. Exempel på olikheter är att: de attribut som är gemensamma för alla Inspire-teman (inspireid, beginlifespanversion, endlifespenversion) används för alla teman i. Motsvarande attribut i CityGML används inte. en förenkling är gjord i Inspire och genom att byggnadsdelar inte kan bestå av delar, vilket är möjligt i CityGML. geometrin - i och Inspire jämfört med CityGML - har kompletterats med metadata för bl.a. lägesosäkerhet, plan- och höjdläge. har färre värden för attributet planläge jämfört med Inspire. textur inte hanteras för närvarande i, men finns i Inspire och CityGML. LOD0 i även kan hantera specialfallet lutande takkontur till skillnad mot Inspire och CityGML 2.0 som enbart hanterar horisontell takkontur.

21 19 (121) Styrgruppen LOD2 i har förenklats till att inte hantera taköverhäng och takkupor. fristående LOD2-tak kan nyttjas för utbyte av takkonstruktion i 3D utan väggar i. inte hanterar LOD4. objekttyperna Fysisk byggnad och Aggregerad byggnad har lagts till i. i Inspire finns fler attribut för miljötillämpningar jämfört med. 5.2 Informationsutbytesmodell och objekttypskatalog Inom finns nio teman Bild, Vatten, Markanvändning/Marktäcke, Markdetaljer, Höjd, Väg/Järnväg, Byggnad, Adress samt Stompunkter. Varje temas informationsutbytesmodell omfattar ett eller flera paket. Utöver detta finns även ett gemensamt paket som används av alla informationsutbytesmodeller som beskrivs i Geodataspecifikation Basmodell. informationsutbytesmodeller är ursprungligen skapade för att visa informationen utifrån ett verksamhetsperspektiv vilket redovisats i tidigare versioner av specifikationerna. För att kunna skapa datautbytesmodeller i form av XML-scheman motsvarande informationsutbytesmodellerna har en del avgränsningar och uppdelningar behövt göras. Dessa nya informationsutbytesmodeller är de som från och med version 3 redovisas i specifikationen. Informationsutbytesmodellerna beskriver hur utbytet av information sker och tillhandahålls tillsammans med XML-scheman via projektets hemsida Informationsutbytesmodellen är uppdelad i flera figurer för att belysa de olika delarna av modellen. Fullständig informationsutbytesmodell och objekttypskatalog återfinns på webbplatsen med kopia i bilaga B och C. Informationsutbytesmodellerna beskriver hur strukturen ser ut i utbytet av information. I objekttypskatalogen för tema Byggnad ingår endast objekttyper skapade för Byggnadsdata. Gemensamma klasser och importerade objekttyper, kodlistor och datatyper från standarder och Inspire beskrivs i dokumentet Basmodell och motsvarande Inspire-specifikation. Kodlistorna är utökningsbara men för att datautbyte ska kunna ske smidigt inom Samverkan ska den nya versionen av kodlistan stämmas av med intressenter för samsyn. Färgsättning av modellelement görs enligt figur nedan. Vita klasser för temats information, grå klasser andra temans och gula klasser för importerade klasser från standarder och Inspire.

22 20 (121) Styrgruppen Figur 2. Färgsättning av klasser i diagram. Annan objekttyp kommer från annat tema eller basmodell. Importerade objekttyper kommer från standarder, Inspire o.dyl. Krav 1 Krav 2 Krav 3 Krav 4 Krav 5 Krav 6 Informationsutbytesmodellens obligatoriska attribut och associationer ska finnas med i datamängd enligt denna geodataspecifikation. Informationsutbytesmodellens angivelser om multiplicitet ska följas för datamängder enligt denna geodataspecifikation. Endast värden från kodlistor ska användas för attribut vars typ är en kodlista. 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. Utökning av kodlistor ska ske i samverkan mellan alla identifierade intressenter. Rekommendation 1 Gemensamma kodlistor ska förvaltas av Lantmäteriet. 5.3 Beskrivning av Basmodell För att skapa enhetlighet bland de specifikationer som tas fram inom har en uppsättning gemensamma objekttyper, datatyper och kodlistor skapats som kan användas av alla specifikationer. Gemensamma klasser, datatyper och kodlistor har prefixet SG_.

23 21 (121) Styrgruppen De gemensamma klasserna medför att identifierare, livscykelinformation, geometrier och av datamängder och metadata hanteras enhetligt. De gemensamma modellerna beskrivs tillsammans med importerade element från Inspire i specifikationen Basmodell med motsvarande numrering SG_BasKlass SG_BasKlass är en abstrakt klass som äger de mest grundläggande attributen som krävs vid utbyte av geodata. SG_BasKlass tillför via arv dessa attribut till objekttyper som inte är en utökning av Inspire såsom objekttyper tillhörande Byggnader och vissa objekttyper i andra teman. SG_BasKlass har två obligatoriska attribut, identitet och datum för då objektets version skapades eller blir giltigt. Identitet beskrivs med datatypen Identifier som kommer från Inspire och består av en namespace (namnrymd) och localid som tillsammans ger ett unikt id Identifierare Alla objekt som levereras enligt ska ha en unik identitet som inte byts ut under dess giltighetstid. Med objekt menas den realisering av den verkliga företeelsen. Vid förändringar av objektet behålls den unika identiteten men objektet representeras av en ny version. utnyttjar Inspires datatyp Identifier som med namespace och localid bygger upp en unik identitet. UUID är en universellt unik identifierare bestående av 32 hexadecimala tecken separerade i fem grupper av bindestreck (-). Lantmäteriet har i sina Inspiretjänster valt att representera namespace med land.organisation.tema Krav 7 Krav 8 Krav 9 Alla vektorobjekt i en datamängd enligt denna geodataspecifikation ska ha en identifierare (Id) Identifierare ska vara av typen Identifier (Inspire - Generic conceptual model - BaseTypes) Identifieraren ska vara unik och stabil över objektets livstid. [Inspire Base Types:Identifier, note 3] Rekommendation 2 LocalId som är ett attribut till typen Identifier anges med typen UUID (ISO/IEC :2005) Livscykelinformation Vid nyskapande av objekt anges skapandedatum i beginlifespanversion, om versionid i datatypen Identifier används ska 1 anges för den första versionen. Då en ny version skapas anges datum och tid för endlifespanversion på den utbytta versionen av objektet. I den nya versionen räknas talet i versionid upp +1 och beginlifespanversion får det datum när den nya versionen blir gällande. Denna version ska vara unik, localid och namespace behålls.

24 22 (121) Styrgruppen Krav 10 Rekommendation Textfält Då attributet endlifespanversion förekommer får dess värde inte inträffa före värdet attributet beginlifespanversion. Datum, för när objekt skapades i databas hos ansvarig part, används för attributet beginlifespanversion och alla objekt i en datamängd enligt denna geodata-specifikation. Det finns olika sätt att representera text. Vanlig text representeras av datatypen CharacterString. Inspire använder datatypen PT_FreeText där språkkod ska anges Projekt SG_Projekt är en objekttyp som kan användas för att hålla information om ett projekt eller uppdrag. SG_Projekt innehåller flera attribut som redovisar kontaktuppgifter till myndigheter, kommuner och företag som på något sätt deltar i projekten som utförare eller beställare. Informationen levereras genom en datatyp RelatedParty, vilken importerats från Inspire Generic Conceptual Model. SG_Projekt har flera subtyper som används i underordnade nivåer i informationsutbytesmodellen. projektid är också en viktig komponent för att bygga upp unika identiteter för enskilda identiteter tillhörande filer och delområden. Byggnad berörs inte av projekt Kontaktuppgifter Ansvarig organisation registreras på olika sätt inom. För projekt inom flygbild, höjd och stompunkter kan uppgifter om ansvarig organisation anges för ägare, producent och uppdragsgivare. För levererade datamängder anges grundläggande metadata enligt den svenska metadataprofilen. För geometrierna kan ansvarig organisation och utförare anges för inmätningen Extern referens Företeelser kan representeras på olika sätt för olika ändamål. Ett objekt i en databas kan referera till ett annat objekt genom datatypen ExternalReference. en kommer från Inspires byggnadsmodell Okända värden För okända eller utelämnade värden används den inbyggda funktionen nillable från XMLschemaspecifikationen från W3C. Funktionen med nil ersätter det utelämnade värde och anges med booleanvärdet true och anledningen till utelämnandet enligt värdelistan nilreason. Anledningen visar t.ex. att värdet saknas eller är okänt. Alla obligatoriska element i XML-scheman är nillable utom identiteten Koordinatsystem För att hantera koordinatsystem används de inbyggda funktionerna i GML där varje geometri har ett koordinatsystem. Referenssystemet för plankoordinater anges med EPSG-kod (se kap. 6) och dimension =2. För 3D-geometrier anges plansystemet men dimension sätts =3. Höjdsystem anges med attribut för Datamängd. Koordinatsystem för plan och dimension anges även för Datamängd.

25 23 (121) Styrgruppen CoClass Klassifikationssystemet CoClass ersätter under hösten 2017 BSAB 96. CoClass användningsområde är den byggda miljön. Syftet är att med ett gemensamt språk underlätta kommunikationen inom byggproduktion och förvaltning. CoClass blir därmed en bärande del i den fortsatta digitaliseringen av bygg- och förvaltningsprocessen. Klassificering sker med 7 tabeller där tabellerna innehåller 3 generaliseringsnivåer. Tabell 5. Tabeller i CoClass Kod Tabellnamn Exempel på innehåll BX Byggnadsverkskomplex grupp av närliggande byggnadsverk som samverkar för att stödja minst en funktion eller verksamhet [CoClass] t.ex. bostadsområde, verksamhetskomplex, markanläggning BV Byggnadsverk självständig enhet i byggd miljö med karakteristisk form och rumslig struktur, avsedd att stödja minst en funktion eller verksamhet [CoClass] indelas i byggnad och anläggning UT Utrymmen avgränsad tredimensionell utsträckning definierad fysiskt eller språkligt [CoClass] t.ex. mänsklig vistelse, förvaring, teknik, trafik FS Funktionella system objekt med karaktäristika som huvudsakligen representerar en övergripande inneboende funktion [CoClass] t.ex. utrymmesskapande system och installationssystem KS Konstruktiva system objekt med karaktäristika som huvudsakligen representerar en sammanhängande teknisk lösning med en inneboende funktion [CoClass] t.ex. trapp KO Komponenter byggdel som realiserar utformningen av delsystem/konstruktioner [CoClass] t.ex. pollare, soffa, gångjärn PR Produktionsresultat resultat av en aktivitet på byggplatsen för produktion av del av eller helt byggnadsverk [CoClass] Exempel på olika klasskoder i 3 nivåer för tabellkoden BV Byggnadsverk: A AA AAA AAB AAC AB ABA ABB ABC Byggnad för mänskliga behov och aktiviteter Bostadshus Småhus Flerbostadshus Hus för gemensamhetsboende Hotell- och restaurangbyggnad Hotellbyggnad Vandrarhem Restaurangbyggnad

26 24 (121) Styrgruppen AC AD, AZ B C D E F Z Hygienbyggnad Skydds- och försvarsbyggnad, Administrationsbyggnad, Tillverkningsbyggnad, Handelsbyggnad, Undervisningsbyggnad, Vård- och omsorgsbyggnad, Komplementbyggnad, Sportbyggnad, Kulturbyggnad, Samlingsbyggnad, Förvaringsbyggnad, Förbindelsebyggnad, Byggnad för flera ändamål Teknikbyggnadsverk Trafikbyggnadsverk Anläggningar Utsmyckande byggnadsverk Fornminne Odefinierat Hela livscykeln från planering till rivning täcks in. CoClass-koden byggs upp av tabellkod:klasskod (eventuell parantes med t.ex. namn eller GUID:GUID-sträng) Exempel: BV:AAA Småhus BV:AAB BV:AAC Flerbostadshus Hus för gemensamhetsboende Objektens identitet är på formen GUID. Vid utbyte av byggnadsinformation enligt denna specifikation kan även korresponderande CoClass-kod samt tillhörande identitet på formen GUID utbytas. Därmed är det möjligt att skapa ett samband mellan BIM-sidan och Geodata-sidan Geometri behandlar geometri som en egenskap till en företeelse. Detta ger möjlighet att representera en företeelse med flera olika geometrier efter olika verksamheters behov. Som exempel kan en byggnad representeras av geometrin för takkant i 2D eller som 3D med alla byggnadens ingående former. Det finns möjlighet att beskriva lägesosäkerheten för en enskild geometri i både plan och höjd. Specifika metadata för inmätningen kan anges för respektive geometri. Svensk Geoprocess använder begreppet lägesosäkerhet för geometrier. Lägesosäkerhet uttrycks som standardosäkerhet, RMSE och beskrivs i HMK-Geodatakvalitet. För kvalitetsrapportering används begreppet noggrannhet för att stämma överens med kvalitetsstandarden. Mätningsanvisningarna är ett komplement till geodataspecifikationer och beskriver geometrisk representation vid utbyte. Kropp Geometri som har utbredning i 3 dimensioner.

27 25 (121) Styrgruppen Ytgeometri Ytor kan representeras av informationsbärande polygoner med eventuella uteslutande inre polygoner (hål). Om en ytas orientering är väsentlig beskrivs ytan med en sekvens koordinater motsols så att insidan är till vänster om begränsningslinjen. En uteslutande inre polygon beskrivs medsols. Ytor kan även representeras av slutna linjegeometrier tillsammans med en informationsbärande centroidpunkt. Linjen kan i sig bära information och vara ett eget objekt. Centroidpunkten ska ligga inom ytan och det måste finnas omkringliggande kantlinjer runt centroidpunkten för att kunna bilda en yta. För att bilda en sluten yta där kantlinjer saknas används tätningslinje, dvs en fiktiv linje utan information. Linjegeometri Linjeobjekt representeras av en ordnad följd koordinatsatta brytpunkter (punktgeometrier). Kontinuerliga linjeobjekt t.ex. kurvor, cirkelbågar och klotoider transformeras till denna form för utbyte. Enbart utvalda linjegeometrier kan representera de objekt som i sig kan klassificeras som ytor men inte har krav på ytbildning. I specifikation för Markdetaljer finns exempel på mittlinjer och kantlinjer. Punktgeometri Punktobjekt representeras geometriskt med ett koordinatpar för 2D samt med höjdvärde om det är 3D. Metadata för geometri Geometrins kvalitet beror till stor del på hur inmätning skett samt var på objektet inmätning skett, detta anges med attribut. I dokumentet Mätningsanvisningar beskrivs hur objekten representeras geometriskt. 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 osakertlage sättas till True och attributet osakertlageanledning skall anges Höjd och 3D Objektets höjd över havet och objekt beskrivna med 3 dimensioner beskrivs med olika modeller. 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öjd som ett attribut. Ett objekts höjd kan beskrivas på 2 sätt o o Absolut höjd beskriver objektets höjd över havet Relativ höjd beskriver objektets höjd över marken Geometri med höjdvärden. 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 (3D-linje eller 3D-yta, ibland även kallad 2,5D). Höjd kan representeras av en tredimensionell geometri, s.k. kropp (3D).

28 26 (121) Styrgruppen 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. Hur höjd redovisas på objekt beskrivs i dokumentet Mätningsanvisningar Ett gemensamt sätt för flera objekttyper att beskriva namn är genom SG_. En datatyp som beskriver namnets status, språk och beslutande myndighet Datamängd Geodata levereras som en datamängd som kan variera i storlek alltifrån enstaka objekt till större datamängder. Att leverera geodata via tjänster av fråga-svar-karaktär beskrivs inte i. SG_Datamangd används av vektordata men inte för bild- och vissa höjddata-leveranser. En identitet för datamängden är obligatorisk och metadata är frivilligt men rekommenderas. SG_Datamangd håller information om koordinatsystem i plan och höjdsystem samt dimension. Metadata för datamängd Grundläggande metadata i enlighet med svensk metadataprofil för datamängden ger en överblick över datamängden med syfte, ämnesområde samt identitet och kontaktuppgifter.

29 27 (121) Styrgruppen 5.4 Beskrivning av Byggnad 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. Lantmäteriet Ändamål Byggherre Geometri BIM-modeller Kartframställning Skatteverket Fastighetstaxering (koppling byggnad och taxeringsinformation) Bygglovsinformation Kommun Interna verksamhetssystem t.ex. bygglov, fastighet Baskartor Förvaltare BIM-modeller Kommun Byggnadsändamål Nybyggnadsår Tillbyggnadsår Ombyggnadsår Rivningsår Antal våningar Boarea Geometri (2D, 3D) Byggnadsnamn Byggnadskaraktär Byggnadstillbehör Fastighet/adresskoppling Blåljus RAÄ Bebyggelseregistret SCB Statistikframställning Bygglovsinformation MSB Skyddsrumsregistret Boverket Bygg och energi Nuvarande samverkan Ev. framtida samverkan Figur 3. Nuvarande och framtida samverkan

30 28 (121) Styrgruppen UUID UUID UUID UUID Figur 4. Översikt för datamängd Byggnad Figur 4. Översikt för datamängd Byggnadvisar översiktligt vad en datamängd med byggnadsdata enligt denna specifikation 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 innehåller även ett antal attribut relaterade till tidsaspekter, 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 informationsutbytesmodell med alla klasser och attribut, se bilaga B 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 5. Fysisk byggnad som ligger på flera fastigheter. För 3D-fastigheter gäller andra regler. Följande varianter av byggnader är definierade i denna specifikation a. Byggnad indelning efter 2D-fastigheter 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.

31 29 (121) Styrgruppen Fysisk byggnad Förenklat kan sägas att objektet fysisk byggnad är en sammanhängande byggnad oberoende av fastighetsindelningen Figur 5. 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. En byggnad med två byggnadsdelar. Figur 6. En byggnad kan bestå av byggnadsdelar.

32 30 (121) Styrgruppen Figur 7. Indelning i byggnadsdelar utifrån olika höjd. class Byggnad_översikt «featuretype» BY_AggregeradByggnad /geometriaggregeradbyggnad externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] bestarav 2..* «featuretype» BY_FysiskByggnad /geometrifysiskbyggnad externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] bestarav 1..* «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «featuretype» BY_Byggnadsdel byggnadnummerdel: Integer [0..1] byggnadandamaldel: BY_ByggnadAndamal [0..*] statusdel: BY_ByggnadStatus [0..1] bygglovstatusdel: BY_BygglovStatus [0..*] antalvaningarovermark: Integer [0..1] antalvaningarundermark: Integer [0..1] bestarav absoluthojd: BY_AbsolutHojd [0..*] relativhojd: BY_RelativHojd [0..*] 1..* boareadel: Integer [0..1] heltundermark: Boolean [0..1] byggnadkaraktardel: BY_ByggnadKaraktar [0..1] taktyp: BY_TakTyp [0..*] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] Figur 8. Aggregerad byggnad - Fysisk byggnad - Byggnad - Byggnadsdel. Vissa attribut kan både finnas på byggnaden och byggnadsdelen. Andra attribut kan endast finnas på byggnaden. Tabell 6 visar vilka attribut som kan finnas på byggnad respektive byggnadsdel. I UML och XML används a,a,o i stället för å,ä,ö. Tabell 6. Attribut på Byggnad och Byggnadsdel. Attribut på byggnad byggnadnummer byggnadandamal byggnad status bygglovstatus byggnadarea boarea byggnadanmarkning undantagenfranadressattning ofrigrund Attribut på byggnadsdel byggnadnummerdel byggnadandamaldel statusdel bygglovstatusdel boareadel antalvaningarovermark antalvaningarundermark absoluthojd

33 31 (121) Styrgruppen byggnadkaraktar externreferens coclass relativhojd heltundermark byggnadkaraktardel taktyp geometri LOD0-LOD3 externreferens coclass 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. Exempel på byggnadstillbehör är balkong och trappa. Figur 9 Exempel på byggnadstillbehör

34 32 (121) Styrgruppen class Byggnadstillbehör «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «featuretype» BY_Byggnadsdel byggnadnummerdel: Integer [0..1] byggnadandamaldel: BY_ByggnadAndamal [0..*] statusdel: BY_ByggnadStatus [0..1] bygglovstatusdel: BY_BygglovStatus [0..*] antalvaningarovermark: Integer [0..1] antalvaningarundermark: Integer [0..1] absoluthojd: BY_AbsolutHojd [0..*] bestarav relativhojd: BY_RelativHojd [0..*] boareadel: Integer [0..1] 1..* heltundermark: Boolean [0..1] byggnadkaraktardel: BY_ByggnadKaraktar [0..1] taktyp: BY_TakTyp [0..*] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] harbyggnadstillbehor 0..* «featuretype» BY_Byggnadstillbehor byggnadstillbehor: BY_ByggnadTillbehor status: BY_ByggnadStatus [0..1] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «codelist» BY_ByggnadTillbehor altan balkong brandvägg lastbrygga mast skorsten takfönster takkupa trappa Figur 10. Byggnadstillbehör

35 33 (121) Styrgruppen Höjd En byggnad kan ha flera höjdvärden som representerar olika lägen. Höjden kan beskrivas med attributet absoluthojd genom att använda möjliga värden i kodlistan BY_HojdLageTyp t.ex. takkant eller takets högsta punkt. byggnadens högsta punkt takets högsta punkt (nock) generell takhöjd högsta takfot lägsta takfot högsta takkant lägsta takkant högsta markhöjd markens medelhöjd lägsta markhöjd byggnadens högsta punkt takets högsta punkt (nock) generell takhöjd generell takfot generell takkant lägsta våning ovan mark entrénivå markens medelhöjd byggnadens lägsta punkt Figur 11. Höjdlägen För mer information om höjdlägen se dokumentet Mätningsanvisningar. Det finns även ett attribut (relativhojd) 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. markens medelhöjd, entrénivå, husgrund).

36 34 (121) Styrgruppen class Höjd «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] HÖJD bestarav 1..* «featuretype» BY_Byggnadsdel byggnadnummerdel: Integer [0..1] byggnadandamaldel: BY_ByggnadAndamal [0..*] statusdel: BY_ByggnadStatus [0..1] bygglovstatusdel: BY_BygglovStatus [0..*] antalvaningarovermark: Integer [0..1] antalvaningarundermark: Integer [0..1] absoluthojd: BY_AbsolutHojd [0..*] relativhojd: BY_RelativHojd [0..*] boareadel: Integer [0..1] heltundermark: Boolean [0..1] byggnadkaraktardel: BY_ByggnadKaraktar [0..1] taktyp: BY_TakTyp [0..*] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «datatype» BY_AbsolutHojd hojdlagetyp: BY_HojdLageTyp hojdvarde: Real «datatype» BY_Relativ Hojd hogstahojdlagetyp: BY_HojdLageTyp lagstahojdlagetyp: BY_HojdLageTyp hojdvarde: Real «codelist» BY_PlanLageTyp fasad takkant husgrund illustrativt läge ospecificerat läge «codelist» BY_HojdLageTyp byggnadens högsta punkt takets högsta punkt (nock) takkant, generell takkant, lägsta takkant, högsta lutande takkontur takfot, generell takfot, lägsta takfot, högsta generell takhöjd lägsta våning ovan mark vid överhäng entrénivå färdigt golv sockelhöjd husgrund markens medelhöjd markhöjd, lägsta markhöjd, högsta byggnadens lägsta punkt fiktivt höjdläge under marknivå illustrativt läge ospecificerat läge Figur 12. Det finns två attribut för absolut höjd och relativ höjd. Exempel på två olika relativa höjder: BH1 = Generell takkant (H2) Markens medelhöjd (Hmin) BH2 = Byggnadens högsta punkt (Hmax) Markens medelhöjd (Hmin) Figur 13. Olika höjddifferenser.

37 35 (121) Styrgruppen Plan Läget där plankoordinaterna registreras ska beskrivas med attributet BY_PlanLägeTyp. fasad takkant Figur 14. Planlägen class Planläge «codelist» BY_PlanLageTyp fasad takkant husgrund illustrativt läge ospecificerat läge Figur 15. Kodlista med planlägen. Illustrativt läge innebär att byggnaden representeras med schablongeometri Klassificering Klassificering sker med två attribut: Byggnadsändamål hänvisar till byggnadens användning (t.ex. bostad, samhällsfunktion eller industri). I Bilaga B finns kodlistan för SG_ByggnadAndamal. Kodlistan är hierarkiskt indelad i två nivåer; Översiktlig nivå och Detaljerad nivå. Informationsutbytesmodellen 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.

38 36 (121) Styrgruppen class Byggnadskaraktär «codelist» BY_ByggnadKaraktar enslig stuga i fjällen fjällstation fyrbyggnad herrgård klockstapel kyrka kåta moské raststuga religiös byggnad slott synagoga tempel torn turiststuga/övernattningsstuga vindkraftverk väderkvarn Figur 16. 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. Exempel på tillämpning kan vara länkning till byggnadens namn i datamängd för ortnamn, länkning till bygglovsinformation eller taxeringsinformation. 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.

39 37 (121) Styrgruppen class ExternReferens_ «featuretype» BY_AggregeradByggnad /geometriaggregeradbyggnad externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «featuretype» BY_Byggnadsdel bestarav 2..* «featuretype» BY_FysiskByggnad /geometrifysiskbyggnad externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] bestarav 1..* «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] bestarav 1..* byggnadnummerdel: Integer [0..1] byggnadandamaldel: BY_ByggnadAndamal [0..*] statusdel: BY_ByggnadStatus [0..1] bygglovstatusdel: BY_BygglovStatus [0..*] antalvaningarovermark: Integer [0..1] antalvaningarundermark: Integer [0..1] absoluthojd: BY_AbsolutHojd [0..*] relativhojd: BY_RelativHojd [0..*] boareadel: Integer [0..1] heltundermark: Boolean [0..1] byggnadkaraktardel: BY_ByggnadKaraktar [0..1] taktyp: BY_Taktyp [0..*] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «datatype» ExternalReference informationsystem: URI informationsystemname: PT_FreeText reference: CharacterString PT_FreeText {root} Figur 17. Länkning mellan byggnad och andra informationssystem via externreferens Taktyp Det finns ett antal olika taktyper fördefinierade för att ange takformen t.ex. sadeltak, brutet tak och pulpettak. class Taktyp_ «codelist» BY_TakTyp lågt lutande tak pulpettak sadeltak valmat tak mansardtak halvvalmat tak kägeltak pyramidtak kupoltak bågtak penthustak sågtandtak tälttak dubbelkrökt tak

40 38 (121) Styrgruppen Figur 18. Exempel på olika taktyper Koppling till en datamängd med ortnamn kan ske via externreferens från BY_Byggnad. Innan sådan koppling är möjlig kan byggnad användas som särskilt namnattribut. class _Byggnad «datatype» ExternalReference informationsystem: URI informationsystemname: PT_FreeText reference: CharacterString «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «datatype» SG_ namn: CharacterString namnstatus: SG_Status sprak: SG_Sprak ansvarigbeslutsfattare: SG_AnsvarigBeslutsfattare [0..1] externalreference: ExternalReference [0..1] «codelist» SG_Status föreslaget namn godkänt namn övrigt namn svenska nordsamiska sydsamiska umesamiska lulesamiska meänkieli finska «codelist» SG_Sprak «codelist» SG_Ansv arigbeslutsfattare kommun Lantmäteriet Trafikverket Sjöfartsverket Naturvårdsverket länsstyrelse annan namngivare Figur 19. på byggnad.

41 39 (121) Styrgruppen Livscykelinformation Det finns två typer av livscykelinformation. Dels i form av transaktionstid (datum då objektets version skapades i data), dels tidpunkter för olika skeden i verkligheten. Transaktionstiden tillsammans med versionshantering beskrivs i kap Många byggnader, framförallt i tidiga skeden i byggnadens livscykel, kommer att härledas utifrån mer detaljerade BIM-modeller. BIM-objekten har identiteter i form av GUID. Enligt denna specifikation har objekten identiteter enligt datatypen Identifier (UUID). Ett objekt för en bygglovspliktig byggnad skapas i samband med bygglovsansökan. Det finns olika typer av bygglovsåtgärder t.ex. nybyggnad, tillbyggnad och ombyggnad. Under bygglovsprocessen finns det olika skeden i byggnadens verkliga livscykel. Det är ansökan, beviljat lov (bygglov eller rivningslov), startbesked och slutbesked. Till dessa skeden finns olika beslutsdatum. I attributet atgardar lagras tidpunkten (datum eller år) för färdigställandet av åtgärden. Värdet motsvaras av tidpunkten för slutbesked. class Bygglov Status «datatype» BY_Bygglov Status bygglovatgardtyp: BY_BygglovAtgardTyp [0..1] bygglovstatustyp: BY_BygglovStatusTyp [0..1] beslutsdatum: DateTime [0..1] atgardar: DateTime [0..1] «codelist» BY_Bygglov AtgardTyp Nybyggnad Tillbyggnad Ombyggnad eller ändrad användning Rivning Befintlig byggnad «codelist» BY_Bygglov StatusTyp Ansökan Beviljat lov Startbesked Slutbesked Ej via bygglov Figur 20. Livscykelinformation Byggnader som samlas in på annat sätt än via bygglovsprocessen t.ex. periodisk ajourhållning med fotogrammetriska metoder, får åtgärdstypen Befintlig byggnad. Statustypen är då Ej via bygglov. Det finns även en kodlista för generella, övergripande statusvärden.

42 40 (121) Styrgruppen class Status «codelist» BY_ByggnadStatus planerad gällande avregistrerad Geometrier allmänt Byggnaders geometriska representation kan vara antingen 2D, 3D-yta eller 3D-volym. 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. 3D beskrivs ofta med OGC-standarden CityGML 2.0 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. Figur 21. Schematisk bild av de olika LOD-nivåerna i CityGML 2.0 (Bild: Filip Biljecki, TU, Delft) LOD0 Byggnaden är avbildad som en yta, dvs. som i en traditionell 2D-karta. Byggnaden kan vara en 2D-yta eller som en horisontell 3D-yta (yta med samma höjdvärde i alla brytpunkter) på marknivå och/eller taknivå. Den horisontella takytan kan avse olika höjder, från byggnadens högsta punkt till lägsta takkant, beroende på ändamål. Ytans planläge kan avse verklig fasads läge, takkantens läge projicerad på markytan med mera. LOD1 LOD2 3D-data (volym) i form av en låda med horisontella och vertikala ytor. Den horisontella takytan kan avse olika höjder, från byggnadens högsta punkt till lägsta takkant, beroende på ändamål. De vertikala ytornas läge kan avse verklig fasads läge eller takkantens läge projicerad på markytan. 3D-data med förenklad tak- och fasadrepresentation. Taköverhäng och byggnadstillbehör på fasad och tak som dörr, fönster, balkong, takkupor, skorsten redovisas inte. Mindre byggnadsdelar kan generaliseras bort. De vertikala ytornas läge kan avse verklig fasads läge eller takkantens läge projicerad på markytan.

43 41 (121) Styrgruppen LOD3 LOD4 3D-data med detaljerad tak- och fasadrepresentation. Detaljerad av exteriör t.ex. skorstenar, takkupor, fönster och dörrar är möjlig om så önskas. Taköverhäng redovisas. De vertikala ytornas läge avser verklig fasads läge. På sikt kan även textur komma att ingå 3D-data som även beskriver byggnaden invändigt. Behandlas inte av Svensk geoprocess. 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. LoD4 med invändig geometri är, än så länge, ovanlig i Geodata/GIS-sammanhang. Det finns även möjlighet till att utbyta de två specialfallen lutande takkontur och fristående LOD2-tak (figur 22) även om de inte följer LOD-begreppet enligt CityGML 2.0. Dessutom finns möjlighet att ge en byggnads absoluta och relativa höjd som attribut till byggnadsobjektet. Figur 22. Två tillåtna specialfall i som inte följer LOD-begreppet enligt CityGML 2.0. Röd linje i vänstra bilden avser 3D-yta för Lutande takkontur och utbyts som LOD0 med särskilt attribut för avvikande höjdläge. Röd linje i den högra bilden avser 3D-ytor som Fristående LOD2-tak för utbyte av takkonstruktion i 3D utan väggar. LOD0 Byggnadens yta i 2D, 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

44 42 (121) Styrgruppen LoD1 LOD1 avser byggnadsvolymer (3D-volymer) representerade med horisontellt tak och bottenyta, väggarna är vertikala. Byggnadsmodeller av samma hus i LOD1 kan göras i ett stort antal varianter enligt bilden ovan. Väggytan i LOD1 kan bland annat 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 bland annat följande varianter för takets höjdläge: a. Takkantens medelhöjd 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. Medelhöjd för 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. Takets medelhö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. Markens medelhöjd (vanligen tas höjd fram för en fiktiv bottenyta genom att ur en DTM interpolera fram lägsta markhöjd) d. Fiktiv bottenyta under marknivå används ofta vid visualisering e. Byggnadens lägsta punkt (dvs bottenytan korrekta höjdläge, t ex källargolv)

45 43 (121) 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. LOD2 I princip finns tre grundmodeller att översiktligt beskriva en byggnad i LOD2 på. Huset längst till vänster i figuren nedan 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 b. Hus med korrekt takläge men för stor fasadutbredning c. Hus med korrekt fasad- och takläge. Denna variant är i endast tillåten i LOD3. a b c

46 44 (121) Styrgruppen LoD 3 a. b. LOD3 är en principiell arkitekturritning sett från utsidan och avser hus med korrekt fasadoch 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. a. LOD3 - utan balkongräcken, dörr- och fönstersmyg b. LOD3 - med balkongräcken, dörr- och fönstersmyg 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.

47 45 (121) Styrgruppen Användningsområden för olika LOD Några exempel på användningsområden för olika detaljeringsnivåer: LOD1 o Lämplig för översiktliga visualiseringar av landskap och stadsmiljö (vanligen takets medelhöjd) samt för fastighetsbildning (om korrekt fasadläge) o Exempel på enkla analyser är siktanalyser längs marken (om korrekt fasadläge), energiförbrukning (om korrekt fasadläge och med takets skärningspunkt med fasaden), buller (vanligen takkant), solpaneler på fasaden (takets skärningspunkt med fasaden), skuggor (takets medelhöjd), vågutbredning telefoni (takets högsta läge) och översvämning. LOD2 o Ger mer realistiska visualiseringar än LOD1 av landskap och stadsmiljö samt o LOD3 o o LOD4 o vid fastighetsbildning (om korrekt fasadläge) Ger bättre analyser för de flesta exempel under LOD1 samt är en förutsättning för planering av solpaneler på tak Lämplig för högkvalitetsvisualisering över mindre områden vid till exempel 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 Lämplig för högkvalitetsvisualisering för räddningstjänst (inomhusnavigering), 3D-fastighetsbildning samt VR-applikationer Användningsområden för de två specialfallen enligt Figur 4.1.1b: Lutande takkontur (Figur 22, vänstra bilden) o Kan lagras i en geodatabas som inte hanterar vertikala ytor. o Lämplig att använda om man nyttjar fotogrammetrisk ajourhållning i 3D av byggnadsobjektet men endast önskar redovisning av byggnader i 2D. o Om frivilligt höjdattribut för absolut höjd eller relativ höjd finns kan användaren skapa byggnader i LOD1 med hjälp av en markmodell. Flygande LOD2-tak (Figur 22, högra bilden) o Kan lagras i en geodatabas som inte hanterar vertikala ytor. o Kan nyttjas av dataägaren till att konvertera byggnader till LOD2 med hjälp av en markmodell när geodatabasen kan hantera 3D fullt ut. o Kan nyttjas av användaren till att ta fram byggnader i LOD2 med hjälp av en markmodell. Läs mer om nyttan i Applications of 3D city models: state of the art review.

48 46 (121) Styrgruppen Generalisering Generaliseringsregler sätts av informationsägaren utifrån sina behov. Följande rekommenderade värden avser högsta gränser för nationell respektive kommunal dokumentation. HMK-standardnivå 1, rekommenderade gränsvärden: Följande värden rekommenderas för LOD0, LOD1 och LOD2 utanför tätort. Innanför tätort rekommenderas samma värden som för HMK-standardnivå 2: Storlek på byggnadsdel, >15 m² Höjdskillnad på tak för att dela in i byggnadsdelar, >5 m HMK-standardnivå 2, rekommenderade gränsvärden: Följande värden rekommenderas för LOD0, LOD1 och LOD2: Storlek på byggnadsdel, >4 m bred eller 10 m² Höjdskillnad på tak för att dela in i byggnadsdelar,>2 m Följande värden rekommenderas vid egen inmätning av byggnadstillbehör i LOD3. Storlek på taköverhäng, >0,2 m Storlek på takkupa eller liknande, >2 m bred eller 2 m² Höjd på skorsten över tak, >1 m Storlek på takfönster och fönster, >1 m bred eller 1 m² Storlek på balkong, >0,2 m ut från fasad eller 1 m² Fönstersmyg, >0,2 m in från fasad Vid nedskalning av CAD/BIM-modell blir det ofta mer detaljerat. Arbete pågår i bland annat Smart Built Environment, eventuella gränsvärden kan komma senare. HMK-standardnivå 3, rekommenderade gränsvärden: Under arbete i bland annat Smart Built Environment, eventuella gränsvärden kan komma senare 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. Textur hanteras för närvarande inte i

49 47 (121) Styrgruppen Geometrier i informationsutbytesmodellen för Byggnad För den geometriska representationen av byggnaden finns attributet geometrilod0 för 2D- och 3D-ytor (2,5D) med en eller flera ytor. För 3D-redovisning finns attributen geometri3dlod1, geometri3dlod2, geometri3dlod3 för de olika detaljeringsnivåerna LoD1-3. Attrubuten antalvaningarovermark, antalvaningarundermark, absoluthojd och relativhojd ger indirekt information om byggnadens höjd. class Geometri «featuretype» BY_Byggnadsdel byggnadnummerdel: Integer [0..1] byggnadandamaldel: BY_ByggnadAndamal [0..*] statusdel: BY_ByggnadStatus [0..1] bygglovstatusdel: BY_BygglovStatus [0..*] antalvaningarovermark: Integer [0..1] antalvaningarundermark: Integer [0..1] absoluthojd: BY_AbsolutHojd [0..*] relativhojd: BY_RelativHojd [0..*] boareadel: Integer [0..1] heltundermark: Boolean [0..1] byggnadkaraktardel: BY_ByggnadKaraktar [0..1] taktyp: BY_TakTyp [0..*] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «DataType» BY_ByggnadGeometriLoD0 punktgeometri: GM_Point [0..1] ytgeometri: GM_Surface [0..1] geometrimetadata: GE_GeometriMetadata planlagetyp: BY_PlanLageTyp hojdlagetyp: BY_HojdLageTyp «DataType» BY_ByggnadGeometri3DLoD ytgeometri: GM_Surface [0..*] kropp: GM_Solid [0..1] terrangskarning: GM_Curve [0..*] geometrimetadata: GE_GeometriMetadata hojdlage3dbotten: BY_HojdLageTyp «DataType» BY_ByggnadGeometri3DLoD1 planlagetyp: BY_PlanLageTyp hojdlage3dtopp: BY_HojdLageTyp «DataType» BY_ByggnadGeometri3DLoD2 planlagetyp: BY_PlanLageTyp Figur 20. Attribut för geometrisk representation.

50 48 (121) Styrgruppen Multipla geometrier är tillåtna. En byggnad kan representeras med en eller flera ytor t.ex. bottenyta och takyta. 2D 2D och 3D-yta (2,5D): Läget för plankoordinater ska redovisas med attributet planlagetyp. Läget där höjdkoordinaten mäts ska dokumenteras med attributet hojdlagetyp. 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 topologiskt perfekta modeller. Så är t.ex. fallet om byggnaden mäts fotogrammetriskt och bottenytan saknas. För dessa fall tillåts en representation med flera ytor (b). En byggnad kan bestå av flera sammansatta ytor eller en enhetlig volym (kropp). Med flera ytor kan olika attribut sättas på de olika ytorna medan en kropp endast kan ha attribut på hela byggnaden.

51 49 (121) Styrgruppen class Begränsningsytor_ «featuretype» BY_Byggnadsdel byggnadnummerdel: Integer [0..1] byggnadandamaldel: BY_ByggnadAndamal [0..*] statusdel: BY_ByggnadStatus [0..1] bygglovstatusdel: BY_BygglovStatus [0..*] antalvaningarovermark: Integer [0..1] antalvaningarundermark: Integer [0..1] absoluthojd: BY_AbsolutHojd [0..*] relativhojd: BY_RelativHojd [0..*] boareadel: Integer [0..1] heltundermark: Boolean [0..1] byggnadkaraktardel: BY_ByggnadKaraktar [0..1] taktyp: BY_TakTyp [0..*] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] begransarbyggnadsdel 0..1 «featuretype» BY_Byggnadstillbehor harbyggnadstillbehor byggnadstillbehor: BY_ByggnadTillbehor 0..* status: BY_ByggnadStatus [0..1] geometrilod0: BY_ByggnadGeometriLoD0 [0..*] geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] begransarbyggnadstillbehor 0..1 «featuretype» BY_Begransningsyta geometri: GM_Surface geometrimetadata: GE_GeometriMetadata [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «featuretype» BY_Oppning oppning geometri: GM_Surface geometrimetadata: GE_GeometriMetadata [0..1] 0..* externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «featuretype» BY_Takyta «featuretype» BY_SkymdGolv yta «featuretype» BY_Bottenyta «featuretype» BY_Fonster «featuretype» BY_Dorr «featuretype» BY_SkymdTakyta «featuretype» BY_Stangningsyta «featuretype» BY_Vaggyta Figur 24. 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 21. Begränsningsytor Bottenytan är vanligen fiktiv och konstrueras med hjälp av fasaden dvs en horisontell yta med en höjd satt som är lägre än markytan runt byggnaden, s.k. fiktivt höjdläge under marknivå.

52 50 (121) Styrgruppen En byggnad kan bestå av följande delar (om vi betraktar den utifrån) Bottenyta 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 t.ex. balkong, 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 26. Terrängskärningen redovisas i svart. För alla LOD-nivåer ska nivån som representerar bottenytan dokumenteras genom attributet hojdlage3dbotten 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 endast tillåten för LODO. 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 hojdlage3dtopp. Exempel på värden är byggnadens högsta punkt, takets högsta punkt, 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.

53 51 (121) Styrgruppen Relationer Byggnads relation till Registerenhet (fastighet eller samfällighet) class Registerenhet «conceptual» Registerenhet «conceptual» Enhetsutrymme liggerpa 0..1 tillhor 0..1 berorsav 0..* «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] Figur 27. Relationer mellan byggnad och registerenhet Byggnads relation till Adress

54 52 (121) Styrgruppen class Adress «featuretype» BY_Byggnad «conceptual» Adressplats har 0..1 «conceptual» Entré nåsvia 1 hörtill 1 byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] «conceptual» Lägenhet Figur 28. Relationer mellan byggnad, adress och lägenhet class SKV Byggnads relation till Skatteverkets taxeringsenhet och värderingsenhet «conceptual» Skattev erkets taxeringsenhet «conceptual» Skattev erkets v ärderingsenhet refererartill 0..* refererartill 0..* «featuretype» BY_Byggnad byggnadnummer: Integer byggnadandamal: BY_ByggnadAndamal [1..*] byggnad: SG_ [0..*] {ordered} status: BY_ByggnadStatus bygglovstatus: BY_BygglovStatus [0..*] byggnadarea: Integer [0..1] boarea: Integer [0..1] byggnadkaraktar: BY_ByggnadKaraktar [0..1] byggnadanmarkning: BY_ByggnadAnmarkning [0..*] undantagenfranadressattning: Boolean [0..1] ofrigrund: Boolean [0..1] externreferens: ExternalReference [0..*] coclass: SG_CoClass [0..1] Figur 29. Relationer mellan byggnad och Skatteverkets taxerings- och värderingsenhet Objekttypskatalog Se bilaga C.

55 53 (121) Styrgruppen 5.5 Beroenden till andra specifikationer pkg PaketberoendenByggnader SG_Bas + SG_BasObjekttyper + SG_Baser + SG_BasKodlistor + BasImporteradeObjekttyper + BasImporteradeer + BasImporteradeKodlistor (from Informationsutbytesmodell) BY_Byggnad ML_Markdetaljer + ML_MarkdetaljerObjekttyper + ML_Markdetaljerer + ML_MarkdetaljerKodlistor + BY_ByggnadObjekttyper + BY_Byggnader + BY_ByggnadKodlistor AR_Adress + AR_AdressObjekttyper + AR_Adresser + AR_AdressKodlistor (from Informationsutbytesmodell) (from Informationsutbytesmodell) (from Informationsutbytesmodell) Figur 30. Paketdiagram visande Byggnadsdatas beroenden. 5.6 Ordning på attribut och roller I geodataspecifikationens motsvarande XML-schema hanteras attribut på objekttyper och datatyper på samma sätt som relationer med roller mellan objekttyper. Kodlistor hanteras i ett separat XML-schema. Ordningen på attribut och roller är densamma som i informationsutbytesmodellen och XML-schemana är skrivna med funktionen <sequence> vilket innebär att ordningen alltid ska följas. Attribut på ett modellelement beskrivs alltid först och därefter eventuella roller till andra modellelement. 6 Referenssystem Referenssystemen SWEREF 99 och RH 2000 används inom. Lista på godkända koordinatsystem finns i dokumentet Basmodell i form av tabell med figur för utbredning av lokala zoner. Koordinatsystem anges med EPSG-kod. Temporalt referenssystem anges med UTC +1 eller +2 vintertid/sommartid i de fall det är aktuellt. Transformation till andra referenssystem eller överräkning till andra projektionszoner ska ske med Gtrans eller annan programvara som innehåller godkända algoritmer. Samma temporala referenssystem används för alla omfattningar. Tabellen med EPSG-koder återfinns i Basmodell

56 54 (121) Styrgruppen 6.1 Plansystem Inom används SWEREF 99 TM eller dess lokala zoner som i många kommunala tillämpningar. Äldre ortofoto och stomnät använder RT Höjdsystem I RH 2000 benämns höjden över havet (Normaal Amsterdam Peil) med H. För ytterligare av höjd se motsvarande kapitel i geodataspecifikation Stompunkter. Krav 11 Datamängder enligt denna geodataspecifikation ska tillhandahållas med i SWEREF 99 TM eller SWEREFs lokala zoner och RH Kvalitetskrav 7.1 Datakvalitet beskriver hur data ska levereras med gemensamma objekttyper och värdelistor. I Tabell 7 beskrivs hur resultatet av kvalitetsutvärderingen levereras i metadata. Respektive leverantörs krav beskrivs i organisationens egna geodataspecifikation som ska göras tillgänglig för mottagaren. Referenser inom parentes anger Id i bilaga D i kvalitetsstandarden ISO Datakvalitet 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. Flertalet kvalitetsparametrar uttrycks som % vid stickprovskontroll eller kontroll av helheten alternativt som del av helheten vid kontroll av hela datamängden eller en specifik objekttyp, resultatet för respektive datamängd rapporteras i datamängdens metadata. Inom kvalitetsstandarden används termen lägesnoggrannhet, vilket i GUM motsvarar termen lägesosäkerhet som används i HMK. I nedanstående tabeller som följer kvalitetsstandarden ISO har termen lägesnoggrannhet använts inom, för att inte avvika från kvalitetsstandardens terminologi. Tabell 7. Datakvalitetskrav Kvalitetstema Kvalitetsparameter Kvalitetsmått med exempel Fullständighet Datamängdens innehållsmässiga överensstämmelse med specifikationen; brist eller övertalighet för objekt, attribut eller relationer. Logisk konsistens överensstämmelse med logiska regler för en datamängd Brist saknade förekomster i en datamängd Övertalighet för många förekomster i en datamängd Konceptuell konsistens utvärderas och rapporteras som: - andel saknade objekt i förhållande till specifikation (id 7) utvärderas och rapporteras som: - andel övertaliga objekt (id 3) - andel dubbellagrade objekt (id 4) 100 % av förekomsterna ska överensstämma med informationsutbytesmodellen (Id 13).

57 55 (121) Styrgruppen grad av överensstämmelse avseende det konceptuella (begreppsmässiga) schemat Domänkonsistens grad av överensstämmelse avseende värdedomän (tilllåtna värden) Topologisk konsistens grad av korrekthet i topologiska egenskaper 100 % av förekomsterna ska överensstämma med värden i kodlistor. (Id 17). Inga ytfel för närliggande ytor får finnas. (D26, Id 24) Inga självkorsningsfel får finnas (D27, Id26) Inga självöverlappningsfel får finnas (D28, Id27) Lägesnoggrannhet osäkerhet i positionsangivelser Tematisk noggrannhet noggrannhet i tematiska förhållanden (t.ex. att objekt-typerna är korrekta) Temporal kvalitet osäkerhet i temporala (tidsmässiga) förhållanden Absolut noggrannhet osäkerhet i positionsangivelser i förhållande till referenssystemet Klassificeringsnoggrannhet grad av korrekthet hos företeelsers/objekts klassificering Tematisk noggrannhet, kvalitativa attribut korrekthet för icke mätbara egenskaper Tematisk noggrannhet, kvantitativa attribut noggrannhet för mätbara egenskaper Tidsnoggrannhet noggrannhet för redovisade tidmätningar Temporal konsistens grad av korrekthet i tidsordning Temporal validitet grad av korrekthet i tidsangivelser Krav på RMS i plan (Id 47) Krav på RMS i höjd (Id 39) HMK-Standardnivåer kan vara vägledande för krav på noggrannhet. (Id 60-64) t.ex. en kodlista, en metod är missklassificeringsmatris (Id 65-67) t.ex. antal felstavade namn (Id 68-73) t.ex. beräkningar på tal Osäkerhet för tidsaspekter (Id 54-59) Mått på korrekt ordningsföljd (Id 159) Mått på giltiga tidsvärden (Id 14-18)

58 56 (121) Styrgruppen 8 Metadata Metadata anges på datamängdsnivå enligt den Nationella metadataprofilen (aktuell version). Grundläggande metadata beskriver innehåll i data som kan erhållas samt var och vem som ansvarar för leverans. Titel, referensdatum, språk, ämnesområde, sammanfattning samt kontakt och datum för metadatat är obligatoriskt. Se För planering, bygglovshantering, miljöarbete, krisarbete, infrastrukturbyggande och fastighetsbildning är aktualitet en mycket viktig parameter. Uttagsdatum för datamängd speglar till viss del aktualitet. Metadata kan också anges på objektnivå framförallt när det gäller geometrier. Metadata kan även sättas på objektnivå för annat än geometri och uttrycks då vanligen som attribut på enskilda objekttyper. Krav 12 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. 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. Rekommendation 4 Leverans ska ske enligt Svensk Geoprocess GML-schema. 9.1 Leveransformat Beteckning Version 1.0 Specifikation Filstruktur Språk Exempel för tema: Teckenuppsättning XML (extensible Markup Language) Svenska Utf-8 Rekommendation 5 Leverans ska ske enligt XML-scheman

59 57 (121) Styrgruppen 10 Datafångst och underhåll I detta kapitel beskrivs de krav som finns på de processer som skapar Byggnadsdata. Byggnadsdata ingår som en del i fastighetsregistret. I förordning om fastighetsregister (se SFS 2000:308) paragraf 60 finns regler om förande av byggnadsdelen. na överensstämmer helt med bestämmelserna i 55 om förande av adressdelen. Byggnadsdelen innehåller följande: - Byggnad För varje byggnad redovisas beteckning, adress (om sådan finns i adressdelen), uppgift om belägenhet (koordinater som beskriver schablon eller verklig geometri) - Uppgifter från fastighetstaxeringen får redovisas - Tilläggsinformation (ex. uppgifter om skyddsrum) En stor del av produktionen görs 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. 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. 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. Tydliga regler finns för hur företeelser ska mätas in och hur geometrier som representerar de ska skapas. Hur den geometriska representationen av utbytesobjekt ska ske är beskrivet i Mätningsanvisningar med sammanställda och fastställa regler för geodata både på en nationell nivå och för geodata som skapas i kommunala verksamheter. 11 Presentationsregler har inga regler för presentation. 12 Övrig information 13 Referenser 13.1 HMK Handbok för mät och kartfrågor HMK-Fotogrammetrisk detaljmätning juni 2015 HMK-Geodatakvalitet 2017 HMK-Ordlista 2015 HMK-Introduktion 2017

60 58 (121) Styrgruppen 13.2 Standarder och tekniska rapporter utgivna genom SIS SIS/TK 489 N247 Geodata- Nationell metadataprofil Specifikation 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:2016 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 SIS termdatabas Ekvator 13.3 Övriga referenser Inspire D2.8.III.2 v Data specification on buildings technical guidelines D2.5: Generic conceptual Model, Version Inspire - Tillägg till genomförandebestämmelser gällande datamängders och datatjänsters interoperabilitet OGC City Geography Markup Language (CityGML) En-coding Standard, version W3C XML Schema Language (XSD) OGC Geography Markup Language, CoClass

61 59 (121) Styrgruppen Bilaga A. Test av specifikationsuppfyllelse Kapitlet behandlar i första hand hur en leverantör validerar att följs i leveransen samt att mottagare validerar att möjligheterna finns att ta emot datamängder levererade enligt. Test för validering att levererande och mottagande system följer Genomför följande kontroller och arbetssteg för att kontrollera att leveransen (levererande eller mottagande system) följer. Avvikelser i leveranser (levererande system) rapporteras i metadata. Kontroll av dataformat/datastruktur Kontrollera mot XML-schema inklusive värdelistor att leverans kan ske i enlighet med dessa (uppdatera krav id mot respektive tema) Kontrollera att obligatoriska attribut och associationer finns med i utbyte (krav 1) Kontrollera att informationsutbytesmodellens angivelser för multiplicitet följs (krav 2) Kontrollera att värdet i endlifespanversion inte är före värdet i beginlifespanversion om endlifespanversion anges (krav 10) Kontroll av domänkonsistens Kontrollera att datamängdens värden överensstämmer med de värden som finns uppräknade i värdelistor (krav 3) Kontrollera att utökade värden i värdelistor inte konkurrerar med värden i ursprunglig värdelista (krav 5) Samverka med andra intressenter om utökning av kodlistor (krav 6) Kontrollera att datamängden är levererad enligt tabell 5 - tillåtna koordinatsystem (SWEREF 99 TM inkl. lokala zoner och RH 2000) (krav 11) Historiska bilder undantas från denna regel och levereras i befintligt koordinatsystem. Kontroll av datakvalitet Kontrollera datakvalitet mot specificerade krav i geodataspecifikationen. Kontroll av fullständighet Kontrollera att alla objekt har identitet (krav 7). Metadata Kontrollera att specifikationsuppfyllelse är angett i metadata (krav 12). Exempel Byggnad: Kontroller av logisk konsistens som kan utföras maskinellt för en leverans enligt Svensk geoprocess. Kontrollera att de klasser generaliserade från SG_BasKlass har attributen id och beginlifespanversion,

62 60 (121) Styrgruppen Kontrollera att BY_AggregeradByggnad även har identitet, härledd geometri aggregerad- ByggnadGeometri och en koppling till minst en BY_FysiskByggnad Kontrollera att BY_FysiskByggnad har härledd geometri och en koppling till minst en BY_Byggnad Kontrollera att BY_Byggnad har ett byggnadsändamål och en status angivet Kontrollera att BY_Byggnad har koppling till minst en BY_Byggnadsdel o.s.v.

63 61 (121) Styrgruppen Bilaga B. Fullständig informationsutbytesmodell Informationsutbytesmodell över Byggnad. Beskrivning hur modellen tolkas återfinns i dokumentet Basmodell. Bilaga B.1 Objekttyper class Fullständig informationsmodell objekttyper SG_Datamangd «DataSet» BY_ByggnadObjekttyper::BY_ByggnadDatamangd ::SG_Datamangd + id: Identifier + uttagdatum: DateTime + metadata: Any [0..*] + koordinatsystemplan: GE_KoordinatsystemPlan + hojdsystem: GE_Hojdsystem [0..1] + dimension: GE_Dimension [0..1] +bestarav 0..* «featuretype» BY_ByggnadObjekttyper::BY_Byggnadsdel SG_BasKlass «featuretype» BY_ByggnadObjekttyper:: 0..* +bestarav BY_AggregeradByggnad SG_BasKlass + /geometriaggregeradbyggnad «featuretype» + externreferens: ExternalReference [0..*] BY_ByggnadObjekttyper::BY_Byggnad + coclass: SG_CoClass [0..1] ::SG_BasKlass + byggnadnummer: Integer + id: Identifier + byggnadandamal: BY_ByggnadAndamal [1..*] + beginlifespanversion: DateTime + byggnad: SG_ [0..*] {ordered} + endlifespanversion: DateTime [0..1] + status: BY_ByggnadStatus + bygglovstatus: BY_BygglovStatus [0..*] + byggnadarea: Integer [0..1] +bestarav + boarea: Integer [0..1] + byggnadkaraktar: BY_ByggnadKaraktar [0..1] 1..* +bestarav 2..* + byggnadanmarkning: BY_ByggnadAnmarkning [0..*] SG_BasKlass + undantagenfranadressattning: Boolean [0..1] «featuretype» + ofrigrund: Boolean [0..1] +bestarav BY_ByggnadObjekttyper:: + externreferens: ExternalReference [0..*] BY_FysiskByggnad + coclass: SG_CoClass [0..1] 0..* ::SG_BasKlass + /geometrifysiskbyggnad +bestarav + id: Identifier + externreferens: ExternalReference [0..*] + beginlifespanversion: DateTime + coclass: SG_CoClass [0..1] 1..* + endlifespanversion: DateTime [0..1] ::SG_BasKlass + id: Identifier + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] + byggnadnummerdel: Integer [0..1] + byggnadandamaldel: BY_ByggnadAndamal [0..*] + statusdel: BY_ByggnadStatus [0..1] + bygglovstatusdel: BY_BygglovStatus [0..*] + antalvaningarovermark: Integer [0..1] + antalvaningarundermark: Integer [0..1] + absoluthojd: BY_AbsolutHojd [0..*] + relativhojd: BY_RelativHojd [0..*] + boareadel: Integer [0..1] + heltundermark: Boolean [0..1] + byggnadkaraktardel: BY_ByggnadKaraktar [0..1] + taktyp: BY_TakTyp [0..*] + geometrilod0: BY_ByggnadGeometriLoD0 [0..*] + geometri3dlod1: BY_ByggnadGeometri3DLoD1 [0..1] + geometri3dlod2: BY_ByggnadGeometri3DLoD2 [0..1] + geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] + externreferens: ExternalReference [0..*] + coclass: SG_CoClass [0..1] +harbyggnadstillbehor 0..* SG_BasKlass «featuretype» BY_ByggnadObjekttyper::BY_Byggnadstillbehor byggnadstillbehor: BY_ByggnadTillbehor + + status: BY_ByggnadStatus [0..1] + geometrilod0: BY_ByggnadGeometriLoD0 [0..*] + geometri3dlod3: BY_ByggnadGeometri3DLoD [0..1] + externreferens: ExternalReference [0..*] + coclass: SG_CoClass [0..1] +begransarbyggnadsdel 0..1 ::SG_BasKlass + id: Identifier SG_BasKlass +begransarbyggnadstillbehor + beginlifespanversion: DateTime SG_BasKlass «featuretype» + endlifespanversion: DateTime [0..1] «featuretype» BY_ByggnadObjekttyper::BY_Begransningsyta 0..1 BY_ByggnadObjekttyper::BY_Oppning + geometri: GM_Surface + geometri: GM_Surface + geometrimetadata: GE_GeometriMetadata [0..1] + geometrimetadata: GE_GeometriMetadata [0..1] + externreferens: ExternalReference [0..*] +oppning + externreferens: ExternalReference [0..*] + coclass: SG_CoClass [0..1] +bestarav + coclass: SG_CoClass [0..1] 0..* ::SG_BasKlass ::SG_BasKlass + id: Identifier 0..* + id: Identifier + beginlifespanversion: DateTime + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] «featuretype» «featuretype» «featuretype» BY_ByggnadObjekttyper:: BY_ByggnadObjekttyper: BY_ByggnadObjekttyper:: BY_Takyta :BY_SkymdGolv yta BY_Bottenyta «featuretype» «featuretype» BY_ByggnadObjekttyper:: BY_ByggnadObjekttyper:: BY_Fonster BY_Dorr «featuretype» «featuretype» «featuretype» BY_ByggnadObjekttyper:: BY_ByggnadObjekttyper:: BY_ByggnadObjekttyper:: BY_SkymdTakyta BY_Stangningsyta BY_Vaggyta

64 62 (121) Styrgruppen Bilaga B.2 er och kodlistor class Fullständig informationsmodell datatyper kodlistor Geometridatatyper «datatype» «codelist» BY_Byggnader::BY_ByggnadAndamal BY_ByggnadKodlistor:: BY_ByggnadAndamalTyp + byggnadandamaltyp: BY_ByggnadAndamalTyp + huvudandamal: Boolean [0..1] «DataType» «datatype» «codelist» BY_Byggnader::BY_ByggnadGeometriLoD0 BY_Byggnader::BY_ByggnadAnmarkning BY_ByggnadKodlistor:: BY_ByggnadAnmarkningTyp + punktgeometri: GM_Point [0..1] + anmarkningtyp: BY_ByggnadAnmarkningTyp + ytgeometri: GM_Surface [0..1] + anmarkningtext: CharacterString [0..1] + belägenpåoidentifieratområde + geometrimetadata: GE_GeometriMetadata + forskningsstation + planlagetyp: BY_PlanLageTyp + hembygdsgård + hojdlagetyp: BY_HojdLageTyp + naturum «datatype» «codelist» BY_Byggnader::BY_Relativ Hojd BY_ByggnadKodlistor::BY_HojdLageTyp + hogstahojdlagetyp: BY_HojdLageTyp + byggnadens högsta punkt + lagstahojdlagetyp: BY_HojdLageTyp + takets högsta punkt (nock) + hojdvarde: Real + takkant, generell + takkant, lägsta + takkant, högsta «DataType» + lutande takkontur BY_Byggnader:: + takfot, generell «datatype» BY_ByggnadGeometri3DLoD + takfot, lägsta BY_Byggnader:: + takfot, högsta BY_AbsolutHojd + ytgeometri: GM_Surface [0..*] + generell takhöjd + kropp: GM_Solid [0..1] + hojdlagetyp: BY_HojdLageTyp + lägsta våning ovan mark vid överhäng + terrangskarning: GM_Curve [0..*] + hojdvarde: Real + entrénivå + geometrimetadata: GE_GeometriMetadata + färdigt golv + hojdlage3dbotten: BY_HojdLageTyp + sockelhöjd + husgrund + markens medelhöjd + markhöjd, lägsta + markhöjd, högsta + byggnadens lägsta punkt + fiktivt höjdläge under marknivå + illustrativt läge «DataType» «DataType» + ospecificerat läge BY_Byggnader:: BY_Byggnader:: BY_ByggnadGeometri3DLoD1 BY_ByggnadGeometri3DLoD2 + planlagetyp: BY_PlanLageTyp + planlagetyp: BY_PlanLageTyp + hojdlage3dtopp: BY_HojdLageTyp «codelist» BY_ByggnadKodlistor:: BY_PlanLageTyp + fasad + takkant + husgrund + illustrativt läge + ospecificerat läge «codelist» «codelist» BY_ByggnadKodlistor:: BY_ByggnadKodlistor:: «codelist» «datatype» «codelist» BY_TakTyp BY_ByggnadTillbehor BY_ByggnadKodlistor:: BY_Byggnader::BY_Bygglov Status BY_ByggnadKodlistor::BY_Bygglov AtgardTyp BY_ByggnadStatus + lågt lutande tak + altan + bygglovatgardtyp: BY_BygglovAtgardTyp [0..1] + nybyggnad + pulpettak + balkong + planerad + bygglovstatustyp: BY_BygglovStatusTyp [0..1] + tillbyggnad + sadeltak + brandvägg + gällande + beslutsdatum: DateTime [0..1] + ombyggnad eller ändrad användning + valmat tak + lastbrygga + avregistrerad + atgardar: DateTime [0..1] + rivning + mansardtak + mast + befintlig byggnad + halvvalmat tak + skorsten + kägeltak + takfönster «codelist» + pyramidtak + takkupa BY_ByggnadKodlistor:: + kupoltak + trappa BY_Bygglov StatusTyp + bågtak + penthustak + ansökan + sågtandtak + beviljat lov + tälttak + startbesked + dubbelkrökt tak + slutbesked + ej via bygglov «codelist» BY_ByggnadKodlistor:: BY_ByggnadKaraktar + enslig stuga i fjällen + fjällstation + fyrbyggnad + herrgård + klockstapel + kyrka + kåta + moské + raststuga + religiös byggnad + slott + synagoga + tempel + torn + turiststuga/övernattningsstuga + vindkraftverk + väderkvarn

65 63 (121) Styrgruppen Bilaga B.3 Kodlistor Byggnadsändamål Kodlistan BY_ByggnadÄndamål är en hierarkisk kodlista som anger giltiga värden för typer av ändamål. Kodlistan är hierarkiskt indelad i två nivåer; Översiktlig nivå och Detaljerad nivå. I denna specifikation ställs inte krav på vilken nivå som skall användas men möjligheterna finns att ställa sådana krav i ar som t.ex. samverkansprocesser eller avtal. Översiktlig nivå Detaljerad nivå Beskrivning 1 Bostad Byggnad som till övervägande del innehåller bostäder för permanent- eller fritidsboende. Källa: SIS-TS : SGP Byggnad Bostad Småhus friliggande Byggnad som inte är sammanbyggd med annat småhus och är inrättad som bostad för en eller två hushåll. Källa: SGP Byggnad + SIS-TS :2014

66 64 (121) Styrgruppen Översiktlig nivå Detaljerad nivå Beskrivning Bostad Småhus kedjehus Två eller flera byggnader, som är sammanbyggda via garage, förråd eller liknande, och är inrättad som bostad för en eller två hushåll. Källa: SGP Byggnad Bostad Småhus radhus Byggnad inrättad till bostäder åt minst tre hushåll vars bostadsdelar är direkt sammanbyggda med varandra i en rad. Källa: Terminologicentrum TNC, Plan- och byggtermer SGP Byggnad

67 65 (121) Styrgruppen Översiktlig nivå Detaljerad nivå Beskrivning Bostad Flerbostadshus Byggnad inrättad till bostäder åt minst tre hushåll. Källa: SIS-TS : SGP Byggnad Bostad Småhus Parhus Byggnad inrättad med två bostäder för en eller två hushåll och är sammanbyggda parvis i mellanliggande fastighetsgräns. Källa: SGP Byggnad + SIS-TS :2014 (tvåbostadshus) + Teminologicentrum TNC, Plan- och Byggtermer 1994