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

Transkript

1 GEODATASPECIFIKATION 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 Torsten Svärd - Lantmäteriet DOKUMENTNUMMER DOKUMENTDATUM BETECKNING /3029 VERSION FASTSTÄLLD VERSION DOKUMENTDATUM ÄNDRING 3.0 TEST Grundversion, utbrutet från dokument för separata tema v Korrigeringar efter remissutgåva Test Förändrade ar: Geometri Ytgeometri Geometri metadata samt korrigering av stavfel CoClass Ny multiplicitet för CoClasskoden Datamängd Attribut metadata ny datatyp (URI) Metadata, Person ska ej anges (NMDP 4.0) GeometriMetadata Nytt attribut Geoidmodell xml-geometri Kompletterat EPSG-koder för 3D Projekt Attribut projektomrade flyttat från respektive subtyp Korrigerade kravnummer Omformuleringar attribut och kodlista om dimension Punktgeometri omformulering dimension 6. Referenssystem Omformuleringar om dimensioner och transformationer Tabell 5 Kompletterat med en EPSG-kod Projektet avslutades juni 2016 och Samverkan ansvarar nu för förvaltning och vidareutveckling av geodataspecifikationerna. XML-scheman finns tillgängliga på hemsida

3 Geodataspecifikation 1 (66) Styrgruppen Bakgrund I samverkansprojektet utarbetas geodataspecifikationer för nio utvalda geodatateman. Målet med arbetet är att kunna leverera enhetliga geodata oavsett administrativa gränser, vilket bidrar till enklare och effektivare myndighetsutövning för till exempel planarbete, fastighetsbildning och bygglovshantering, miljö- och krisarbete samt infrastrukturbyggande. Arbetet med att utforma och förvalta specifikationerna bedrivs i samverkan mellan kommuner, Lantmäteriet och för temat andra berörda myndigheter. Specifikationerna baseras i stort på standarden SS-EN ISO 19131:2008, Geografisk information Specifikation av datamängder även om avsteg görs. Specifikationerna utnyttjar både internationella och svenska standarder samt är i möjligaste mån överensstämmande med Inspire s dataspecifikationer för motsvarande geodatateman. Introduktion till Geodataspecifikation Geodataspecifikationen är ett dokument som tagits fram i samverkan mellan SKL, Lantmäteriet och kommunerna. Specifikationen innehåller informationsmodell och krav på geodata som beskriver basen för modellerna i Svensk Geoprocess. Geodataspecifikationen skildrar tillsammans med processen ett framtida scenario av gemensamma modeller och ett arbetsflöde där flera aktörer samverkar för att effektivisera samhällsbyggnadsprocessen (processen innehåller en redogörelse av hur samverkan kring insamling, lagring och tillhandahållande ska gå till och tas också fram inom ). Med bas avses grundläggande information som är gemensam för flera teman. T.ex. att alla objekttyper har identitet och geometrin hanteras på ett enhetligt sätt för de objekt som har geometri. Det finns också gemensamma kodlistor. ens beståndsdelar läses enklast ur avsnitt 5 som innehåller både en informationsutbytesmodell (grafisk i UML 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. Specifikationer med informationsutbytesmodeller och XML-scheman som tas fram i är tänkta att kunna användas för utbyte av geodata i många olika sammanhang. Detta medför att de i mångt och mycket har karaktären av en bruttolista av allt som kan tänkas utbytas enligt specifikationernas teman. Verksamhetsregler som i många fall kan ses som tekniska realiseringar av avtal eller överenskommelser är inte en del av då det skulle begränsa möjliga användningsområden för specifikationer med mera. Detta innebär dock att man i många fall kommer att behöva göra begränsningar av vad ur specifikationer som får utbytas och tydligare regler kring hur detta ska ske. Visar det sig att samma begränsningar och striktare regler kring utbyte återkommer i många fall nationellt sett så är det en fråga för Samverkan att besluta om dessa begränsningar och striktare regler ska införlivas i specifikationer, informationsutbytesmodeller och XML-scheman. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 1

4 Geodataspecifikation 2 (66) Styrgruppen Krav på data enligt denna specifikation uttrycks i respektive tillämpligt avsnitt av specifikationen. Krav skrivs på egen rad med fet stil i röd färg undantaget datakvalitetskrav. Rekommendationer skrivs på egen rad med fet stil i blå färg. Denna geodataspecifikation är tillgänglig som ett dokument (.pdf) från Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 2

5 Geodataspecifikation 3 (66) Styrgruppen INNEHÅLLSFÖRTECKNING 1 GEODATASPECIFIKATIONENS OMFATTNING 5 2 ÖVERSIKT Information om geodataspecifikationen Information om 9 3 BASMODELLENS OMFATTNINGAR 9 4 IDENTIFIERING AV SVENSK GEOPROCESS BASMODELL 9 5 DATAINNEHÅLL OCH STRUKTUR Översikt struktur Informationsutbytesmodell och objekttypskatalog Ordning på attribut och associationer Beroenden till andra specifikationer 33 6 REFERENSSYSTEM Referenssystem i Höjdsystem Tidssystem Geoidmodell Benämning av koordinater 35 7 KVALITETSKRAV Datakvalitet 36 8 METADATA 36 Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 3

6 Geodataspecifikation 4 (66) Styrgruppen 9 TILLHANDAHÅLLANDE DATAFÅNGST OCH AJOURHÅLLNING PRESENTATIONSREGLER ÖVRIG INFORMATION REFERENSER HMK Handbok för mät och kartfrågor 37 1 Standarder och tekniska rapporter utgivna genom SIS Övriga referenser 37 BILAGA A. TEST AV SPECIFIKATIONSUPPFYLLELSE 38 BILAGA B. BESKRIVNING AV UML FÖR SVENSK GEOPROCESS INFORMATIONSMODELLER 38 BILAGA C. FULLSTÄNDIG INFORMATIONSUTBYTESMODELL 43 SG_BasObjekttyper 43 SG_Baser 48 SG_Kodlistor 50 GE_Geometrimetadata 54 GE_GeometriKodlistor 59 BILAGA D. KRAV OCH REKOMMENDATIONER 65 BILAGA E. RELATIONER TILL DATA ENLIGT SPECIFIKATIONER SOM EJ OMFATTAS AV SVENSK GEOPROCESS. 65 Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 4

7 Geodataspecifikation 5 (66) Styrgruppen 1 Geodataspecifikationens omfattning Detta dokument utgör en geodataspecifikation för klasser som är gemensamma för flera temaspecifikationer inom. Dokumentet har framställts på uppdrag av Lantmäteriet, kommunerna, SKL och andra myndigheter. 2 Översikt 2.1 Information om geodataspecifikationen Titel Datum Ansvarig part Språk Ämnesområde Syfte Geodataspecifikation Lantmäteriet i samverkan med kommuner och SKL Lantmäteriet, Division Geodata, enheten Geografisk information Adress Gävle Telefon E-post URL Svenska Termer och definitioner svenskgeoprocess@lm.se Ej relevant för gemensamma klasser Specifikation av de nationella krav som ställs på utbyte av information mellan kommuner, leverantörer och myndigheter. Utbyte kan avse både från producent till datalager eller från datalager till användare. Denna geodataspecifikation riktar sig i första hand till dataproducenter, systemleverantörer och systemutvecklare som ansvarar för att utbyta datamängder enligt SGP temaspecifikationer. Källa om annan än anges inom hakparentes [ ]. UML-specifika termer och vissa modelleringstekniska termer beskrivs i Bilaga B. Generella termer Tabell 1. Term Abstrakt klass Association Attribut klass som inte motsvarar en verklig företeelse [Ekvator] Kommentar: representerar gemensamma egenskaper för klasser t.ex. attribut och roller. samband mellan klasser Kommentar: beskrivs med roller i egenskap för en klass beskriven genom de värden den kan anta [Ekvator] Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 5

8 Geodataspecifikation 6 (66) Styrgruppen Kommentar: Ett värde som representerar det observerade värdet av en egenskap hos en Företeelse Begreppsmodell Datamodell Egenskap Företeelse Företeelsetyp Geodataspecifikation Generic Conceptual Model Informationsmodell Koordinatsystem Kvalitetsmått Kvalitetsparameter Kvalitetstema Kodlista Lägesosäkerhet Metadata modell som beskriver begrepp, deras egenskaper och inbördes relationer [GIS-ordbok] på logisk nivå över hur data är organiserade i en databas [GIS-ordbok] specifikation av värdedomän och de operationer som är tillå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), 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 Ett dokument som beskriver alla krav som ställs på datamängder. Krav avser struktur på data vid utbyte, obligatoriska element samt datakvalitetskrav. motsvarande basmodell i Inspire som beskriver gemensamma objekttyper, datatyper och kodlistor begreppsmodell som beskriver de olika objekttyper som är av intresse för en viss verksamhet [GIS-ordboken] uppsättning (matematiska) regler som anger hur punkter ska tilldelas koordinater t.ex. genom en kartprojektion 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 kvalitetsparametrar, 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 [GIS-ordbok] Kommentar: Metadata kan förekomma både på datamängdsnivå och objekttypsnivå samt av tjänster. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 6

