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

Transkript

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

2 2 (63) UPPHOVSMAN DOKUMENTANSVARIG Maria Andersson, Lantmäteriet Tema Markdetaljer DOKUMENTNUMMER DOKUMENTDATUM BETECKNING /3031 VERSION FASTSTÄLLD VERSION DOKUMENTDATUM ÄNDRING NAMN Förslag till styrgrupp Grundversion framtagen Slutversion från projektet Svensk geoprocess. Ingela Nilsson Uppdragsledare: Ingela Nilsson (Agima) Arbetsgrupp: Linn Varhaugvik (Lantmäteriet) Katarina Lönnqvist (Stockholms stad) Anna Selander (Nyköpings kommun) Anders Carlström (Västerås stad) Jonny Jäwert (Örnsköldsviks kommun) Jan Karlsson (Hässleholms kommun) Göran Leiner (Nässjö kommun) Lars Börjesson (Skövde kommun) Olov Johansson (Metria AB) Geodataspecifikationerna i version är resultat från projektet. Specifikationerna är testade och harmoniserade med hjälp av framtagna datautbytesmodeller (XML-scheman) och exempel (XML). XML-scheman finns tillgängliga för tester på hemsida Projektet avslutade juni 2016 och Samverkan ansvarar nu för förvaltning och vidareutveckling av geodataspecifikationerna. Inför version 3.0 kommer under hösten pilotinföranden och fortsatta tester att genomföras, vilket kan komma att påverka innehållet i geodatasspecifikationerna.

3 3 (63) 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 Geodatapecifikation Markdetaljer är ett dokument som tagits fram i samverkan mellan SKL, Lantmäteriet och kommunerna. Specifikationen innehåller informationsmodell och krav på geodata som beskriver Markdetaljer. Geodataspecifikationen skildrar tillsammans med processbeskrivningen ett framtida scenario av temat Markdetaljer och ett arbetsflöde där flera aktörer samverkar för att effektivisera samhällsbyggnadsprocessen (processbeskrivningen innehåller en redogörelse av hur samverkan kring insamling, lagring och tillhandahållande ska gå till och tas också fram inom ). Med markdetalj avses fysisk företeelse ovan mark som påverkar processer inom samhällsbyggnadsområdet, t.ex. detaljplanering, bygglov och fastighetsbildning. Markdetaljer kan förekomma naturligt eller vara anlagda. Exempel på markdetaljer är stödmur, mast och brygga. Geodataspecifikationen avser de geografiska data om Markdetaljer som främst kommunerna, men till viss del även Lantmäteriet och andra aktörer, samlar in, lagrar och tillhandahåller. Geodataspecifikationen för Markdetaljer ska, tillsammans med andra datamängder (beskrivna inom eller utanför ), möjliggöra en baskarta. Baskartan ska utgöra grund för framställning av kommunens olika kartprodukter, t.ex. nybyggnadskarta och grundkarta för detaljplan samt kunna tillgodose förrättningsverksamhetens krav på information från baskartan. Markdetaljstyper beskrivna i specifikationen kan även ingå i andra typer av kommunala produkter såsom t.ex. adresskarta, ledningsdokumentation, projekteringsunderlag, underlag för drift och underhåll av kommunala anordningar (t.ex. parker och gator) samt mer småskaliga kartprodukter eller analysunderlag. Markdetaljers beståndsdelar läses enklast ur avsnitt 5, vilket innehåller både en informationsmodell (grafisk beskrivning i UML, Unified Modelling Language) samt en objekttypskatalog med ingående objekttyper (klasser), deras attribut och relationer till andra objekttyper. Vilka objekttyper och attribut som är obligatoriska eller frivilliga framgår av informationsmodellen. Både en informationsmodell i UML och en objekttypskatalog ökar möjligheterna att fler tänkta användare ska kunna förstå specifikationens informationsmodell. Informationsmodellen kan ses som en avgränsning av de företeelsetyper som ingår i temat. Som ett komplement till denna avgränsning finns i specifikationen även illustrationer av andra närliggande företeelsetyper som identifierats i arbetet med specifikationen. I den mån de närliggande företeelserna omfattas av andra teman inom

4 4 (63) går detta att utläsa. I de fall de närliggande företeelserna inte omfattas av andra teman inom så är de dokumenterade och förslag på informationsansvariga aktörer pekas ut. Geodataspecifikationen skall understödja olika samverkansprocesser för datautbyte kopplade till Markdetaljer. Inom Markdetaljers avgränsning definieras ett flertal olika processer där samverkan kan fördjupas för att tillgodose behovet av en ajourhållen baskarta samt effektivisera ajourhållningsprocesserna. Informationsmodellen är i stor utsträckning baserad på ett flertal befintliga kommunala modeller, vilka används inom samhällsbyggnadsprocessen. Som några exempel kan nämnas Sverigemodellen (Lantmäteriet, ESRI), SGD (Södertörns Geodata = Tyresö kommun, Botkyrka kommun, Huddinge kommun, Södertälje kommun, Nynäshamns kommun, Salems kommun, Haninge kommun samt Nykvarns kommun), Topobase/Geodatapaketet (Cad-Q och Topobase användarförening), Baggis (Stockholms stads Stadsbyggnadskontor) m.fl. Som underlag och inspiration för framtagning av modellen har även kommungml, Geomatrisen, GSD fastighetskartan, HMK, NSL (Nationell strandlinje) och RIGES (Regional innovativ GIS- och e-tjänstsamverkan) använts. Se vidare kapitel Förkortningar samt kapitel 13 Referenser. Krav på Markdetaljer uttrycks i respektive tillämpligt avsnitt av specifikationen. Krav skrivs på egen rad med fet stil i röd färg undantaget datakvalitetskrav. Rekommendationer skrivs på egen rad med fet stil i blå färg. Datakvalitetskrav uttrycks i tabellform enligt den internationella datakvalitetsstandarden SS-EN ISO 19157:2013, Geografisk information Datakvalitet under avsnitt 7 i geodataspecifikationen. Denna geodataspecifikation är tillgänglig som ett dokument (.pdf) från

5 5 (63) INNEHÅLLSFÖRTECKNING 1 GEODATASPECIFIKATIONENS OMFATTNING 7 2 ÖVERSIKT Information om geodataspecifikationen Termer och beskrivningar Förkortningar Information om Markdetaljer 12 3 MARKDETALJERS OMFATTNINGAR Omfattning A - Markdetaljer 14 4 IDENTIFIERING AV MARKDETALJER 14 5 DATAINNEHÅLL OCH STRUKTUR Beskrivande text Informationsmodell och objekttypskatalog Okända värden Rumsliga referenssystem Beroenden till andra specifikationer Gemensamma objekttyper SG_BasKlass Geometrityper Höjd och 3D SG_Datamängd Markdetaljer datamängd Objekttyper Markdetalj Objekttyper Kodlistor 35 6 REFERENSSYSTEM 35 7 KVALITETSKRAV Datakvalitet 38 8 METADATA 39 9 TILLHANDAHÅLLANDE 39

6 6 (63) 9.1 Leveransmedium Leveransmedium WFS Leveransmedium WMS Leveransformat Leveransformat GML Leveransformat Bild (för WMS) DATAFÅNGST OCH AJOURHÅLLNING Datafångstkrav Underhåll av data omfattning A (Markdetaljer) PRESENTATIONSREGLER REFERENSER BILAGOR Bilaga A. Test av specifikationsuppfyllelse Bilaga B. Beskrivning av UML för informationsmodeller Bilaga C. Fullständig informationsmodell Bilaga D. Kodlista Markdetaljer Bilaga E. Krav och rekommendationer Krav Rekommendationer Bilaga F. Relationer till specifikationer eller datamängder som ej omfattas av Bilaga G. Mappning av kodlista mot INSPIRE 63

7 7 (63) 1 Geodataspecifikationens omfattning Detta dokument utgör en gemensam geodataspecifikation för Markdetaljer, vilken framställs på uppdrag av Lantmäteriet, kommunerna och andra myndigheter. Specifikationen omfattar grundläggande geografiska data som tillsammans med andra data (beskrivna inom eller utanför ) ska kunna utgöra underlag för en baskarta. Omfattningen avser alla Sveriges kommuner. Inga delomfattningar av Markdetaljer har identifierats då det inte finns några naturliga avgränsningar för innehållet i tema Markdetaljer (t.ex. geografisk indelning, objektvis indelning, indelning utifrån kvalitet och noggrannhet eller insamlingsmetod). 2 Översikt Geodataspecifikationen Markdetaljer omfattar grundläggande geografiska data som, tillsammans med andra geodataspecifikationer, ska möjliggöra en baskarta. Baskartan ska utgöra grund för framställning av kommunens olika kartprodukter, t.ex. nybyggnadskarta och grundkarta för detaljplanering samt kunna tillgodose förrättningsverksamhetens krav på information från baskartan. Markdetaljstyper beskrivna i markdetaljer kan även ingå i andra kommunala produkter såsom adresskarta, ledningsdokumentation, projekteringsunderlag, underlag för drift och underhåll av kommunala anordningar (t.ex. parker och gator) samt mer småskaliga kartprodukter eller analysunderlag. Vissa objekt ingår även i olika myndigheters kartsammanställningar, t.ex. produkter från Lantmäteriet och Sjöfartsverket. 2.1 Information om geodataspecifikationen Titel Datum Ansvarig part Lantmäteriet i samverkan med kommuner och SKL Lantmäteriet, Division Geodata, enheten Geografisk information Adress Gävle Telefon E-post URL specifikationer@lm.se Språk Svenska Ämnesområde 010 Arealtäckande bilder och baskartor Ämnesområde ur den Nationella metadataprofilen, tabell 33.

8 8 (63) Syfte Specifikation av de nationella krav som ställs på kommunens, Lantmäteriets samt andra aktörers grundläggande geografiska data för framtagning av kartprodukter kopplade till samhällsbyggnadsprocessen samt för att möjliggöra ett effektivt datautbyte kopplat till Markdetaljer. Med utbyte av Markdetaljer avses utbyte av geometrier med klassning enligt denna specifikations kodlista. Genom enkelt tillgängliga och väl beskrivna data ökar möjligheterna att effektivisera beslutsprocessen samt minimera riskerna att felaktiga beslut fattas i brist på underlag eller på grund av att underlaget feltolkas. Denna specifikation riktar sig i första hand till dataproducenter, systemleverantörer och systemutvecklare som ansvarar för att möjliggöra utbyte av datamängder enligt denna specifiaktion. Specifikationen 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 beskrivningar Termerna är uppdelade i två tabeller, Tabell 1 beskriver termer från denna specifikation, Tabell 1 innehåller generella termer som används i flera specifikationer. Källa om annan än anges inom parentes efter beskrivning. UML-specifika termer och vissa modelleringstekniska termer beskrivs i 13.2, Bilaga B Beskrivning av UML för informationsmodeller. Tabell 1. Termer för geodataspecifikation Markdetaljer Termer ur Markdetaljer Exploateringsområde Beskrivning (och eventuella anmärkningar) Område avsett för någon form av exploatering och där baskarta uppdateras i samband med t.ex. framtagning av grundkarta för detaljplan Tabell 2. Generella termer i Generella termer Term Abstrakt objekttyp Abstraktion Beskrivning (och eventuella kommentarer) Objekttyp som inte själv kan ha några instanser Kommentar: Används ofta för att modelltekniskt undvika redundans av attributtyper genom att låta en abstrakt klass bära alla gemensamma attributtyper och associationer och därefter låta andra objekttyper ärva dem. Teoretisk konstruktion/tankeskapelse

9 9 (63) Avser vanligtvis representerande av en Företeelsetyp som en Objekttyp eller en Egenskap som en Attributtyp Applikationsschema Association Attribut Attributtyp Baskarta Baskarteområde Begreppsmodell Coverage Datamodell Datatyp formell beskrivning av datastruktur, regler och innehåll för information inom ett visst tillämpningsområde Källa: SIS/STANLI (TK 323) Samverkande GIS med ISO En handbok om tekniskt ramverk för geografisk information, utg 1, 2004 Samband mellan objekttyper Instans av Attributtyp Kommentar: Ett värde som representerar det observerade värdet av en Egenskap hos en Företeelse Egenskap hos Objekt Kommentar: Representerar en eller flera Egenskaper hos en Företeelsetyp Kommentar: Det rekommenderas att en attributtyp endast motsvarar en Egenskap för att undvika att man använder attributtypen felaktigt, att problem uppstår i relation till andra modeller (vid mappning etc.) samt svårigheter att definiera användbara värdelistor. Ett vanligt förekommande fall då en attributtyp representerar flera egenskaper är olika typer av klassificeringar. Exempel: Maxhöjd vid insamlingstillfälle Digitala data (storskaliga) som redovisar grundläggande förhållanden ovan mark, som är av gemensamt intresse för samhällsbyggandet och som ajourhålls kontinuerligt. Område som ajourhålls med storskalig kartinformation, t.ex. inom tätortsområde eller inom område där kartunderlag för grundkarta, nybyggnadskarta eller förrättningskarta tas fram. Vanligtvis grafisk beskrivning av uppträdande hos en avgränsad del av verkligheten utifrån ett visst syfte Termen coverage i samband med geografisk information har ingen allmänt spridd svensk översättning. I ISO definieras coverage på följande sätt: Feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain. Exempel som anges är rasterbild, polygon-lager, digital höjdmatris. Det pågår arbete inom SIS att ta fram en svensk term och definition. Begreppet blir tillgängligt i termdatabasen Ekvator när det är färdigt. Regler för hur data ska struktureras och innehålla vid till exempel lagring eller utbyte Format i vilket attribut anges

10 10 (63) Kommentar: Olika datatyper har olika egenskaper och kan användas i olika typer av operationer Ej samma sak som stereotypen <<DataType>> i grafiska modelleringsnotationer Exempel: Textsträng Heltal Decimaltal Sanningstyp (Ja/Nej) Egenskap Företeelse Företeelsetyp Geodataspecifikation Informationsmodell Kvalitetsmått (engelska, quality measure) Kvalitetsparameter (engelska, quality element) Kvalitetstema (engelska, data quality element category) 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 Exempel: Barr/Löv Art Höjd Solitärt träd Ett i verkligheten förekommande fenomen Kommentar: Kan vara ett ting eller en process. Kan vara ett naturligt eller konstgjort fenomen. Är en instans av en Företeelsetyp Exempel: Trädet utanför huset Grupp av Företeelser med samma egenskaper Exempel: Träd Ett dokument som beskriver alla krav som ställs på datamängder enligt geodataspecifikationen. Krav avser struktur på data vid utbyte, obligatoriska element, hur data ska produceras och tillhandahållas samt datakvalitetskrav. En systemoberoende modell som beskriver, strukturerar och definierar den information som ska hanteras och vilka verksamhetsregler som ska gälla. Struktur för informationsinnehåll beskriven som objekttyper, relationstyper och attributtyper. Föregås oftast av en begreppsmodell, för aktuellt verksamhets- och tillämpningsområde. Kvantitativ bestämning som ligger till grund för utvärderingen av en kvalitetsparameter Källa: HMK Ordlista Detaljerad indelning av geodatakvalitetens olika aspekter; grupperas ihop till kvalitetsteman och mäts med kvalitetsmått Källa: HMK Ordlista Övergripande indelning av geodatakvalitetens olika aspekter (aktualitet, fullständighet, användbarhet etc.); delas in i kvalitetsparameterar, som mäts med kvalitetsmått

11 11 (63) Källa: HMK Ordlista Kodlista Metadata Modellelement Objekt Objekttyp Objekttypskatalog Uppräknade värden som en attributtyp kan anta Kommentar: Implementeras oftast i konceptuella modeller som <<codelist>> (utökningsbar) eller <<enumeration>> (icke utökningsbar). Synonymer: Värdelista Värdemängd Värdeförråd Data som definierar och beskriver andra data Kommentar: Metadata kan förekomma både på datamängdsnivå och objekttypsnivå. Metadata används också för data som beskriver en tjänst. Komponent som bygger upp en modell. Exempel: Objekttyper och attributtyper. Instans av Objekttyp Kommentar: Representerar en individ i verkligheten Exempel: Ek id: 21 (Id är egentligen ett attribut men behövs för att identifiera just den ek vi avser) abstraktion av Företeelsetyp Kommentar: Representation i datamängd (faktisk eller konceptuell) av en eller flera Företeelsetyper Grupp av Objekt med samma egenskaper Innehåller delmängd av Företeelsers egenskaper utvalda utifrån vad som är möjligt att beskrivas och som utifrån användningsfall identifierats vara betydelsefulla för syftet med abstraktionen. Exempel: Lövträd Vedartade växter En sammanställning av en informationsmodell i tabellform Förkortningar Tabell 3. Förkortningar DGNSS DPS EPSG Differentiell GNSS. Relativ GNSS-mätning där korrektioner för systematiska felkällor beräknas på referensstation och sänds till mobila GNSSmottagare, som korrigerar sina mätningar. Dataproduktspecifikation European Petroleum Survey Group

12 12 (63) GALILEO GLONASS GML GNSS GPS HMK Nätverks-RTK OGC System för satellitnavigering som utvecklas på uppdrag av EU och Europeiska rymdorganisationen (ESA). Globalnaja navigatsionnaja sputnikovaja sistema Geographic Markup Language En profil av XML med fördefinierad hantering av geometrier och referenssystem med mera. Global Navigation Satellite System. Samlingsbegrepp för GPS, GLONASS och GALILEO. Global Positioning System Handbok i mät- och kartfrågor. Samverkan mellan Lantmäteriet och andra myndigheter, främst kommuner och Trafikverket, som arbetar för enhetlig och standardiserad insamling av geodata i form av handböcker. Se HMK:s hemsida 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 RH 2000 Rikets Höjdsystem 2000 RTK SWEREF 99 SWEREF 99 TM SWEREF 99 dd mm UUID XML Real Time Kinematic. Bärvågsmätning i realtid. Swedish Reference Frame Svenskt tredimensionellt referenssystem Swedish Reference Frame 1999 Transversal Mercator. Rikstäckande kartprojektion i svenskt tredimensionellt referenssystem Swedish Reference Frame Svenskt tredimensionellt referenssystem, lokala projektionszoner Universal Unique IDentifier extensible Markup Language Ett textbaserat överföringsformat för data där man själv definierar struktur och regler för data med hjälp av ett XML-schema (.xsd). I huvudsak avsett för att vara maskinläsbart men kan även läsas av människor. 2.2 Information om Markdetaljer Namn Markdetaljer