9 Geodataspecifikation 7 (66) Styrgruppen Modellelement Multiplicitet Objekt Objekttyp Objekttypskatalog Referenssystem Komponent som bygger upp en modell. Exempel: Objekttyper, associationer och datatyper. anger hur många förekomster som ska eller kan förekomma representation av en företeelse i den verkliga världen [Ekvator] abstraktion av en grupp av företeelser med likartade egenskaper [Ekvator] förteckning över objekttyper samt deras attribut- och sambandsanalyser [Ekvator] uppsättning parametrar som specificerar ett koordinatsystems läge relativt jorden Källor till definitioner Tabell 2. 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 Inspire 1089/2010 Ekvator TR 14 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 teknisk rapporter (TR) utgivna av SIS, t.ex. 23, 24, 25, 26 Metadata på svenska Förkortningar Tabell 3. BSAB EPSG GALILEO GLONASS GML Byggandets Samordning AB, kodsystem för beteckning av byggdelar eller produktionsresultat 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. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 7

10 Geodataspecifikation 8 (66) Styrgruppen GNSS GPS GUID GUM HMK Global Navigation Satellite System. Samlingsbegrepp för satellitbaserade navigations- och positioneringssystem [HMK- Ordlista] Global Positioning System, Amerikanskt satellitbaserat positioneringssystem [HMK-Ordlista] Globally Unique Identifier. Version av UUID Guide to the Expression of Uncertainty in Measurement. Internationell standard för mätosäkerhet. [HMK-ordlista] 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 NMDP 4.0 Nationell MetaDataProfil version 4.0 Nätverks-RTK OGC 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 SWEPOS SWEREF 99 SWEREF 99 TM SWEREF 99 dd mm UML URI UUID XML Root Mean Square, en typ av (kvadratiskt) medeltal [HMK- Ordlista] Real Time Kinematic, Bärvågsmätning i realtid. Sveriges Kommuner och Landsting det svenska nationella nätet av fasta referensstationer för GNSS-mätning [HMK-ordlista] Swedish Reference Frame svensk realisering av det europeiska geodetiska referenssystemet ETRS 89 Swedish Reference Frame 1999 Transversal Mercator. Rikstäckande kartprojektion i svenskt tredimensionellt referenssystem Swedish Reference Frame 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] extensible Markup Language Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 8

11 Geodataspecifikation 9 (66) Styrgruppen Ett textbaserat överföringsformat för data där man själv definierar struktur och regler för data med hjälp av ett XMLschema (.xsd). I huvudsak avsett för att vara maskinläsbart men kan även läsas av människor. 2.2 Information om Beskrivning av innehåll Syfte Inom finns ett antal objekttyper, datatyper och kodlistor som är gemensamma för flera teman. Dessa beskrivs ingående i denna geodataspecifikation och endast översiktligt i de andra temaspecifika specifikationerna En gemensam basmodell skapar förutsättningar för att hantera samma funktioner på ett enhetligt sätt oavsett specifikation eller ämnesområde 3 ens omfattningar en har i sig inga kvalitetskrav eller andra behov av indelningar i omfattningar. 4 Identifiering av Titel Alternativ titel Versionsnummer 3.1 Sammanfattning Syfte Ämnesområde Typ av geometrisk representation en beskriver de objekttyper, datatyper och kodlistor som flera teman har gemensamt en ger förutsättningar för övriga teman inom Svensk Geoprocess att hantera objekten på ett likartat sätt Ej relevant Vektor, grid, TIN 5 Datainnehåll och struktur 5.1 Översikt struktur I kapitlet Informationsutbytesmodell nedan beskrivs alla ingående objekttyper och datatyper med attribut och roller som ingår i basmodellen. 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. 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 för information om hur UML har använts i Svensk Geoprocess. För att skapa enhetlighet bland de specifikationer som Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 9

12 Geodataspecifikation 10 (66) Styrgruppen tas fram inom har en uppsättning gemensamma objekttyper skapats som kan användas av alla specifikationer. Gemensamma klasser har prefixet SG eller GE för geometri. I några fall har klasser importerats från Inspire, standarder och gml, dessa har inget eller andra prefix och dess attribut och värden har behållit sin engelska form. erna är i de flera fall översatta inom Inspire eller standardiseringsarbete. Denna basmodell medför att identifierare, livscykelinformation, geometrier och av datamängder och metadata hanteras enhetligt Förändringar sedan version 3.0 test 1 Omstrukturering av ordningsföljden i kapitel 5.3 å, ä och ö i klassnamn och attributnamn ändrade till a, a respektive o Basklass Geometri Höjdläge Datamängd coclass flyttad till respektive objekttyp som använder koden Geometribasen är borttagen och attributen flyttade till SG_Geometri- Metadata och SG_Datamängd. GE_GeometriMetadata får nytt attribut om utförande organisation och gemensam kodlista för mätmetod plan och höjd Absolut/relativ höjd samt höjdlägetyp flyttas till byggnadsmodellen Huvudnamn anges genom ordningsföljd, namntyp/kategori ändras till namnstatus Har fått attribut för koordinatsystem plan, höjdsystem och dimension Förändringar till version 3.1 Metadata för SG_Datamangd, ny datatyp. CoClass ny multiplicitet, Nytt attribut geoidmodell för SG_GeometriMetadata och koordinatsystem för xml-geometrier är förändrade. Anpassningar till Nationell Metadataprofil (NMDP 4.0). Angivande av kontaktuppgifter ska inte ske till fysisk person Förändringar till version SG_projekt har ett nytt attribut projektomrade som lagts till från de 3 specialiseringarna BB_BildProjekt, GS_StompunktProjekt och HH_HojdDjupProjekt. Beskrivningar gällande dimension har formulerats om för attribut i SG_Datamängd, kodlista dimension, Punktgeometri och referenssystem. Beskrivning av koordinattransformation har formulerats om. 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 är indelad i ett eller flera paket. Utöver detta finns detta gemensamma paket som används av alla informationsutbytesmodeller. Informationsutbytesmodellen är uppdelad i avsnitt för att belysa de olika delarna av basmodellen. Kapitel 5 beskriver objekttyper, datatyper, kodlistor och roller översiktligt och med svenska definitioner för importerade datatyper. I kapitel 5 finns också förklaringar till de ingående elementen. Hela informationsutbytesmodellen återfinns i bilaga C. Generaliseringar och relationer mellan objekttyper i modellen representeras också grafiskt i bilaga C Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 10