13 13 (63) Förkortning - Beskrivning av innehåll Utsträckning i tid och rum Syfte Markdetaljer innehåller de markdetaljstyper som utgör grundläggande geografiska data och som har identifierats ingå i en baskarta. Dessa utgör underlag vid framtagning av kartprodukter och kartunderlag kopplade till samhällsbyggnadsprocessen, t.ex. detaljplanering, bygglovshantering och fastighetsbildning. Vissa markdetaljstyper ingår även i olika myndigheters kartsammanställningar, t.ex. produkter från Lantmäteriet och Sjöfartsverket. Markdetaljstyperna används för att beskriva fysiska företeelser som förekommer ovan mark, naturligt eller är anlagda. Exempel på markdetaljer är stödmur, mast och brygga. Hela Sverige Markdetaljer är väl beskrivna och rymmer data om fysiska företeelser ovan mark, som förekommer naturligt eller är anlagda. Markdetaljer behövs som underlag vid detaljplanering, fastighetsbildning och bygglovshantering eller i andra kartunderlag kopplade till samhällsbyggnadsprocessen. Markdetaljer kan också bidra till att annan myndighetsutövning underlättas. Datakällor Kommunala databaser, Lantmäteriets och Sjöfartsverkets databaser eller andra aktörers databaser. Data enligt ska, tillsammans med andra data (beskrivna inom eller utanför ), möjliggöra en baskarta. Baskartan ska kunna användas för att generera grundkarta för detaljplanering, nybyggnadskarta, förrättningskarta eller andra storskaliga eller småskaliga underlag eller produkter inom samhällsbyggnadsprocessen. Vissa markdetaljstyper ingår även i olika myndigheters kartsammanställningar, t.ex. produkter från Lantmäteriet och Sjöfartsverket. Syftet med är även att specificera de nationella krav som ställs på utbyte av Markdetaljer mellan kommuner och infrastrukturbyggare samt kommuner och Lantmäteriet. Utbyte kan avse både från producent till datalager eller från datalager till användare. Produktionsprocesser Dataproduktion hos kommunerna (insamling och ajourhållning) utförs med fotogrammetriska metoder med flygbilder som underlag (t.ex. stereokartering) eller geodetisk mätning. Dataproduktion utförs ofta i samband med framtagning av produkter kopplade till samhällsbyggnadspro-

14 14 (63) cessen. Kontinuerlig ajourhållning utförs ofta inom utpekade exploateringsområden eller i omdrev. Inom förrättningsprocessen utförs inmätning av markdetaljer som har betydelse för förrättningsärendet. Detta utförs av både kommunala- och statliga lantmäterimyndigheter. Även hos Lantmäteriet och Sjöfartsverket sker dataproduktion av vissa markdetaljer, främst de som ingår i NSL (Nationell StrandLinje). Ajourhållning Varje kommun har individuella rutiner för ajourhållning av Markdetaljer. Lantmäteriet ajourhåller i samband med lantmäteriförrättning. Lantmäteriet ajourhåller även NSLobjekt vid årlig omdrevsfotografering. 3 Markdetaljers omfattningar Endast omfattningen Hela Markdetaljer har identifierats. 3.1 Omfattning A - Markdetaljer Identifiering av omfattning Hierarkisk nivå Markdetaljer 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Markdetaljer Datamängd beskrivande markdetaljer. Utsträckning Data förekommer över hela Sverige. Coverages - Ingående omfattningar - 4 Identifiering av Markdetaljer Titel Markdetaljer Alternativ titel Markdetaljer

15 15 (63) Versionsnummer Sammanfattning Markdetaljer omfattar fysiska företeelser, naturliga eller anlagda, vilka har betydelse för samhällsbyggnadsprocessen. Med samhällsbyggnadsprocessen avses översiktlig planering eller detaljplanering, fastighetsbildning och bygglovhantering samt processer kopplade till dessa. Det kan också vara underlag för framtagning av ledningsdokumentation, projekteringsunderlag eller analysunderlag för olika delar i processen. Större delen av dessa processer ägs av kommunerna och är reglerade i PBL (Plan- och bygglagen). Data från Markdetaljer ska, tillsammans med andra data (beskrivna inom eller utanför ), möjliggöra en baskarta. En baskarta ajourhålls kontinuerligt och fungerar som underlag inom flera delar av samhällsbyggnadsprocessen. Vissa markdetaljer ingår även i olika myndigheters kartsammanställningar, t.ex. produkter från Lantmäteriet och Sjöfartsverket. Syfte Markdetaljer är väl beskrivna och rymmer data om fysiska företeelser ovan mark, vilka förekommer naturligt eller är anlagda. Markdetaljer ska, tillsammans med andra data (beskrivna inom eller utanför ), möjliggöra en baskarta. En baskarta behövs som underlag vid detaljplanering, fastighetsbildning och bygglovshantering eller i andra kartunderlag kopplade till samhällsbyggnadsprocessen. Markdetaljer kan också bidra till att annan myndighetsutövning underlättas. Geodataspecifikationen, med kodlistan inkluderad, är även avsedd att främja och effektivisera datautbytet mellan kommunerna och olika statliga myndigheter (Lantmäteriet, Sjöfartsverket m.fl.), datautbytet mellan kommunerna och olika privata aktörer (arkitekter, projektörer, byggare etc.) samt datautbytet kommuner emellan, vid t.ex. mark- och exploateringsprojekt över kommungräns. Ämnesområde 010 Arealtäckande bilder och baskartor. Ämnesområde ur den Nationella metadataprofilen, tabell 33. Typ av geometrisk representation Rumslig upplösning Vektor. Ur den Nationella metadataprofilen. Geografisk utsträckning Markdetaljer förekommer över hela Sverige.

16 16 (63) Kompletterande information - 5 Datainnehåll och struktur 5.1 Beskrivande text Markdetaljer beskrivs av en grafisk informationsmodell, en objekttypskatalog och en hierarkisk kodlista med typer av markdetaljer (13.4). I kapitlet Informationsmodell beskrivs i detalj alla ingående objekttyper, attribut och associationer som ingår i Markdetaljer. Beskrivning sker med hjälp av figurer (UMLdiagram), förklarande text och en objekttypskatalog. Objekttypskatalogen är inte utformad efter ISO Feature catalogue som ISO anger, utan istället skapad med fokus på enkelhet och läsbarhet. Geodataspecifikationens kodlista har som avsikt att vara så heltäckande som möjligt för att motsvara främst kommunala behov av att tillhandahålla grundläggande kartunderlag till de olika processerna. Värden i kodlistan är anpassade för att harmonisera med kommuners olika förutsättningar och strukturer, t.ex. skillnader i behov av olika typer av koder mellan storstads- och landsortskommuner. För att generera en komplett baskarta kombineras data från flera olika geodataspecifikationer inom Svensk geoprocess, t.ex. Väg och Järnväg, Byggnad, Markanvändning och Marktäcke eller Vatten. Även data beskrivna utanför kan behövas för att skapa en komplett baskarta. I kodlistan har en avgränsning gjorts gentemot lokala verksamhetssystem (t.ex. park, ledning, VA, hamn, trafik etc.). I praktiken innebär det att objektet som ingår i kodlistan kan vara mer generellt och inte definierat utifrån någon specifik verksamhet. I 13.7, Bilaga G Mappning av kodlista mot INSPIRE redovisas vilka koder i Markdetaljer som kan mappas mot INSPIRE:s dataspecifikationer. Inom har inga applikationsscheman (enligt ISO 19109) tagits fram utan det sätt som Markdetaljers innehåll är grafisk dokumenterat med är en informationsmodell. Informationsmodellen är dokumenterad med UML ( och är framförallt avsedd att vara läsbar för människor och är därför i vissa avseenden inte konsekvent eller tekniskt korrekt modellerad. Se 13.2 för information om hur UML har använts i. 5.2 Informationsmodell och objekttypskatalog Informationsmodellen är uppdelad i flera figurer för att belysa de olika delarna av modellen. Hela informationsmodellen återfinns i I avgränsandet av Markdetaljer så har företeelser identifierats som Markdetaljstyper har beroenden eller associationer till men som inte omfattas av Markdetaljer. I 13.6 illustreras dessa företeelser samt eventuella aktörer ansvariga för specifikationer som motsvarar dessa företeelser. En del av dessa företeelser omfattas av andra specifikationer som utvecklas inom Svensk geoprocess.

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

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

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

20 20 (63) Beroenden till andra specifikationer pkg ML_MarkDetaljerPaketBeroenden VN_Vatten SG_GemensammaKlasser (from SvenskGeoprocess) (from SvenskGeoprocess) MA_Markanv ändning ML_MarkDetaljer (from SvenskGeoprocess) MT_Marktäcke (from SvenskGeoprocess) (from SvenskGeoprocess) VJ_VägJärnv äg (from SvenskGeoprocess) BY_Byggnad (from SvenskGeoprocess) Figur 2. Paketdiagram visande Markdetaljers beroenden till andra specifikationer. Markdetaljer har beroenden till andra specifikationer. Detta illustreras genom paketberoenden (Figur 2). Markdetaljstyper har identifierats ha relationer till objekttyper som återfinns i andra specifikationer inom. Figur 2 visar därför beroenden mellan Markdetaljer och andra specifikationer inom. Markdetaljer har även beroenden till specifikationer utanför, t.ex. fastigheter, rättigheter, planer, bestämmelser, fornlämningar och ledningsinformation (se 13.6) Gemensamma objekttyper För att skapa enhetlighet bland de specifikationer som tas fram inom har en uppsättning gemensamma objekttyper skapats som kan användas av alla specifikationer. De gemensamma klasserna medför att identifierare, livcykelinformation, geometrier och beskrivning av datamängder och metadata hanteras enhetligt SG_BasKlass SG_BasKlass (Figur 3) är en abstrakt superklass (objekttyp) som äger de mest grundläggande attributen som krävs vid utbyte av geodata. Nästan alla andra objekttyper i

21 21 (63) alla specifikationer inom kan vara specialiseringar av typen SG_BasKlass. Att skapa superklasser på detta sätt är en vanligt förekommande metod för att undvika upprepning i modeller och därmed göra modellerna mer lättlästa. SG_BasKlass har två obligatoriska attribut, id, som är av typen SG_Id och aktualitet. Man kan ange ett eller två id:n. Datatypen SG_Id medger att man kan välja mellan två olika id:n, ett nationellt-id eller ett verksamhets-id. Båda är av datatypen Identifier (Figur 4) som kommer från Inspire och består av en namnrymd (namespace) och ett id (localid) som tillsammans ger ett unikt id vilket förklaras djupare i För nationelltid ska namespace inte peka ut en organisation utan en datamängd enligt en viss specifikation. För verksamhetsid ska namespace peka ut en organisation men kan även peka ut en viss datamängd som förvaltas av organisationen. Se ytterligare om identifierare i Attributet externreferens, av typen SG_ExternReferens ger möjlighet att associera ett objekt enligt en specifikation med ett annat objekt enligt en annan specifikation, exempel: möjlighet att koppla en byggnad till ett ortnamn ur Ortnamnsregistret. Objekt enligt olika specifikationer i kan representera samma verkliga företeelse men ur olika aspekter. Associationen representerarsammaföreteelse ger möjlighet att tala om att ett objekt enligt en specifikation i representerar samma verkliga företeelse som ett annat objekt ur en annan specifikation i. Exempel: En vägs utbredning beskrivs som Markanvändning men inte dess beläggning (asfalt, grus etc.) vilket istället beskrivs som Marktäcke. För att till exempel kunna använda samma geometri som representerar båda objekten kan associationen representerarsammaföreteelse användas. class SG_Basklass +representerarsammaföreteelse 0..* «FeatureType» SG_GemensammaKlasser::SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime «union» SG_GemensammaKlasser:: SG_Id + nationelltid: Identifier + verksamhetsid: Identifier «DataType» SG_GemensammaKlasser:: SG_ExternReferens + id: CharacterString Figur 3. SG_BasKlass

22 22 (63) class Inspire_Id «datatype» Base Types::Identifier + localid :CharacterString + namespace :CharacterString «lifecycleinfo, voidable» + versionid :CharacterString [0..1] Figur 4. Inspires identifierare, Identifier Identifierare Unika identifierare kan uppnås på olika sätt, antingen med UUID som är en universellt unik identifierare bestående av 32 hexadecimala tecken separerade i fyra grupper av bindestreck (-). Ett annat sätt är att med en URI (Unique Resource Identifier) identifiera en datamängd i något som kallas Namespace och därefter identifiera ett objekt i datamängden med en för datamängden unik identifierare. Det senare sättet används av typen Identifier från Inspire med hjälp av attributen namespace och localid. Trots att localid inte måste vara universellt unik så rekommenderar denna geodataspecifiaktion att UUID används. Arbete pågår i Sverige med att ta fram riktlinjer för namespace for geodata. Arbetet leds av Lantmäteriet. Föreslaget är en lösning enligt nedan: identifier}/{localid} Exempel på ett nationellt id skulle då kunna bli: fd5e-90ec-e040-ed8f66333c3f Exempel på ett verksamhets-id skulle då kunna bli: Krav 7. Alla objekt i en datamängd enligt denna geodataspecifikation ska ha en identifierare (Id) (Se kapitel 7.1, Nr. 3). Krav 8. Då endast en identifierare anges skall den vara av typen nationellid.

23 23 (63) Krav 9. Då två identifierare anges skall de vara ett av varje typ, nationelltid och verksamhetsid. Krav 10 nationelltid:s namespace ska identifiera en datamängd. Krav 11. verksamhetsid:s namespace ska identifiera en organisation. Krav 12 Identifierare ska vara av typen Identifier (Inspire - Generic conceptual model - BaseTypes) (Se kapitel 7.1, Nr. 3). Krav 13. Identifieraren ska vara unik och stabil över objektets livstid. Rekommendation 2 LocalId som är ett attribut till typen Identifier ska vara av typen UUID (ISO/IEC :2005) Livscykelinformation Inspire har skapat attributen beginlifespanversion och endlifespanversion som tillsammans med ett versionsnummer, valfritt attribut på identifieraren Identifier, på ett objekt kan användas vid versionshantering och åtkomst till äldre versioner av objektet. Krav 14 Då attributet endlifespanversion förekommer får dess värde inte inträffa före värdet attributet beginlifespanversion. Rekommendation 3. Attributet beginlifespanversion ska finnas för samtliga objekt i datamängd enligt denna geodataspecifikation. Rekommendation 4. Datum, för när objekt skapades i databas hos ansvarig part, ska användas för attributet beginlifespanversion och alla objekt i en datamängd enligt denna geodataspecifikation Objekttyper SG_BasKlass Sammanhållande abstrakt klass för attribut som är grundläggande vid utbyte av geodata och som kan användas som superklass för en modells samtliga objekttyper Attribut Beskrivning Multiplicitet Datatyp id Identifierare [1..2] SG_Id beginlifespanversion endlifespanversion Datum då objekt först skapades i datamängd. Datum från när objekt inte längre ingår i datamängd. [0..1] DateTime [0..1] DateTime

24 24 (63) externreferens aktualitet Referens till annan objekttyp i eller utanför. Datum då objektet senast befanns vara korrekt. [0..*] SG_ExternReferens [1] DateTime Datatyper SG_Id Identifierare Attribut Beskrivning Multiplicitet Datatyp nationelltid verksamhetsid Nationell identiferare Kommentar: namespace pekar ut specifikation, ej ansvarig organisation Lokal identifierare skapad utifrån specifika verksamheters behov Kommentar: namespace pekar ut ansvarig organisation, ej specifikation. [1..1] Identifier [1..1] Identifier SG_ExternReferens Referens till annan objekttyp i eller utanför. Attribut Beskrivning Multiplicitet Datatyp id Identifierare för extern objekttyp som refereras till. [1] CharachterString Geometrityper För specifikationer har en grunduppsättning geometrityper tagits fram, Figur 5. De är i huvudsak specialiseringar av geometrityper från SS-ISO 19107:2003 Modell för att beskriva rumsliga aspekter.

25 25 (63) class SG_Geometri «FeatureType» SG_GemensammaKlasserInformation:: SG_Geometri + geometriid: SG_Id [1..2] + lägesosäkerhetplan: SG_LägesOsäkerhet [0..1] + lägesosäkerhethöjd: SG_LägesOsäkerhet [0..1] + geometrikälla: RelatedParty + geometrimetadata: SG_GeometriMetadata [0..1] «FeatureType» SG_GemensammaKlasserInformation: :SG_Punkt + punkt: GM_Point + ärcentroid: Boolean [0..1] «FeatureType» SG_GemensammaKlasserInformation: :SG_Yta + yta: GM_MultiSurface «FeatureType» SG_GemensammaKlasserInformation: :SG_Kropp + kropp: GM_Solid «FeatureType» SG_GemensammaKlasserInformation::SG_Linje + linje: GM_MultiCurve + typavlinje: SG_TypAvLinje + /kartografiskrepresentation: SG_KartografiskRepresentationLinjeTyp [0..*] + kantlinjeegenskap: SG_KantlinjeEgenskapTyp [0..1] «codelist» SG_GemensammaKlasserKodlistor: :SG_TypAv Linje + Kantlinje + Mittlinje + AnnanLinje «codelist» SG_GemensammaKlasserKodlistor:: SG_KartografiskRepresentationLinjeTyp «codelist» SG_GemensammaKlasserKodlistor: :SG_KantlinjeEgenskapTyp + Kantsten + Släntfot + Släntkrön Figur 5. geometrityper Grundtanken i är att en företeelses abstraktion inte är knuten till hur den representeras geometriskt. Detta ger möjlighet att representera en företeelse med flera geometrier. Ett dike kan ha både två kantlinjer, en mittlinje och en yta. I många fall så skapas abstraktioner av företeelser utifrån hur man tänker sig att de ska representeras geometriskt och geometrin blir en del av typen, till exempel Dikeskant. I så ligger inte möjligheten att tala om detta på typen, ett dike är ett dike, inte en linje. Om det är en kantlinje, en mittlinje eller en yta ges istället av geometrin. Krav 15. Geometri ska finnas för samtliga objekt i datamängd enligt denna geodataspecifikation (Se kapitel 7, Nr. 3). Alla geometrier (SG_Geometri) i har flera egenskaper men det är endast attributen geometriid och geometrikälla som är obligatoriska. Det finns möjlighet att beskriva lägesosäkerheten för en enskild geometri i både plan och höjd (Figur 6) samt vilken metod som har använts för att fastställa lägesosäkerheten.