13 Geodataspecifikation 11 (66) Styrgruppen 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 informationsutbytesmodellerna tillhandahålls som html. I objekttypskatalogen för basmodell beskrivs egendefinierade och importerade objekttyper. I informationsmodeller används benämningen kodlista för att beskriva tillåtna värden ett attribut kan anta. Kodlistor är utökningsbara. Krav 1 Krav 2 Krav 3 Krav 4 Krav 5 Krav 6 Rekommendation Informationsutbytesmodellens obligatoriska attribut och associationer ska finnas med i datamängd enligt denna geodataspecifikation Informationsmodellens 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. Modell för av element i basmodellen Gemensamma kodlistor förvaltas av Lantmäteriet. Element av objekttyp eller datatyp Kort av objekttypens eller datatypens viktigaste funktion och attribut. Beskrivning av attribut i objekttyper och datatyper samt roller attributnamn eller benämning av roll Multiplicitet (hur många företeelser det kan vara) Regel på datatypen som representerar attributets värde definition till attributet eventuell regel som styr objekttypen, datatypen eller rollen Beskrivning av kodlista Kodlista Värde definition för värdet Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 11

14 Geodataspecifikation 12 (66) Styrgruppen Basklass SG_BasKlass är en abstrakt klass som äger de mest grundläggande attributen som krävs vid utbyte av geodata. Många objekttyper i ärver egenskaperna från SG_BasKlass, undantag är Höjd, Bild, Vatten Markanvändning/Marktäcke och Stompunkter SG_BasKlass har två obligatoriska attribut, identitet och datum för då objektets version skapades eller blir giltigt. id beskrivs med datatypen Identifier som kommer från Inspire. SG_BasKlass class SG_BasObjekttyper Sammanhållande abstrakt klass på objektnivå för attribut som är grundläggande vid utbyte av geodata och som kan användas som superklass «featuretype» SG_BasKlass + id: Identifier + beginlifespanversion: DateTime + endlifespanversion: DateTime [0..1] Abstrakt basklass för vektorobjekt. Identiteten id är obligatorisk och inte nillable. beginlifespanversion är obligatorisk men nillable Attribut id 1 Identifier unik identifierare för det rumsliga objektet beginlifespanversion 1 DateTime datum då objektets version skapades hos ansvarig part endlifespanversion 0..1 Regel Regel DateTime datum från när objektet eller dess version inte längre gäller endlifespanversion är obligatorisk om beginlifespanversion levererats och versionen är utgången. Då attributet endlifespanversion förekommer får dess värde inte inträffa före värdet attributet beginlifespanversion 5. Identifierare Alla rumsliga objekt som levereras enligt Svensk Geoprocess ska ha en unik identitet som inte byts ut under dess giltighetstid. Vid förändringar av objektet behålls den unika identiteten men objektet representeras av en ny version. Svensk Geoprocess utnyttjar Inspires datatyp Identifier som med namespace och localid bygger upp en unik Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 12

15 Geodataspecifikation 13 (66) Styrgruppen identitet. UUID är en universellt unik identifierare bestående av 32 hexadecimala tecken separerade i fem grupper av bindestreck (-). Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 13

16 Geodataspecifikation 14 (66) Styrgruppen Identifier class SG_BasKlass «datatype» Base Types::Identifier + localid: CharacterString + namespace: CharacterString + «lifecycleinfo» versionid: CharacterString [0..1] extern unik objektidentifierare som offentliggörs av den ansvariga organisationen och som kan användas av externa tillämpningar för att referera till det rumsliga objektet. [Inspire 2010/1089] För localid rekommenderas UUID. Namespace skrivs på formen land.organisation.tema, versionid anger löpnummer i vilken ordning objektens representation gäller Exempel namespace: Datamängd med byggnader levererad av lantmäteriet SE.LM.BY Attribut localid 1 CharacterString En lokal identifierare som bestäms av dataleverantören. Den lokala identifieraren är unik i namnrymden, det vill säga inget annat rumsligt objekt har samma unika identifierare. [Inspire 2010/1089] namespace 1 CharacterString rymd med en unik identifiering av det rumsliga objektets datakälla. [Inspire 2010/1089] versionid 0..1 CharacterString identifieraren för just den versionen av det rumsliga objektet. Kan innehålla högst 25 tecken. Om specifikationen av en rumslig objekttyp med en extern objektidentifierare omfattar livscykelinformation används versionsidentifieraren för att särskilja mellan de olika versionerna av ett rumsligt objekt. Versionsidentifieraren är unik i uppsättningen av samtliga versioner av ett rumsligt objekt. [Inspire 2010/1089] I attributen localid och namespace får endast följande teckenuppsättning användas: { A Z, a z, 0 9, _,., }, det vill säga endast versala och gemena bokstäver i det latinska alfabetet, utom å, ä och ö, samt siffror, understreck, punkt och bindestreck är tillåtna. [Inspire ] 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. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 14

17 Geodataspecifikation 15 (66) Styrgruppen Rekommendation 2 LocalId som är ett attribut till typen Identifier ska vara av 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. Krav 10 Rekommendation Datamängd Då attributet endlifespanversion förekommer får dess värde inte inträffa före värdet attributet beginlifespan- Version. Datum, för när objekt skapades i databas hos ansvarig part, rekommenderas användas för attributet beginlifespanversion och alla objekt i en datamängd enligt denna geodataspecifikation Geodata levereras ofta 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 håller samman datamängder av vektortyp och ingår därför inte i alla informationsmodeller för bild och höjd, med undantag av punktmoln, höjdpunkter, punkthöjder, brytlinjer och nivåkurvor. SG_Datamangd class SG_Datamangd «DataSet» SG_Datamangd id: Identifier uttagdatum: DateTime metadata: URI koordinatsystemplan: GE_KoordinatsystemPlan hojdsystem: GE_Hojdsystem [0..1] dimension: GE_Dimension [0..1] Sammanhållande abstrakt klass på datamängdsnivå för attribut som är grundläggande vid utbyte av geodata och som kan användas som superklass En identitet, uttagsdatum, koordinatsystem för plan och metadata är obligatoriska. En datamängd angiven som plan/höjd-koordinater kan även innehålla objekt med bara plankoordinater. Metadata kan vara länk till metadata för datamängden där data hämtas ut. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 15