26 26 (63) class SG_Lägesosäkerhet «DataType» SG_GemensammaKlasserDatatyper:: SG_LägesOsäkerhet + mätmetod: CharacterString [0..1] + lägesosäkerhet: DQ_PositionalAccuracy + tidpunktmätning: DateTime [0..1] Figur 6. Lägesosäkerhet för geometrier. GeometriId anges på samma sätt som för SG_BasKlass ( ). GeometriKälla anges med Inspire-klassen RelatedParty (Figur 7). class RelatedParty «datatype» Base Types 2::RelatedParty «voidable» + individualname :PT_FreeText [0..1] + organisationname :PT_FreeText [0..1] + positionname :PT_FreeText [0..1] + contact :Contact [0..1] + role :PartyRoleValue [0..*] «datatype» Base Types 2::Contact «voidable» + address :AddressRepresentation [0..1] + contactinstructions :PT_FreeText [0..1] + electronicmailaddress :CharacterString [0..1] + hoursofservice :PT_FreeText [0..1] + telephonefacsimile :CharacterString [0..*] + telephonevoice :CharacterString [0..*] + website :URL [0..1] Figur 7. RelatedParty I många kommunala verksamheter används inte ytor (polygoner) för att representera företeelser med ytutbredning i verkligheten utan istället används linjer, till exempel begränsningslinje eller kantlinje. För att kunna tala om vad en linje representerar gällande en verklig företeelse så är attributet typavlinje obligatoriskt för alla linjer. En linje kan vara: Kantlinje, en linje som används för att beskriva ytterkant på en företeelse. Till exempel kan ett dike representeras av två kantlinjer. Mittlinje, en linje som representerar en utsträckt företeelses mitt. Till exempel så kan ett dike i tillägg till två kantlinjer även ha en mittlinje. Annan linje, alla övriga typer av linjer. Till exempel kan man låta en linje representera ett mindre vattendrag i en småskalig presentation oavsett om den avser vattendragets mitt eller kant. Då man inte hanterar ytor utan linjer som geometrisk representation för ytutbredda företeelser i verkligheten så förekommer de ofta tillsammans med en centroid

27 27 (63) (SG_Punkt med attributet ärcentroid=true) och topologier för att avgränsa en företeelses utbredning. Centroiden tillsammans med linjer kan användas för at konstruera en yta vid behov. En linje kan behöva presenteras i till exempel en karta. För en del linjer kan detta behöva ske utan att ytan som den delvis avgränsar ritas ut. Hur linjen ska presenteras (portrayal/manér) beror på vilka typer av företeelser den avgränsar. Attributet kartografiskrepresentation på objekttypen SG_Linje ger möjlighet att beskriva hur en linje är tänkt att representeras kartografiskt med kodlistan SG_KartografiskRepresentation- LinjeTyp utifrån omgivande typer av företeelser. Ska till exempel en kantlinje mellan en åker och en väg presenteras som åkerkant eller vägkant. SG_KartografiskRepresentationLinjeTyp kommer att implementeras olika för olika specifikationer utifrån de behov som respektive specifikation representerar. Andra egenskaper som förekommer på kantlinjer är till exempel förekomst av kantsten. Denna och liknande egenskaper kan tillskrivas linjen med hjälp av attributet kantlinjeegenskap som använder kodlistan SG_KantlinjeEgenskapTyp. class SG_GeometriMetadata «DataType» SG_GemensammaKlasserDatatyper::SG_GeometriMetadata + geometrinamn: CharacterString [0..1] + geometrisyfte: CharacterString [0..1] + inmätningsläge: SG_InmätningsLäge [0..1] = Enligt SGP mätn... + tänktupplösningpresentation: MD_Resolution [0..1] + aktualitet: DateTime [0..1] + insamlingsdatum: DateTime [0..1] + beginlifespanversion: DateTime [0..1] + osäkertläge: Boolean [0..1] = false + osäkertlägeanledning: CharacterString [0..1] + endlifespanversion: DateTime [0..1] «codelist» SG_GemensammaKlasserKodlistor:: SG_InmätningsLäge + Enligt SGP mätningsanvisningar + Egna mätningsanvisningar + Marknivå + Överkant + Mätningsanvisningar saknas Figur 8. Geometrimetadata I Figur 8 så beskrivs ytterligare egenskaper till SG_Geometri. Det största skälet till att SG_GeometriMetadata finns är att kunna använda SG_Geometri i så många sammanhang där de frivilliga egenskaperna som beskrivs i SG_GeometriMetadata ej behövs och därmed inte verkar skrämmande för läsare av aktuell modell eller specifikation.

28 28 (63) En geometri kan ha ett namn, geometrinamn, om behovet finns. GeometriSyfte anges i nuläget med fritext och kan vara till exempel: modellunderlag, representation för objekt i detaljplan etc. Attributet inmätningsläge gör att man kan tala om hur en företeelse är inmätt och representerad geometriskt. Standardalternativet för inmätnings- Läge är enligt mätningsanvisningar men för att inte exkludera utbyte av gamla geodata som mätts in enligt okända regler finns möjlighet att ange flera alternativ. Detta gör det också möjligt att belysa om mätningsanvisningar saknas. Attributet tänktupplösningpresentation talar om vilken skala en geometri är tänkt att presenteras i, används främst om detta är viktigt för förståelsen och användandet av geometrin. Det finns också möjlighet att beskriva aktualitet för enskilda geometrier, aktualiteten beskrivs som det datum då geometrin senast befanns vara korrekt. Det finns flera attribut som beskriver de olika tillfällen som ligger bakom skapandet av en geometri och som kan vara bra att känna till vid användning av geometrier. Insamlingsdatum avser det datum då en flygbild tagits (eller en geodetisk fältmätning utförts etc.) och som sedan legat till grund för skapande av en geometri. BeginLifeSpanversion avser det datum då själva geometrin tolkats/skapats och lagrats i en databas. På liknande sätt anger endlifespanversion när en geometri ersatts av en nyare geometri databas eller beslutats inte längre vara aktuell eller användbar. I vissa fall kan en företeelse vara skymd, helt eller delvis, i en flygbild eller ett ortofoto och den som skapar geometrin gör en uppskattning av geometrin utifrån erfarenhet, regler och/eller andra indikatorer i bilden. När så inträffar skall attributet osäkert läge (skymd geometri) sättas till True (standardvärde för attributet är False ) och attributet osäkertlägeanledning skall anges Objekttyper SG_Geometri Geometrityper och kvalitetsmärkning av ett objekts geometri - framtagna för ändamål. Attribut Beskrivning Multiplicitet Datatyp geometriid Identifierare för geometri [1..2] SG_Id LägesOsäkerhetPlan LägesOsäkerhetHöjd geometrikälla Mätmetod och standardosäkerhet för geometris läge i plan Mätmetod och standardosäkerhet för geometris läge i höjd Organisation ansvarig för geometri [0..1] SG_LägesOsäkerhet [0..1] SG_LägesOsäkerhet [1..1] RelatedParty geometrimetadata Metadata för geometri [0..1] SG_GeometriMetadata SG_Punkt Endimensionell geometri som beskriver en punkt Attribut Beskrivning Multiplicitet Datatyp punkt Geometri [1..1] GM_Point ärcentroid Talar om huruvida punkten används som centroid hållande identifierare för ytutbrett objekt och som tillsam- [0..1] Boolean

29 29 (63) mans med linjer kan användas vid skapande av ytgeometri. SG_Linje Linjegeometri Attribut Beskrivning Multiplicitet Datatyp linje Geometri [1..1] GM_MultiCurve typavlinje kartografiskrepresentation kantlinjeegenskap Kategorisering av linjegeometri utifrån användningssyfte Beskrivning av hur en linje är tänkt att representeras kartografiskt. Anger om kantlinjen har speciella egenskaper [1..1] SG_TypAvLinje [0..1] SG_KartografiskRepresentationLinjeTyp [0..1] SG_KantlinjeEgenskap- Typ SG_Yta Tvådimensionell ytgeometri Attribut Beskrivning Multiplicitet Datatyp yta Geometri [1..1] GM_MultiSurface SG_Kropp Tredimensionell geometri som avgränsas av gränsytor Attribut Beskrivning Multiplicitet Datatyp kropp Geometri [1..1] GM_Solid Datatyper SG_GeometriMetadata Geometrityper och kvalitetsmärkning av ett objekts geometri - framtagna för ändamål. Attribut Beskrivning Multiplicitet Datatyp geometrinamn Namn på geometri [0..1] CharacterString geometrisyfte inmätningsläge tänktupplösningpresentation aktualitet insamlingsdatum Syfte för vilket geometri skapats Beskrivning av hur en geometri är inmätt Tänkt skala/upplösning för presentation av geometri Datum då geometrin senast befanns vara korrekt Datum då data samlats in Kommentar: Avser vanligen det datum då flygbild tagits eller geodetisk fältmätning utförts [0..1] CharacterString [0..1] SG_InmätningsLäge [0..1] MD_Resolution [0..1] DateTime [0..1] DateTime beginlifespanversion Datum då objekt skapades i datamängd Kommentar: Avser vanligen det datum då ett objekt lagras i en databas men kan också [0..1] DateTime

30 30 (63) osäkertläge osäkertlägeanledning endlifespanversion avse det datum då mätning i bild eller tolkning av fältdata görs Markering om att direkt mätning av geometri inte kunnat ske Kommentar: Kallas även skymd geometri, False = ej osäkert läge är standardval Anledning till att en geometri betraktats som skymd/osäkert läge. Datum då objekt ersatts av annat objekt i datamängd eller beslutats inte längre vara aktuell eller användbar. Kommentar: Objekt ersatta med nyare objekt/versioner är vanligtvis inte tillgängliga via normala sökningar/frågor mot datamängd. [1..1] Boolean [0..1] CharacterString [0..1] DateTime SG_LägesOsäkerhet Beskrivning av mätmetod och standardosäkerhet för lägesbestämning av en geometri. Attribut Beskrivning Multiplicitet Datatyp lägesosäkerhet mätmetod tidpunktmätning Geometrins standardosäkerhet Metod för fastställning av geometrins läge. Tidpunkt för mätning. Kommentar: Används då olika metoder används för mätning i plan och höjd, annars används bara insamlingsdatum på SG_GeometriMetadata [1..1] DQ_PositionalAccuracy [1..1] CharacterString [0..1] DateTime Kodlistor SG_typAvLinje Värden Kantlinje Mittlinje AnnanLinje Kategorisering av linjegeometri utifrån användningssyfte. Beskrivning Linje som representerar del av en företeelses yttre begränsning Linje som representerar en företeelses mitt Generell typ av linje som representerar en företeelse och som används då linjen ej representerar en företeelses kant eller mitt SG_KartografiskRepresentationLinjeTyp Beskrivning av hur en linje är tänkt att representeras kartografiskt. Kommentar: Kodlistan kommer att variera i olika specifikationer och hur den ska implementeras beskrivs av respektive specifikation.

31 31 (63) SG_KantlinjeEgenskap- Typ Värden Kantsten Släntfot Släntkrön Egenskaper som en kantlinje kan ha Beskrivning SG_InmätningsLäge Värden Enligt SGP mätningsanvisning Beskrivning av hur en geometri är inmätt Kommentar: Startvärde ("default") är Enligt SGP mätningsanvisning. Beskrivning Företeelsen som geometri representerar är inmätt enligt mätningsanvisningar. Egna mätningsanvisningar Företeelse som geometri representerar är inmätt enligt egna mätningsanvisningar. Kommentar: Vem "egen" avser ges av attributet geometrikälla på SG_Geometri. Marknivå Överkant Mätningsanvisningar saknas Företeelsen som geometri representerar är inmätt i marknivå. Företeelsen som geometri representerar är inmätt i överkant. Mätningsanvisningar saknas Höjd och 3D Efterfrågan på att veta höjd på företeelser i olika sammanhang ökar ständigt, till exempel 3D-modeller, översvämningsbedömning med mera. Höjd mäts idag inom olika verksamheter och på olika sätt, allt ifrån enstaka objekt till flygburen laserskanning över stora områden. Höjddata har traditionellt sett ofta hanterats som antingen ett ytterligare attribut på ett objekt eller som en höjdvärde på en geometri. I denna specifikation ges utrymme för att uttrycka höjd på flera sätt utifrån behov: Höjd som ett attribut (2D). En objekttyp kan ha ett attribut för att beskriva höjd, detta speglar oftast endast en aspekt av ett objekts höjd. Till exempel höjden på ett berg. Höjd som attribut följer de krav på referenssystem som anges i denna specifikation. Höjdvärden på geometri. o o Höjd kan anges som ett höjdvärde på en punkt och på brytpunkter ingående i en linje eller en yta (2,5D). Höjd kan representeras av en tredimensionell geometri, s k kropp (3D). I de fall mer yttäckande höjddatainsamling görs rekommenderas att resultatet uttrycks som en höjdmodell enligt geodataspecifikationen Höjd. För mer information om punkthöjder som referenshöjder se geodataspecifikationerna Höjd och Stompunkter. Det rekommenderas att inmätning av företeelser görs på deras högsta punkt då läget på marken oftast kan fås av en höjdmodell. Detta förfarande medför att man i större utsträckning kan använda geometrin i frågeställningar som kräver 3D-representation av företeelser.

32 32 (63) Rekommendation 5. Företeelsers höjd ska mätas in på dess högsta punkt SG_Datamängd För att visa hur datamängder sätts ihop av objekttyper i teman inom samt att för att visa hur metadata förhåller sig till en datamängd har en gemensam objekttyp för datamängd, SG_Datamängd, skapats (Figur 9) class SG_Datamängd «DataSet» SG_GemensammaKlasser:: SG_Datamängd + aktualitet :DateTime + sekretessreglerad :Boolean = false +metadata Metadata entity set information::md_metadata Figur 9. SG_Datamängd. SG_Datamängd bär också en utökning av obligatorisk metadata på datamängdsnivå i form av aktualitet samt information om datamängden är sekretessreglerad eller inte. SG_Datamängd håller samman datamängder av vektortyp och ingår därför inte i alla informationsmodeller för bild och höjd, med undantag av punktmoln, höjdpunkter, punkthöjder, brytlinjer och nivåkurvor.

33 33 (63) Markdetaljer datamängd class ML_MarkDetaljerDatamängd «DataSet» SG_GemensammaKlasserInformation:: SG_Datamängd + aktualitet: DateTime [0..1] + sekretessreglerad: Boolean [0..1] = false +metadata Metadata entity set information::md_metadata «DataSet» ML_MarkdetaljDatamängd 1..* «FeatureType» ML_Markdetalj SG_BasKlass + namnmarkdetaljobjekt: CharacterString [0..1] + markdetaljtyp: ML_MarkdetaljTyp + geometri: SG_Geometri [1..*] Figur 10. Datamängd för Markdetaljer. Figur 10 visar hur datamängder med Markdetaljer är sammansatt enligt denna specifikation. Metadata ska anges på datamängdsnivå för Markdetaljer. Figur 10 visar hur metadata associeras till en datamängd som följer denna specifikation. Metadata används för att identifiera en datamängd enligt denna specifikation samt beskriver hur datamängden är beskaffad och om den uppfyller denna specifikation. För utförligare information om metadata se Objekttyper ML_MarkdetaljDatamängd Visar hur Markdetaljer sätts samman och hur metadata kopplas till Markdetaljdatamängder.

34 34 (63) Markdetalj class ML_MarkDetalj er «FeatureType» SG_GemensammaKlasserInformation:: SG_BasKlass +representerarsammaföreteelse 0..* + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime «FeatureType» ML_Markdetalj + namnmarkdetaljobjekt: CharacterString [0..1] + markdetaljtyp: ML_MarkdetaljTyp + geometri: SG_Geometri [1..*] + höjd: Real [0..1] «codelist» ML_MarkDetaljerKodlistor:: ML_MarkdetaljTyp Figur 11. Markdetalj Markdetaljer avser förekomster av fysiska företeelser ovan mark. Exempel på markdetaljer är stödmur, mast och brygga. Objekttypen ML_Markdetalj är en SG_BasKlass och är den enda objekttypen i en datamängd om markdetaljer (Figur 11). Tillsammans med kodlistan ML_MarkdetaljTyp (13.4) utgör ML_Markdetalj informationsmodellen för markdetaljer. Ett markdetaljsobjekt är av en viss markdetaljtyp som ges av den hierarkiska kodlistan ML_MarkdetaljTyp. Ett markdetaljsobjekt har en geometri som beskriver dess läge och utbredning. Geometrin kan vara yta, linje, punkt eller kropp. Alla markdetaljer kan ha en höjd som anges med det valfria attributet höjd. Höjden anges i meter över marken. Inom ML_Markdetalj finns möjlighet att ange om detaljen har något särskilt namn (namnmarkdetaljobjekt). Det innebär om detaljen kallas något speciellt eller är tilldelad ett officiellt namn. Till exempel kan en brygga ha ett officiellt namn.