18 Geodataspecifikation 16 (66) Styrgruppen Attribut id 1 Identifier unik identifierare för datamängden uttagdatum 1 DateTime datum och tid för uttag av datamängd ur databas metadata 1 URI länk till metadata enligt Svensk metadataprofil koordinatsystemplan 1 GE_KoordinatsystemPlan koordinatsystem för objektgeometrins plankoordinater hojdsystem 0..1 definition GE_Hojdsystem referenssystem för objektgeometrins höjd dimension 0..1 GE_Dimension anger om objektgeometrin beskrivs med plankoordinater eller plan och höjdkoordinater Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 16

19 Geodataspecifikation 17 (66) Styrgruppen Metadata för datamängd Metadata kan beskrivas för en datamängd hos en tillhandahållare av data. En länk till denna metadata kan infogas i SG_Datamangd. 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. Metadata är obligatoriskt. Identifikation av metadata attribut xml fileidentifier unik identifierare för metadatamängden i form av UUID Språk language det språk enligt ISO som används i metadatamängden, anges med swe, Kan utelämnas om UTF-8 används Metadatauppgift Teckenuppsättning Arv från övergripande metadata Hierarkisk nivå för den datamängd metadata omfattar på hierarkisk nivå Metadatakontakt charcterset parentidentifier hierarchylevel hierarchylevelname contact datestamp Datum för metadata Metadatastandard metadatastandardname fullständigt namn på teckenuppsättningen som används i datamängden identifiering av metadata som detta metadata är en delmängd av omfattning som metadata beskriver. Obligatoriskt om det inte är datamängd. Kan vara t.ex. objekttyp namn på hierarkisk nivå. Obligatoriskt om hierarkisk nivå inte är datamängd ansvarig organisation för metadatainformation. E-post obligatorisk senaste datum på formen YYYY-MM-DD som påverkat metadata. Årlig kontroll av allmänna metadata bör ske, detta datum anges då metadatastandard enligt formen SS-EN ISO 19115:2005-SE 4.0 Titel title namn som datamängden är känd under Datum för datamängd Händelsedatum date datetype date: YYYY-MM-DD händelse bakom förändring av datamängd kodlista: creation, publication, revision Ämnesområde topiccategory ämnesområde(n) som beskriver huvudsakligt innehåll i datamängden MD_TopicCategoryCode t.ex.boundaries, inlandwaters Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 17

20 Geodataspecifikation 18 (66) Styrgruppen Sammanfattning sammanfattning av innehållet i datamängden Specifikationsuppfyllelse Beskrivning av secifikationsuppfyllelse abstract boolean URI anger om datamängd uppfyller kraven i Annex A för respektive specifikation. Boolean anger ja-true eller nej-false. Om false beskrivs avsteg genom beskrivinguppfyllelse redovisning av hur datamängd uppfyller enligt Bilaga A i specifikation 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 Identiteten byggs upp på följande sätt:ttyyyy_orgnr_löpnr TT=Typ av projekt yyyy=projektstartår orgnr=organisationsnummer löpnr=löpnummer Krav 11 Krav 12 För det obligatoriska attributet geodataagare ska genom datatypen RelatedParty attributet organisationname anges. Om något av de frivilliga attributen som redovisar roller (geodataproducent, uppdragsgivare) används ska genom datatypen RelatedParty individual, organisation eller position name anges. Rekommendation 4 De attribut som använder datatypen RelatedParty ska i attributet contact via datatypen Contact ange attributen electronicmailaddress och website. Rekommendation 5 De attribut som använder datatypen RelatedParty ska i attributet contact via datatypen Contact INTE ange attributet adress. Information om dataskapande/-insamlande verksamhet SG_Projekt information om dataskapande/-insamlande verksamhet. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 18

21 Geodataspecifikation 19 (66) Styrgruppen class SG_Projekt «featuretype» SG_Projekt projektid: CharacterString projektomrade: GM_MultiSurface geodataproducent: RelatedParty [0..*] geodataagare: RelatedParty [1..*] projekt: CharacterString [0..1] projektrapportlank: URI [0..1] uppdragsgivare: RelatedParty [0..*] projektid och geodataagare är obligatoriska. Då RelatedParty används för dessa attribut anges inte role. Projektomrade anges med geometrisk. Attribut projektid 1 CharacterString unik identitet för projekt projektomrade 1 GM_MultiSurface geometriskt objekt som täcker produktionsområdet geodataproducent 0..* RelatedParty organisation som producerar geodata. geodataagare 1..* RelatedParty rättighetsinnehavare till datamängd som produceras projekt 0..1 CharacterString namn på projekt. projektrapportlank 0..1 URI länk till en adress där projektrapport är tillgänglig. uppdragsgivare 0..* RelatedParty beställare av projekt. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 19

22 Geodataspecifikation 20 (66) Styrgruppen 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 och utförande organisation anges för inmätningen. Enligt Inspire kan två kodlistor användas för role: RelatedPartyRoleValue (Inspire) och PartyRoleCode (ISO 19115) PartyRoleValue följer kodlistan CI_RoleCode från 19115:2003 men har i Inspire genererats en profil RelatedPartyRoleValue Ansvarig part RelatedParty class SG_Projekt «datatype» Base Types 2::RelatedParty + «voidable» individualname: PT_FreeText [0..1] + «voidable» organisationname: PT_FreeText [0..1] + «voidable» positionname: PT_FreeText [0..1] + «voidable» contact: Contact [0..1] + «voidable» role: PartyRoleValue [0..*] en organisation med koppling till en resurs För datatypen RelatedParty rekommenderas att ange organisationname och kontaktuppgifter med datatypen Contact. role kan anges för av datamängder men ingår i projektets attribut. individualname ska inte användas då personuppgiftslagen kan träda in (ersätts av Dataskyddsförordningen, GDPR i maj 2018) Attribut IndividualName 0..1 PT_FreeText namn på kontaktperson Kommentar: får ej användas enligt NMDP 4.0 organisationname 0..1 PT_FreeText organisationens namn positionname 0..1 PT_FreeText partens position i dess relation till resursen contact 0..1 Contact Kontaktinformation för ansvarig organisation Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 20

23 Geodataspecifikation 21 (66) Styrgruppen role 0..* PartyRoleValue Roll eller roller för ägaren av informationsmängden från någon av kodlistaerna CI_RoleCode eller RelatedPartyRoleValue Kontaktuppgifter Contact class SG_Projekt Attribut «datatype» Base Types 2::Contact + «voidable» address: AddressRepresentation [0..1] + «voidable» contactinstructions: PT_FreeText [0..1] + «voidable» electronicmailaddress: CharacterString [0..1] + «voidable» hoursofservice: PT_FreeText [0..1] + «voidable» telephonefacsimile: CharacterString [0..*] + «voidable» telephonevoice: CharacterString [0..*] + «voidable» website: URL [0..1] kommunikationskanal för att möjliggöra åtkomst till något eller någon [Inspire fritt översatt, gäller hela datatypen] en Contact kommer från Inspire och skiljer sig från metadatastandardens CI_Contact genom t.ex. skilda online-attribut. Svensk Geoprocess rekommenderar att website och electronicmailaddress anges som kontaktinformation. Adress rekommenderas inte då datatypen AdressRepresentation från Inspire medför att GeographicalName är obligatoriskt och därmed många medföljande attribut. Kontaktuppgifter till person ska inte anges. address 0..1 Regel SGP AddressRepresentation en adress levererad som fri text ska inte användas contactinstructions 0..1 PT_FreeText tilläggsinformation om hur och när organisation kan kontaktas electronicmailaddress 0..1 Regel SGP CharacterString e-postadress till organisation bör användas hoursofservice 0..1 PT_FreeText Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 21