35 35 (63) Objekttyper ML_Markdetalj Förekomst av fysisk företeelse ovan mark Attribut namnmarkdetaljobjekt Namn på markdetalj [0..1] CharacterString markdetaljtyp Typ av markdetalj enl. kodlista [1..1] ML_MarkdetaljTyp geometri Geometri för markdetalj [1..1] SG_Geometri Kodlistor ML_MarkdetaljTyp Typer av markdetaljer 6 Referenssystem Information om det geodetiska referenssystemet för Markdetaljer ska anges, referenssystem enligt Tabell 5 är tillåtna (se Figur 12 för utbredning av referenssystem). Transformation till andra referenssystem eller överräkning till andra projektionszoner ska ske med Gtrans eller annan programvara som innehåller godkända algoritmer. Tabell 5. Tillåtna referenssystem Geodetiskt referenssystem EPSG-kod EPSG:3006 EPSG:3007 EPSG:3008 EPSG:3009 EPSG:3010 EPSG:3011 EPSG:3012 EPSG:3013 EPSG:3014 EPSG:3015 EPSG:3016 EPSG:3017 EPSG:3018 EPSG:5613 EPSG:5628 EPSG:5845 EPSG:5846 EPSG:5847 EPSG:5848 Benämning SWEREF 99 TM SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF RH 2000 SWEREF 99 + RH 2000 (Lat/long) SWEREF 99 TM + RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000

36 36 (63) EPSG:5849 EPSG:5850 EPSG:5851 EPSG:5852 EPSG:5853 EPSG:5854 EPSG:5855 EPSG:5856 EPSG:5857 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 Se Figur 12 för en karta med de lokala sweref 99-zonerna. Temporalt referenssystem Gregorianska kalendern UTC ±0 UTC +1 normaltid (CET) UTC +2 sommartid (CEST) Referenssystemets omfattning Krav 16. Datamängder enligt denna geodataspecifikation ska tillhandahållas med referenssystem Sweref 99 TM och RH 2000.

37 37 (63) Figur 12. Rekommenderade lokala SWEREF-zoner för kommuner Benämning på plankoordinater görs enligt Tabell 6. Tabell 6. Plankoordinater Koordinatsystem Nordlig koordinat (Northing) Östlig koordinat (Easting) SWEREF 99 N E RT 90 x y

38 38 (63) I RH 2000 benämns höjden över havet (Normaal Amsterdam Peil) med H. För ytterligare beskrivning av höjd se motsvarande kapitel i geodataspecifikation Stompunkter. 7 Kvalitetskrav 7.1 Datakvalitet Tabell 7 anger datakvalitetskrav för Markdetaljer. Referenser inom parentes anger tabeller och Id i bilaga D i ISO för vilka kvalitetsmått som ska användas vid redovisning av datakvalitet. I HMK Geodatakvalitet beskrivs utförligare teori och terminologi rörande geodatakvalitet samt exempel på metoder för kvalitetsutvärdering. För lägesosäkerhet avseende fotogrammetriskt inmätta företeelser hänvisas till HMK Teknisk rapport 2013:2 Tolkningsmöjligheter vid olika geometriska upplösningar. Tabell 7. Datakvalitetskrav Nr Kvalitetstema Kvalitets-parameter Kvalitetsmått 1 Fullständighet Datamängdens innehållsmässiga överensstämmelse med specifikationen; brist eller övertalighet för objekt, attribut eller relationer. 2 Fullständighet Datamängdens innehållsmässiga överensstämmelse med specifikationen; brist eller övertalighet för objekt, attribut eller relationer. 3 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). 4 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). 6 Tematisk noggrannhet Överensstämmelse av klassning av företeelser enligt kodlista. 7 Lägesosäkerhet Noggrannhet/mätosäkerhet i position. Brist För få. Övertalighet För många objekt i datamängd i förhållande till verkligheten. Konceptuell konsistens Giltiga kombinationer av värden, som stämmer med informationsmodellen. Domänkonsistens Giltig värdemängd. Domänkonsistens Giltig värdemängd. Absolut osäkerhet I förhållande till referenssystemet. Omfattning A För företeelser och geometrier får högst 5 % saknas i datamängden inom exploateringsområde. Omfattning A Övertalighet ska ej förekomma. Omfattning A 100 % av förekomsterna ska överensstämma med informationsmodellen. (D.13, Id 13). Omfattning A 100 % av förekomsterna ska överensstämma med värden i kodlistor. (D.17, Id 17). Omfattning A 100 % av förekomsterna ska överensstämma med Markdetaljers kodlista, Bilaga D. Omfattning A

39 39 (63) Krav på RMS i plan (D.49 Id 47) är 0,025 m för geodetiskt inmätt Krav på RMS i plan (D.49 Id 47) är 0,02-0,5 m för fotogrammetriskt inmätt Krav på RMS i plan (D.49 Id 47) är 0,2 m för tolkat/digitaliserat Krav på RMS i höjd (D.41, Id 39) är 0,025 m för geodetiskt inmätt Krav på RMS i höjd (D.41, Id 39) är 0,02-0,5 m för fotogrammetriskt inmätt 8 Metadata Metadata anges på datamängdsnivå enligt den Nationella metadataprofilen (aktuell version). För detaljplanering, fastighetsbildning och bygglovshantering är aktualitet en mycket viktig parameter. Aktualitet betraktas i många fall som ett datakvalitetselement, dock inte i ISO Eftersom denna geodataspecifikation använder ISO för att beskriva datakvalitet hanteras aktualitet som en del av metadata som inte avser datakvalitet. Metadata kan också anges på objektnivå framförallt när det gäller geometrier (se ). Metadata kan även sättas på objektnivå och uttrycks då vanligen som attribut på enskilda objekttyper. I Markdetaljer Har inga metadataelement på objektnivå identifierats. Krav 17. Aktualitet för datamängder enligt denna specifikation ska anges. Krav 18. Specifikationsuppfyllelse ska anges i metadata för datamängd enligt denna specifikation. 9 Tillhandahållande Detta kapitel innehåller rekommenderade sätt för att tillhandahålla datamängder enligt denna specifikation. De rekommenderade formaten och leveransmedierna är de som kommer att kunna testas i samband med framtagandet av specifikationen. Användande av andra sätt för tillhandahållande sker utifrån överenskommelse mellan leverantör och mottagare.

40 40 (63) Det är framförallt aktuella data som ska tillhandahållas via de medium och format som anges i detta kapitel. Historiska data kan med fördel följa denna specifikation men åtkomst behöver inte vara allmän utan kan göras utifrån specialiserade anrop till en tjänst eller via beställning av datauttag från ansvarig part. 9.1 Leveransmedium Leveransmedium WFS Medium Geografiska områden utifrån behov (Web Feature Service) Leveransmedium WMS Medium Geografiska områden utifrån behov (Web Map Service) 9.2 Leveransformat Leveransformat GML Beteckning GML (Geography Markup Language) Version Leverantör och mottagare kommer överens om version Specifikation - Filstruktur - Språk Svenska Indelnings-alternativ Indelnings-alternativ Teckenuppsättning Utf Leveransformat Bild (för WMS) Beteckning Exempel: Bitmap (rastergrafik) PNG (rastergrafik) Gif (rastergrafik) Jpeg (rastergrafik)

41 41 (63) Svg (vektorgrafik) Krav 19. WMS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar av denna geodataspecifikation. Rekommendation 6. WFS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar av denna geodataspecifikation. 10 Datafångst och ajourhållning I detta kapitel beskrivs de krav som finns på de processer som skapar Markdetaljer. Datafångst på kommunerna (metoder och rutiner) kan variera mycket från kommun till kommun. Vanligtvis sker datafångst i samband med processerna översiktlig planering, detaljplanering, fastighetsbildning och bygglov (inkl. utstakning och lägeskontroll). Inom dessa processer uppdateras kartunderlaget för att kunna utgöra ett korrekt beslutsunderlag. Datafångst sker även vid framtagning av underlag för projektering eller till analyser av olika slag. Vissa kommuner uppdaterar även data i omdrev, enligt regelbundna uppdateringsplaner, eller inom utvalda exploateringsområden. Val av metod beror bl.a. på hur stora områden som ska samlas in, kraven på lägesosäkerhet, vad som ska tolkas samt detaljeringsgrad. De sistnämnda kraven kan delas in i tre nivåer enligt HMK-Geodatakvalitet 2014, avsnitt 3.2 HMK-standardnivåer: Översiktsplanering (HMK - standardnivå 1) används för nationell/regional mätning och kartläggning för översiktlig planering och dokumentation av byggande, infrastruktur, miljö, naturvård, risker, skogsbruk med mera. Detaljplanering (HMK - standardnivå 2) används för mätning och kartläggning av tätort för kommunal detaljplanering och dokumentation. Projektering (HMK - standardnivå 3) används för projektinriktad mätning och kartläggning för projektering, byggande och förvaltning av bebyggelse, vägar och övrig infrastruktur samt för bygg- och relationshandlingar med mera. Följande insamlingsmetoder tillämpas: Fotogrammetriska metoder med flygbilder som underlag, t.ex. stereokartering Markfotogrammetri med bilder tagna på marken Geodetisk detaljmätning GNSS-mätning (DGPS, RTK eller Nätverks-RTK) Marklasermätning Digitalisering från digitala eller analoga underlag Datafångst inom kommunerna utförs vanligen av kommunens mätavdelning eller av mätkonsultföretag på uppdrag av kommunen. Vanligt är också att kommunerna upphandlar en fotogrammetrisk stereokartering av hela eller delar av kommunen vid specifika behovsstyrda tillfällen.