24 Geodataspecifikation 22 (66) Styrgruppen tidsperioder när organisation kan kontaktas telephonefacsimile 0..* CharacterString faxnummer till organisation telephonevoice 0..* CharacterString telefonnummer till organisation website 0..1 Regel SGP URL sidor på internet tillhandahållna av organisation bör användas Textfält Det finns olika sätt att representera text. Vanlig text i representeras av datatypen CharacterString. Inspire datatyper t.ex. RelatedParty använder ofta datatypen PT_FreeText där språkkod ska anges. class Textmodell PT_FreeText {root} 1 textgroup LocalisedCharacterString {root} 1..* 0..* locale 1 PT_Locale {root} languagecode: LanguageCode country: CountryCode [0..1] charactersetcode: MD_CharacterSetCode [0..1] PT_FreeText class Textmodell PT_FreeText {root} datatyp för flerspråkig text Kommentar: Ett metadataelement med de alternativa datatyperna textsträng och fritext. Fritextalternativet skiljer sig från vanlig textsträng genom dess möjligheter att ange avvikande språkkod, land och teckenuppsättning [19115 översatt] Roll textgroup 1..* roll LocalisedCharacterString tillhandahåller textsträng uttryckt i valt språk [19115 översatt] Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 22

25 Geodataspecifikation 23 (66) Styrgruppen LocalisedCharacterString class Textmodell uttryck för fritext i ett valt språk [19115 översatt] Textdatatyp som genom rollen locale kan ange språk LocalisedCharacterString {root} Roll locale 1 roll PT_Locale anger språk för textsträng PT_Locale class Textmodell PT_Locale av ett språk {root} Anger språkkod och har möjlighet till mer genom frivilliga attribut landskod och teckenkod för It-system languagecode: LanguageCode country: CountryCode [0..1] charactersetcode: MD_CharacterSetCode [0..1] Attribut languagecode 1 Kodlista LanguageCode treställig kod enligt ISO Exempel: swe country 0..1 Kodlista CountryCode tvåställig landskod enligt ISO 3166 Exempel: SE charactersetcode 0..1 Kodlista MD_CharacterSetCode teckenkod enligt Exempel: utf8 Regel Ska anges om den inte är utf8 Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 23

26 Geodataspecifikation 24 (66) Styrgruppen Okända värden För okända eller utelämnade värden används den inbyggda funktionen nillable från XML-schemaspecifikationen 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 nilreason anledning att ett värde utelämnas Kodlista inapplicable missing template unknown withheld other<briefexplanation> värde saknas värdet kan inte med enkelhet levereras av dataproducenten. Ett korrekt värde kan dessutom saknas värdet finns och kommer att kompletteras senare värdet är inte känt och kan inte beräknas av dataproducenten. Men ett värde finns troligen avslöjas ej av sekretesskäl annat skäl, där <briefexplanation> är en textsträng med minst 2 tecken och utan mellanrum Exempel då värde saknas och nilreason används: <typ:endlifespanversion nilreason="inapplicable" xsi:nil="true"/> Koordinatsystem Koordinatsystem anges med EPSG-kod enligt tabell 5 i kapitel 6.1 för datamängd, bildprojekt och höjdprojekt. I xml-paketet för geometri levereras EPSG-kod enligt kapitel 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. Specifik 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. Men för kvalitetsrapportering används begreppet noggrannhet för att stämma överens med kvalitetsstandarden. Nedan listas den information som kan levereras för respektive geometrityp: Punktgeometri realiseras av GM_Point genom det antal koordinater som ges av dimension Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 24

27 Geodataspecifikation 25 (66) Styrgruppen Linjegeometri Ytgeometri Kropp realiseras av GM_Curve som en sekvens av koordinater realiseras av GM_Surface genom sluten sekvens av koordinater realiseras av GM_Solid som byggs upp av ytor I xml finns för varje geometri en plats att ange koordinatsystem. I finns möjlighet att ange plansystem eller både plan- och höjdsystem genom de kombinerade koderna. Koordinatsystemen finns listade i tabellen 5 i kapitel 6.1. Exempel för ett 2 dimensionellt objekt i SWEREF 99 TM srsname="urn:ogc:def:crs:epsg::3006" srsdimension="2" 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 koordinatsatta brytpunkter sammanbundna med linjer. Kontinuerliga linjeobjekt t.ex. kurvor, cirkelbågar och klotoider transformeras till denna form för utbyte. Enbart utvalda linjer 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 samt vanligen med höjdvärde 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 mäts/redovisas. 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. GE_GeometriMetadata anger uppgifter om hur en geometri har mätts in m.m. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 25

28 Geodataspecifikation 26 (66) Styrgruppen class GE_GeometriMetadata «datatype» GE_GeometriMetadata lagesosakerhetplan: Real [0..1] lagesosakerhethojd: Real [0..1] matmetodplan: GE_InsamlingMetod [0..1] matmetodhojd: GE_InsamlingMetod [0..1] geoidmodell: GE_Geoidmodell [0..1] geometriskupplosning: Real [0..1] flyghojd: Integer [0..1] skalaunderlag: Integer [0..1] tidpunktmatning: DateTime [0..1] osakertlage: Boolean [0..1] osakertlageanledning: CharacterString [0..1] ansvarigorganisation: CharacterString [0..1] utforandeorganisation: CharacterString [0..1] HMK-Standardniva: GE_HMK-Standardniva foljermatningsanvisning: Boolean aktualitet: DateTime [0..1] Att ange metadata för Geometri är i sig frivilligt. Med datatypen finns möjlighet att ge många typer av information som beskriver hur inmätning skett där HMK- Standardnivå och angivande om mätningsanvisningar följts är obligatoriska. Attribut lagesosakerhetplan 0..1 Real standardosäkerhet för geometrins läge i plan lagesosakerhethojd 0..1 Real standardosäkerhet för geometrins läge i höjd matmetodplan 0..1 GE_InsamlingMetod beskriver vilken mätmetod som är använd för inmätning i plan matmetodhojd 0..1 GE_InsamlingMetod beskriver vilken mätmetod som är använd för inmätning i höjd geoidmodell 0..1 GE_Geoidmodell kodlista innehållande de geoidmodeller som för närvarande används för RH 2000 geometriskupplosning 0..1 Real Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 26

29 Geodataspecifikation 27 (66) Styrgruppen avståndet på marken mellan två närliggande pixelcentra i rasterdata [HMK] Kommentar: anges i meter för den bild inmätning sker från flyghojd 0..1 Integer meter över marken vid flygfotografering skalaunderlag 0..1 Integer skala på digitaliseringsunderlaget tidpunktmatning 0,,1 DateTime tidpunkt för mätning av geometrin osakertlage 0..1 Boolean markering om att direkt mätning av geometri inte kunnat ske osakertlageanledning 0..1 String anledning till att en geometri bedöms ha osäkert läge ansvarigorganisation 0..1 String organisation som är ansvarig för geometrin utforandeorganisation 0..1 String organisation som utfört mätningen av geometrin HMK-Standardniva 1 GE_HMK-Standardniva anger vilken standardnivå enligt HMK som används foljermatningsanvisning 1 Boolean notering om mätning följer mätningsanvisning aktualitet 0..1 DateTime det datum geometrin senast befanns vara korrekt Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 27

30 Geodataspecifikation 28 (66) Styrgruppen class SG_GeometriKodlistor «codelist» GE_InsamlingMetod flygburen laserskanning fordonsburen laserskanning marklaserskanning fotogrammetrisk detaljmätning (stereokartering) fotogrammetrisk detaljmätning (ortofoto) fotogrammetrisk detaljmätning (ortofoto + höjdmodell) geodetisk mätning, GNSS geodetisk mätning, GNSS med korrektion geodetisk mätning, totalstation geodetisk mätning, ospecificerad geodetisk mätning, avvägning digitalisering analog karta konstruerad annan konstruerad BIM annan metod «codelist» GE_KoordinatsystemPlan EPSG:3006 EPSG:3007 EPSG:3008 EPSG:3009 EPSG:3010 EPSG:3011 EPSG:3012 EPSG:3013 EPSG:3014 EPSG:3015 EPSG:3016 EPSG:3017 EPSG:3018 EPSG:4619 EPSG:4976 EPSG:4977 «codelist» GE_Geoidmodell SWEN05_RH2000 SWEN08_RH2000 SWEN17_RH2000 «codelist» GE_Hojdsystem EPSG: «codelist» GE_Dimension 2 3 «codelist» GE_HMK- Standardniv a Kodlistor till Geometri metadata Kodlista för insamlingsmetod GE_InsamlingMetod listar metoder för inmätning, kodlistan är gemensam för plankoordinater, höjd och kombinationer Kodlista HMK-Standardnivå Enligt HMK-Geodatakvalitet finns krav uppställda för 4 standardnivåer HMK-Standardnivå följer dessa krav: 0 Global/nationell mätning och kartläggning, lägesosäkerhet 1 meter eller sämre 1 Nationell/regional mätning och kartläggning, lägesosäkerhet mellan 1 dm och 1 m 2 Mätning och kartläggning i tätort, lägesosäkerhet bättre än 1 dm 3 Projektinriktad mätning och kartläggning, lägesosäkerhet bättre än 5 cm Kodlista för dimension kodlista för koordinatrepresentation i plan (värde 2) eller plan och höjd (värde 3), värde 3 kan även innehålla objekt med enbart plankoordinater. Kodlista för koordinatsystem plan Kodlista med EPSG-koder för koordinatsystem. Hur koderna används framgår av tabell 5 i kapitel 6.1. Bild har en egen kodlista med RT 90 som ytterligare alternativ. Kodlista för Höjdsystem Kodlista med höjdsystem, RH 2000 är gällande höjdsystem utom för Bild som har egen kodlista. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 28

31 Geodataspecifikation 29 (66) Styrgruppen 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 (2D). 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). 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 den beslutande myndigheten. Om ett objekt har flera namn kan flera förekomster finnas, för flerspråkiga namn är ordningen viktig, där det första ska vara det namn som skrivs ut på kartor. SG_ class SG_Baser «datatype» SG_ + namn: CharacterString + namnstatus: SG_Status + sprak: SG_Sprak + ansvarigbeslutsfattare: SG_AnsvarigBeslutsfattare [0..1] + externalreference: ExternalReference [0..1] gemensam klass för namn på geografiska objekt Om namnstatus är godkänt ska ansvarigorganisation anges. externalreference används för referens till ortnamnsregistret Attribut namn 1 CharacterString namnet i klartext namnstatus 1 SG_Status Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 29

32 Geodataspecifikation 30 (66) Styrgruppen kategori av namn sprak 1 SG_Sprak språk som namnet är angivet på ansvarigbeslutsfattare 0..1 Regel SG_AnsvarigBeslutsfattare organisation som beslutat om namnet obligatoriskt om namnstatus är godkänt externalreference 1 ExternalReference referens till ortnamnsregistret eller annan namnsättande organisation status anger om namnet är föreslaget, godkänt eller övrigt Språk SG_Sprak anger om språket är svenska eller något av minoritetsspråken Ansvarig beslutsfattare SG_AnsvarigBeslutsfattare anger om det är Lantmäteriet, kommun eller annan beslutsfattare 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. Exempel kan vara att ett namn har en post i ortnamnsregistret. ExternalReference class BasImporteradeer «datatype» BuildingsBase::ExternalReference + informationsystem: URI + informationsystemname: PT_FreeText + reference: CharacterString referens till annat informationssystem med någon typ av information förknippad med objektet en ExternalReference hänvisar till en annan representation genom attributen informationsystem med URI och namnet på informationssystemet. Objektet identifieras med reference som inom SGP är Identifier Attribut informationsystem 1 Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 30

33 Geodataspecifikation 31 (66) Styrgruppen URI enhetlig extern referens till informationssystemet informationsystemname 1 PT_FreeText namnet på det externa informationssystemet reference 1 CharacterString tematisk identifierare till det objekt eller information som relaterar till objektet CoClass CoClass ersätter BSAB 96 under hösten CoClass användningsområde är den byggda miljön. Om det finns en korresponderande CoClass-kod anges denna. Klassificering sker med 7 tabeller där tabellerna innehåller 3 generaliseringsnivåer, exempel: A AA Bostadskomplex Bostadsområde AAA Småhusområde AAB Flerbostadshusområde B BA BB Verksamhetskomplex Hotell- och restaurangområde Skydds- och försvarsområde Hela livscykeln från planering till rivning täcks in. CoClass är en kombination av koder och dess betydelse för tabell och klass. CoClass kod byggs upp av 2 bokstäver:kod (eventuell parantes med t.ex. namn eller GUID:GUID-sträng) Exempel: BV:AAA BX:AAA(Gammelstaden) BX:AAB(GUID:4HFR6-osv) Småhus Småhusområde med namnet Gammelstaden Flerbostadsområde med identitet Tabell 4. 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 Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 31

34 Geodataspecifikation 32 (66) Styrgruppen 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] SG_CoClass class SG_CoClass «datatype» SG_CoClass klassningssystem för informationsutbyte inom byggbranschen Information från byggbranschens klassningssystem. Identitet på formen GUID och tillhörande CoClasskod coclassid: CharacterString coclasskod: CharacterString [1..*] Attribut coclassid 1 CharacterString identifikation för CoClass-objekt i form av GUID coclasskod 1..* CharacterString klassifikation för byggd miljö Kommentar 1: Flera koder anges om t.ex. en byggnad har flera ändamål Kommentar 2: Skrivs på formen tabellkod:klasskod t.ex. BV:CBD som står för Byggnadsverk:Tågterminal Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 32