42 42 (63) Inom kommuner där det statliga Lantmäteriet utgör myndighet för lantmäteriförrättningar (SLM-kommuner) utför Lantmäteriet en uppdatering av detaljer som är av betydelse för lantmäteriförrättningen och som utgör grunden för förrättningskartan. Inom kommuner med avtal för förrättningsförberedelser (KFF-kommuner) mäter kommunen in och uppdaterar detaljer som är av betydelse för lantmäteriförrättningen och som utgör grunden för förrättningskartan. Dessa detaljer sparas i kommunens baskarta samt levereras till Lantmäteriet, vilka producerar förrättningskartan. Inom kommuner som är egen kommunal lantmäterimyndighet (KLM-kommuner) mäter kommunen in och uppdaterar detaljer som är av betydelse för lantmäteriförrättningen och som utgör grunden för förrättningskartan. Dessa detaljer lagras i kommunens baskarta. Sjöfartsverket och Lantmäteriet driver tillsammans projektet Nationell strandlinje (NSL). Syftet är att bygga upp, ajourhålla och förvalta en gemensam version och Sveriges strandlinje. Vissa objekttyper inom Markdetaljer ingår i NSL. För data där insamling och ajourhållning sker på Lantmäteriet, Sjöfartsverket eller andra myndigheter nyttjas till stor del fotogrammetriska metoder med flygbilder, t.ex. stereokartering och kartering i digitalt ortofoto, enligt HMK-standardnivå 1. Lantmäteriet utför periodisk regelbunden datafångst samt produktion. Krav 20. Vid insamling av data inom kommunala verksamheter ska lokala Sweref 99 zoner användas vid mätning för att uppnå tillräcklig lägesosäkerhet. Krav 21. Dokumenterade insamlingsprocesser för kommunal verksamhet ska användas. Rekommendation 7. Kommunala insamlingsprocesser ska utgå ifrån HMK Datafångstkrav För att nå enhetlighet för geodata behöver företeelser mätas in enhetligt och de objekt (framförallt objektens geometrier) som skapas för att representera företeelserna behöver skapas enligt gemensamma regler. Det behöver också i informationsmodeller och datamodeller finnas möjlighet att beskriva hur data har samlats in och om eventuella avsteg från regler har gjorts. För nationella data som samlas in, lagras och ajourhålls av Lantmäteriet finns tydliga regler för hur företeelser ska mätas in och hur geometrier som representerar de ska skapas. Det finns dock inte regler för alla företeelsetyper. För mer information om Lantmäteriets regler hänvisas till specifikationen för grundläggande geografiska data på Lantmäteriet (GGD spec.)

43 43 (63) För data som samlas in, lagras och ajourhålls hos kommuner finns inga nationella regler utan det är upp till varje kommun att fastställa hur insamling sker. I en del (företrädesvis större) kommuner finns tydliga regler och handböcker för hur datainsamling sker. I många kommuner finns å andra sidan inga nedtecknade regler alls utan reglerna finns i huvudet på mätingenjörer/-tekniker. I vissa kommuner finns en del regler nedtecknade och en del är muntligt nedärvda. Det finns således en väldigt stor spridning på hur detta hanteras av kommunala verksamheter och det finns ingen landstäckande sammanställning av hur det skiljer sig åt. Mätningsanvisningar är en specifikation som tas fram för att sammanställa och fastställa regler för inmätning, skapande av objekt och geometrier för geodata både på en nationell nivå och för geodata som skapas i kommunala verksamheter. Med Mätningsanvisningar fylls en lucka igen i arbetet med att skapa enhetliga geodata Underhåll av data omfattning A (Markdetaljer) Underhållsfrekvens Vid behov. Data ska ajourhållas vid följande: Detaljplanering Fastighetsbildning Vid framtagning av projekteringsunderlag Stora kommunala projekt med nyinsamling av data Inkomna relationshandlingar Omfattning Delomfattning A (hela datamängden) Nybyggnation, tillbyggnader och bygglovbefriade åtgärder Underhållsfrekvens Periodisk. Data kan ajourhållas vid följande: Uppdatering av identifierade exploateringsområden Uppdatering i form av omdrev Omfattning Delomfattning A (hela datamängden) 11 Presentationsregler Det är tänkt att data enligt specifikationer ska kunna visas tillsammans, men hur detta ska ske har ännu inte fastställts. När detta är beslutat kommer presentationsregler att beskrivas gemensamt för alla specifikationer.

44 44 (63) 12 Referenser Geodatapecifikation Höjd Geodatapecifikation Stompunkter Geodataspecifikation Markanvändning och Marktäcke Geodataspecifikation Vatten Geodataspecifikation Byggnad Geodataspecifikation Väg och Järnväg Mätningsanvisningar Specifikation för Grundläggande Geografiska Data (GGD - Lantmäteriet) HMK Fotogrammetrisk detaljmätning HMK Geodatakvalitet HMK Ordlista HMK Introduktion HMK Teknisk rapport 2013:2 Tolkningsmöjligheter vid olika geometriska upplösningar NDRK Nationell Digital Registerkarta 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 Regler för applikationsschema SS-EN ISO 19110:2006 Geografisk information - Struktur för katalogisering av objekttyper SS-EN ISO :2014 Geografisk information Metadata Del 1:Grunder SS-EN ISO 19131:2008 Geographic information Specifikation av datamängder SS-EN ISO 19157:2013 Geografisk information Datakvalitet W3C XML Schema Definition Language (XSD) OGC Geography Markup Language,

45 45 (63) 13 Bilagor 13.1 Bilaga A. Test av specifikationsuppfyllelse Test av specifikationsuppfyllelse ska inte hanteras av de enskilda temauppdragen inom. Kommer att hanteras gemensamt med återkoppling till temauppdragen antingen av projektet eller av mottagar-/förvaltarorganisationen. Kommer att utvecklas av mottagande/förvaltande organisation.

46 46 (63) 13.2 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. Figur 11.Symbol för diagram. Modellerna visualiseras av modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa (Figur 11). class Beskriv ning av UML Klass 1 +kännertill +kännertill Klass * Klass 2 Figur 12. Klasser, associationer och generaliseringar. De vanligast förekommande elementen i informationsmodellen är klasser, associationer och generaliseringar/specialiseringar. En klass motsvarar en objekttyp i informationsmodellen och representeras vanligen av en tabell i en databas för en datamängd. En klass har ett namn. Associationer uttrycker att en klass känner till en annan klass (exempel Klass 1 kännertill Klass 3 i Figur 12). Hur klasserna känner till varandra ges av rollerna de har i associationen. Man kan även specificera multiplicitet för parterna i associationen, i Figur 12 uttrycks att Klass 1 känner till noll till många (0..*) av Klass 3 medan Klass 3 endast känner till en och endast en (1) av Klass 1. Om ingen multiplicitet är angiven förutsätts den vara en och endast en (1). En generalisering/specialisering är en vanligt förekommande association, så vanlig att en egen symbol skapats för associationen, en ofylld triangel som pekar ut generaliseringsriktningen. Generaliseringar/specialiseringar skapas oftast då flera klasser har gemensamma egenskaper, istället för att upprepa egenskaperna på varje klass så skapar

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

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

49 49 (63) Figur 15. Beroende och realisering Beroende och realisering (Figur 15) ä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:201x). Realisering (streckad pil med stängd, ofylld spets) i Figur 15 innebär att Klass 12 implementeras som Klass 9 i informationsmodell eller datamodell. I används realiseringar framförallt för att tala om hur de konceptuella begreppen realiseras i informationsmodellen. Figur 16. Paketstruktur i Alla modellelement är indelade i paket (mappar). I förekomer följande paket under huvudpaketet (Figur 16), hela modellen = Svenskgeoprocess): SG_Paketberoenden Innehåller diagram som visar hur olika paket är beroende av varandra och av andra standarder och modeller. SG_GemensammaKlasser Innehåller gemensamma klasser och egenskaper som återkommer i alla teman i. Exempel, geometrier och identifierare. SG_Temanamn Innehåller den enskilda modellen för varje tema inklusive kringinformation. o o TemanamnAnvändningsfall Innehåller användningsfall för aktuellt tema, antingen uppräknade eller mer fullständigt modellerade, efter behov. Användningsfallen är underlag vid avgränsande av temat. TemanamnHelhetsbild Innehåller en helhetsbild (begreppsmodell) över alla de för temat identifierade viktiga företeelser. I helhetsbilden framgår också vilka företeelser som bedömts ligga utanför ett tema. I diagrammet TemanamnHelhetRealisering visas hur respektive företeelse från helhetsbilden som ska ingå i temat realiseras i informationsmodellen.