35 Geodataspecifikation 33 (66) Styrgruppen 5.4 Ordning på attribut och associationer I geodataspecifikationens motsvarande XML-schema hanteras attribut på objekttyper och datatyper på samma sätt som relationer med roller mellan objekttyper. Värdedomäner hanteras i ett separat XML-schema. Ordningen på attribut och roller är densamma som i informationsmodellen 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. 5.5 Beroenden till andra specifikationer är en grund för andra modeller som hänvisar till basmodellerna 6 Referenssystem Referenssystemen SWEREF 99 och RH 2000 används inom med vissa undantag.. Lokala zoner används ofta i kommunala tillämpningar, se rekommenderade zoner och Trafikverkets anpassning av zoner via länkar nedan. Bild har även andra tillåtna referenssystem. Transformation till andra referenssystem eller överräkning till andra projektionszoner ska ske med Gtrans eller annan programvara som följer anvisningarna i HMK-Geodetisk infrastruktur bilaga A2. Temporalt referenssystem anges med UTC +1 eller +2 vintertid/sommartid i de fall det är aktuellt. 6.1 Referenssystem i I tabell 5 redovisas hur EPSG-koderna används. Plan Höjd Används för attribut koordinatsystemplan Används för attributen hojdsystem och koordinatsystemhojd 2D Används normalt i geometripaketet i xml för objekt med plankoordinater, men även objekt även med höjd kan finnas 3D Används normalt i geometripaketet i xml för plan- och höjdkoordinater Tabell 5. Tillåtna referenssystem och dess EPSG-koder EPSG Benämning Mer om referenssystem kan läsas på Topografisk data och höjd Stompunkt 3006 SWEREF 99 TM Plan Plan Plan 2D 3007 SWEREF Plan Plan Plan 2D 3008 SWEREF Plan Plan Plan 2D Bild xml Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 33

36 Geodataspecifikation 34 (66) Styrgruppen 3009 SWEREF Plan Plan Plan 2D 3010 SWEREF Plan Plan Plan 2D 3011 SWEREF Plan Plan Plan 2D 3012 SWEREF Plan Plan Plan 2D 3013 SWEREF Plan Plan Plan 2D 3014 SWEREF Plan Plan Plan 2D 3015 SWEREF Plan Plan Plan 2D 3016 SWEREF Plan Plan Plan 2D 3017 SWEREF Plan Plan Plan 2D 3018 SWEREF Plan Plan Plan 2D 3019 RT gon V Plan 2D 3020 RT 90 5 gon V Plan 2D 3021 RT gon V Plan 2D 3022 RT 90 0 gon Plan 2D 3023 RT gon O Plan 2D 3024 RT 90 5 gon O Plan 2D 4619 SWEREF 99 Geografiskt (2D) Plan 2D 4976 SWEREF 99 Geocentriskt Plan 2D 4977 SWEREF 99 Geodetiskt (geografisk 3D) Plan 3D 5613 RH 2000 Höjd Höjd Höjd 5628 SWEREF 99 + RH D 5718 RH 70 Höjd 5845 SWEREF 99 TM + RH D 5846 SWEREF RH D 5847 SWEREF RH D 5848 SWEREF RH D 5849 SWEREF RH D 5850 SWEREF RH D 5851 SWEREF RH D 5852 SWEREF RH D 5853 SWEREF RH D 5854 SWEREF RH D 5855 SWEREF RH D Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 34

37 Geodataspecifikation 35 (66) Styrgruppen 5856 SWEREF RH D 5857 SWEREF RH D 7404 RT 90 + RH 70 3D På Lantmäteriets hemsida återfinns mer detaljerad av referenssystemen och de lokala projektionszonerna: har för tillämpningar för spårtrafik en anpassad användning av de lokala zonerna. Specifikation för dessa återfinns på Trafikverkets webbplats: Krav 13 Datamängder enligt denna geodataspecifikation ska tillhandahållas med referenssystem SWEREF 99 TM eller dess lokala zoner och RH 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. 6.3 Tidssystem Tidsuppgifter anges i UTC +1 för normaltid och UTC +2 för sommartid Temporalt referenssystem Gregorianska kalendern UTC +1 normaltid (CET) UTC +2 sommartid (CEST) 6.4 Geoidmodell Geoidmodeller i anges med värde ur kodlista GE_Geoidmodell SWEN05_RH2000 SWEN07_RH2000 SWEN17_RH2000 SWEN05 och RH2000 SWEN07 och RH2000 SWEN17 och RH Benämning av koordinater Benämning på koordinater görs enligt tabellen nedan, äldre bilder och stompunkter är exempel som kan använda RT 90 Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 35

38 Geodataspecifikation 36 (66) Styrgruppen Tabell 6 Benämning koordinater Koordinatsystem Nordlig koordinat (Northing) Östlig koordinat (Easting) Höjd SWEREF 99 TM N E RH 2000 H RT 90 x y SWEREF 99 Geografiskt (2D) geografiska koordinater, dvs läget på jordytan (GRS80-ellipsoiden) anges med latitud och longitud ϕ λ SWEREF 99 Geocentriskt SWEREF 99 Geodetiskt (geografisk 3D) geocentriska koordinater, dvs läget anges med rätvinkliga koordinater med origo i jordens centrum geodetiska koordinater, dvs läget anges med latitud, longitud och höjd över referensellipsoiden (GRS80) X Y Z ϕ λ h Mer om referenssystem kan läsas på EPSG-koder för referenssystem finns på 7 Kvalitetskrav 7.1 Datakvalitet Kvalitetskrav beskrivs inom respektive tema 8 Metadata Metadata för datamängd beskrivs i kap samt i kapitel om metadata för geometri. Metadata beskrivs också för vissa tema. 9 Tillhandahållande Tillhandahållande beskrivs för respektive tema 10 Datafångst och ajourhållning Datafångst beskrivs i specifikationerna för respektive tema. 11 Presentationsregler Det är tänkt att data enligt specifikationer ska kunna visas tillsammans, men hur detta ska ske har ännu inte fastställts. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 36

39 Geodataspecifikation 37 (66) Styrgruppen 12 Övrig information 13 Referenser 13.1 HMK Handbok för mät och kartfrågor HMK-Geodatakvalitet HMK-Ordlista 1 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 CoClass - Nya generationen BSAB Klassifikation och tillämpning v Inspire förordning 1089/2010 med tillägg D2.5: Generic conceptual Model, Version W3C XML Schema Language (XSD) OGC Geography Markup Language, Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 37

40 Geodataspecifikation 38 (66) Styrgruppen Bilaga A. Test av specifikationsuppfyllelse Test utförs genom respektive temas specifikation. Bilaga B. Beskrivning av UML för informationsmodeller Beskrivning av de i använda modellelementen. Modellerna visualiseras med modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa. I löptext markeras modellelement med kursiv text. Färgsättning Färgsättning av modellelement görs enligt Figur 1. Grå bakgrundsfärg på klass betyder att klassen är beskriven i annat tema. Vit betyder att klassen är beskriven i den aktuella modellen. En importerad klass kan komma från t.ex. Inspire class Färgsättning «featuretype» AnnanObjekttyp «datatype» Annan «codelist» AnnanKodlista «featuretype» TematsObjekttyp «datatype» Temats «codelist» TematsKodlista «featuretype» ImporteradObjekttyp «datatype» Importerad «codelist» ImporteradKodlista Figur 1 färgsättning inom Svensk Geoprocess Grunderna i modellering Klasser, relationer och generaliseringar De vanligast förekommande elementen i informationsmodellen är klasser, attribut, datatyper, kodlistor, relationer med roller och generaliseringar/specialiseringar. En klass motsvarar en objekttyp i informationsmodellen och representeras vanligen av en tabell i en databas för en datamängd. En klass har ett namn. Relationer uttrycker att en klass känner till en annan klass (exempel Klass 1 kännertill Klass 3Fel! Hittar inte referenskälla.). Hur klasserna känner till varandra ges av rollerna de har i relationen. Man kan även specificera multiplicitet för parterna i associationen, i Figur 2 uttrycks att Klass 1 känner till noll till många (0..*) av Klass 3 medan Klass 3 endast känner till en och endast en (1) av Klass 1. Om ingen multiplicitet är angiven förutsätts den vara en och endast en (1). Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 38

41 Geodataspecifikation 39 (66) Styrgruppen En generalisering/specialisering är en vanligt förekommande association, så vanlig att en egen symbol skapats för associationen, en ofylld triangel som pekar ut generaliseringsriktningen. Generaliseringar/specialiseringar skapas oftast då flera klasser har gemensamma egenskaper, istället för att upprepa egenskaperna på varje klass så skapar men en superklass (Klass 1) med de gemensamma egenskaperna. De specialiserade klasserna (Klass 2) ärver då superklassens egenskaper (attribut och associationer med mera). Om det inte finns något behov av superklassen i övrigt så görs den ofta abstrakt vilket innebär att man inte kan skapa objekt (instanser) av den. Att en klass är abstrakt syns på att klassens namn är skrivet med kursiv stil. Om man har behov av att kunna skapa objekt av olika konceptuella detaljeringsnivåer i en modell kan man använda generaliseringar/specialiseringar, ett exempel kan vara träd och barrträd. I vissa fall kanske man kan säga att det är ett barrträd som avses men i vissa andra fall kanske man bara vet att det är ett träd. På så vis kan man bygga upp en struktur som motsvarar den bild av verkligheten som en datamängd sedan kommer att beskriva/representera. Figur 2 Klasser, associationer och generaliseringar. Attribut, stereotyper, datatyper och kodlistor Klasser kan ha andra egenskaper än associationer, i Figur 3 visas stereotyper, attribut, datatyper och kodlistor. Attribut på en klass beskriver enkla eller komplexa egenskaper på klassen. I de enklaste fallen så är de av enkla fördefinierade typer. AttributA på Klass 10 är av datatypen Boolean (kan anta värdena true eller false ), attributc är av datatypen CharacterString vilket motsvarar en textsträng. Man kan även ange multiplicitet på ett attribut vilket talar om hur många gånger attributet får förekomma på ett objekt/attributc på Klass 10 får förekomma noll till många gånger, 0..*). Ett attribut kan också spegla en mer komplex egenskap som inte kan anges med en siffra, en text eller liknande. Man kan då ange en komplex datatyp som typ för attributet (attributb på Klass 10). Den komplexa datatypen kan man definiera själv som en klass med stereotypen <<datatype>> (se nedan) eller så kan man använda någon av de i standarder fördefinierade komplexa datatyperna. Exempelvis finns i metadatastandarden ISO :2014 en komplex datatyp för att tala om ansvarig part för en datamängd eller del av datamängd (CI_ResponsibleParty). Attribut kan också vara av en typ som kallas kodlista. En kodlista är en lista med värden som attributet får anta. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 39

42 Geodataspecifikation 40 (66) Styrgruppen Kodlistor är utökningsbara under premissen att utökningen görs tillgänglig tillsammans med datamängden. En kodlista ska inom Svensk Geoprocess inte använda andra betydelser än originallistan samt samverkas med andra intressenter. Synlighet för attribut redovisas före attributet. Det har i dessa informationsutbytesmodeller ingen betydelse om det står + eller - före attributet. Stereotyper (exempel <<featuretype>> på Klass 10) är ett sätt att gruppera klasser, attribut och associationer i en modell. I modeller förekommer fyra stereotyper på klasser och en stereotyp på attribut eller associationer De är: <<conceptual>>, anger att klassen motsvarar ett begrepp som identifierats vid skapandet av den helhetsbild som använts för att avgränsa ett tema i. <<featuretype>>, anger att klassen är en rumsligt förekommande objekttyp med en identitet. <<datatype>>, anger att klassen är en identitetslös datatyp som ofta används för att beskriva komplexa egenskaper på klasser. Dessa implementeras oftast som attribut <<codelist>>, anger att klassen innehåller tillåtna värden för ett attribut. Kodlistor förutsätts finnas tillgängliga. <<enumeration>> innebär en icke utökningsbar kodlista Svensk Geoprocess har inte skapat sådan kodlista men från gml kommer listan nilreason <<voidable>> förekommer i Inspire och betyder att information bör men måste inte lämnas. Om informationen utelämnas ska anledningen till detta anges med voidreason (motsvarande nilreason) Figur 3. Attribut, stereotyper, datatyper och kodlistor. Aggregering och komposition Aggregering representeras av en ofylld romb och innebär att Klass 4 i figur 4 kan bestå av en Klass 5. Om en instans av klass 4 raderas kan ändå instansen av klass 5 finnas kvar. En komposition representeras av en fylld romb och innebär på liknande sätt som en aggregering att Klass 6 kan bestå av en Klass 7. Om en instans av klass 6 raderas skall instansen av klass 7 också raderas. Exempelvis så kan inte ett personnummer finnas utan att det finns en person att koppla det till. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 40

43 Geodataspecifikation 41 (66) Styrgruppen Figur 4. Aggregering och komposition Beroenden och realisering Beroende och realisering (figur 5) är två andra specialiserade associationer som förekommer i modeller. Dessa associationer används för att belysa vissa aspekter men de implementeras inte själva direkt i en datamodell som övriga associationer. Ett beroende (streckad pil med öppen spets) innebär att Klass 8 har ett beroende till Klass 9. Ett konkret exempel är att respektive tema pekar ut de standarder som används i temat, detta görs med ett beroende, tema Vatten är till exempel beroende av den svenska vattensystemstandarden (SS637008:2015). Realisering (streckad pil med stängd, ofylld spets).fel! Hittar inte referenskälla. Figur 5 innebär att Klass 13 implementeras som Klass 9 i informationsmodell eller datamodell. I används realiseringar framförallt för att tala om hur de konceptuella begreppen realiseras i informationsmodellen Figur 5. Beroende och realisering Paketstruktur Alla modellelement är indelade i paket (figur 6). I förekommer följande paket under huvudpaketet Informationsutbytesmodell: GenerellaTemaberoenden är ett diagram som visar hur olika paket är beroende av varandra. SG_ Innehåller gemensamma klasser, datatyper och kodlistor och egenskaper som återkommer i flera teman i. Exempel geometrier och identifierare. SG_Temanamn Innehåller den enskilda modellen för varje tema inklusive kringinformation. o TemanamnPaketberoenden Visar beroenden mellan temat och andra paket. Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 41

44 Geodataspecifikation 42 (66) Styrgruppen o o o SG_TemanamnObjekttyper Innehåller ett eller flera diagram som visar den informationsutbytesmodell som beskriver temat. Informationsutbytesmodellen utgör underlag för datamodell. SG_Temanamner Innehåller de egendefinierade komplexa datatyper som används i temat. SG_TemanamnKodlistor Innehåller de egendefinierade kodlistor som används i temat. För förtydliganden eller andra skäl kan varje tema dessutom innehålla andra paket, till exempel importerade datatyper och kodlistor eller hur observationer på temats företeelser med hjälp av ISO Observations & Measurements ska beskrivas. För att kunna särskilja objekttyper mellan de xml-scheman de ingår i skapas i de schemagrundande informationsmodellerna nya prefix som är unika för varje tema Figur 6. Paketstruktur i Giltighet av detta dokument kontrolleras mot utgåvenummer i dokumentförteckningen. 42