Markanvändning/Marktäcke

Transkript

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

2 GEODATASPECIFIKATION UPPHOVSMAN DOKUMENTANSVARIG Maria Andersson DOKUMENTNUMMER DOKUMENTDATUM BETECKNING /3030 VERSION Markanvändning och marktäcke FASTSTÄLLD VERSION DOKUMENTDATUM ÄNDRING NAMN Grundversion framtagen Slutversion från projektet Svensk geoprocess. Uppdragsledare: Olov Johansson (Metria AB) Arbetsgrupp: Ida Brännäng (Eskilstuna kommun) Thomas Åkerholm (Lunds kommun) Matilda Sörell (Lantmäteriet) Jimmy Svensson (Lantmäteriet) Kerstin Johansson (Lantmäteriet) Inger Persson (Lantmäteriet) 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. Bild Vatten Markanvändning och Marktäcke Markdetaljer Höjd Väg och Järnväg Byggnad Adress Stompunkter

3 1 (99) 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 Markanvändning och Marktäcke Geodataspecifikationen Markanvändning/ Marktäcke är ett dokument som tagits fram i samverkan mellan SKL, Lantmäteriet och kommunerna. Specifikationen innehåller informationsmodell och krav på geodata som beskriver pågående markanvändning och marktäcke. Markanvändning enligt plan behandlas ej i denna specifikation. Skillnaden mellan markanvändning och marktäcke kan exemplifieras med golfbana. Golfbana är en markanvändning men det sker på marktäcket Öppen mark. Markanvändning är inte en ytmässigt sett heltäckande datamängd och överlappande objekt kan förekomma. Marktäcke är en ytmässigt sett heltäckande datamängd. En förenklad vattenmodell hanteras i som en del av Marktäcke för att kunna erbjuda ett alternativ till Geodataspecifikation Vatten som är baserad på en mer komplex modell. Geodataspecifikationen skildrar tillsammans med processbeskrivningen ett framtida scenario av temat 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 ). Specifikationen avser de geodata om markanvändning och marktäcke som Lantmäteriet och kommunerna samlar in, lagrar och tillhandahåller. s beståndsdelar läses enklast ur avsnitt 5 som innehåller både en informationsmodell (grafisk beskrivning i UML, Unified Modelling Language) samt en objekttypskatalog med ingående objekttyper (klasser), deras attribut och relationer till andra objekttyper. Vilka objekttyper och attribut som är obligatoriska eller frivilliga framgår av informationsmodellen. Både en informationsmodell och en objekttypskatalog ökar möjligheterna att fler tänkta användare ska kunna förstå s informationsmodell. Informationsmodellen kan ses som en avgränsning av vilka företeelsetyper som ingår i temat.

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

5 3 (99) INNEHÅLLSFÖRTECKNING 1 GEODATASPECIFIKATIONENS OMFATTNING 6 2 ÖVERSIKT Information om geodataspecifikationen Termer och definitioner Förkortningar Information om 12 3 MARKANVÄNDNING OCH MARKTÄCKES OMFATTNINGAR Omfattning A Delomfattning B - Markanvändning Delomfattning B1 Markanvändning Lantmäteriet Delomfattning B2 Markanvändning Kommun Delomfattning C - Marktäcke Delomfattning C1 Marktäcke Fullständig version Delomfattning C2 Marktäcke Grundversion Delomfattning C3 Marktäcke Förenklad grundversion Delomfattning C4 Marktäcke Kommun 17 4 IDENTIFIERING AV MARKANVÄNDNING OCH MARKTÄCKE 19 5 DATAINNEHÅLL OCH STRUKTUR Beskrivande text Informationsmodell Okända värden Rumsliga referenssystem Beroenden till andra specifikationer Gemensamma objekttyper SG_BasKlass Geometrityper Höjd och 3D SG_Datamängd Markanvändning/Marktäcke datamängd Markanvändning Marktäcke 40

6 4 (99) Markslagsgräns 41 6 REFERENSSYSTEM 41 7 KVALITETSKRAV Datakvalitet 44 8 METADATA 45 9 TILLHANDAHÅLLANDE Leveransmedium Leveransmedium WFS Leveransmedium WMS Leveransformat Leveransformat GML Leveransformat Bild (för WMS) DATAFÅNGST OCH AJOURHÅLLNING Datafångstkrav Datafångstkrav för delomfattning A, B1, C, C1, C2 och C Datafångstkrav för delomfattning B1 och C Underhåll av data Underhåll av data med delomfattning B1, C1, C2, C Underhåll av data med delomfattning B2 och C PRESENTATIONSREGLER ÖVRIG INFORMATION REFERENSER BILAGOR Bilaga A. Test av specifikationsöverensstämmelse Bilaga B. Beskrivning av UML för informationsmodeller Bilaga C. Fullständig informationsmodell 58

7 5 (99) 14.4 Bilaga D. Kodlistor Bilaga D1. Kodlista markanvändning Bilaga D2. Kodlista marktäcke Bilaga E. Krav och rekommendationer Krav Rekommendationer Bilaga F. Relationer till specifikationer eller datamängder som ej omfattas av Bilaga G. Mappning av kodlistor till LM-data 92

8 6 (99) 1 Geodataspecifikationens omfattning Detta dokument utgör en gemensam geodataspecifikation för pågående markanvändning och marktäcke som framställs på uppdrag av Lantmäteriet, kommunerna och andra myndigheter. Geodataspecifikationen omfattar grundläggande geografiska data som tillsammans med andra data (beskrivna inom eller utanför ) ska kunna utgöra underlag för en baskarta. 2 Översikt 2.1 Information om geodataspecifikationen Titel Geodataspecifikation 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. Syfte Specifikation av de nationella krav som ställs på utbyte av data om markanvändning och marktäcke mellan kommuner och Lantmäteriet. Utbyte kan avse både från producent till datalager eller från datalager till användare. Med utbyte av data om markanvändning och marktäcke avses geometrier med klassificering beskrivande befintlig markanvändning och marktäcke.

9 7 (99) Termer och definitioner Termerna är uppdelade i två tabeller. Tabell 1 beskriver termer från denna specifikation, Tabell 2 innehåller generella termer som används i flera specifikationer. Källa om annan än anges inom parentes efter beskrivning. UML-specifika termer och vissa modelleringstekniska termer beskrivs i Källa om annan än anges inom parentes efter definition. Tabell 1. Termer för markanvändning och marktäcke Markanvändning/Marktäcke termer Term Markslagsgräns Markanvändning Marktäcke Beskrivning (och eventuella kommentarer) Skiljelinje mellan olika typer av marktäcke. Kommentar: Kallas även ägoslagsgräns. Ej heltäckande information som visar användning för ett markområde. Överlappande information kan förekomma. Kommentar: I denna specifikation behandlas endast befintlig markanvändning, ej markanvändning enligt plan såsom detaljplan. Heltäckande ytskikt som visar befintligt markslag. Tabell 2. Generella termer i Generella termer Term Abstrakt objekttyp Abstraktion Applikationsschema 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 Avser vanligtvis representerande av en Företeelsetyp som en Objekttyp eller en Egenskap som en Attributtyp formell beskrivning av datastruktur, regler och innehåll för information inom ett visst tillämpningsområde

10 8 (99) Källa: SIS/STANLI (TK 323) Samverkande GIS med ISO En handbok om tekniskt ramverk för geografisk information, utg 1, 2004 Association Attribut Attributtyp Baskarta Baskarteområde Begreppsmodell Coverage Datamodell Datatyp 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 Kommentar: Olika datatyper har olika egenskaper och kan användas i olika typer av operationer

11 9 (99) 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

12 10 (99) 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 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

13 11 (99) EPSG European Petroleum Survey Group 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.

14 12 (99) 2.2 Information om Namn Förkortning - Beskrivning av innehåll Markanvändning innehåller de typer som har identifierats utgöra underlag vid planering, bygglovshantering och fastighetsbildning. Typerna beskriver befintlig markanvändning (ej heltäckande, överlappande geometrier kan förekomma) och marktäcke (heltäckande geometrier). För samhällsbyggnadsprocessen har lagakraftvunnen markanvändning enligt plan stor betydelse. Den omfattas inte av denna specifikation utan beskrivs i SS637040:2010, detaljplanestandarden, och i dpbl som utvecklas av Boverket och SKL. Däremot har användningsslag ur detaljplanestandarden beaktats i framtagandet av denna specifikation för att bland annat möjliggöra uppföljning av detaljplaners realiserande. Utsträckning i tid och rum Syfte Hela Sverige är väl beskriven och rymmer data om befintlig markanvändning och marktäcke som behövs som underlag vid framförallt detaljplanering, fastighetsbildning och bygglovshantering. Tillsammans med andra geodataspecifikationer ska markanvändning och marktäcke möjliggöra en kommunal 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. Genom enkelt tillgängliga och väl beskrivna data ökar möjligheterna att både snabbt och effektivt fatta rätt beslut och minimera riskerna att felaktiga beslut fattas i brist på underlag eller på grund av att underlaget tolkas fel. Markanvändning och Marktäcke kan också bidra till att annan myndighetsutövning underlättas. Datakällor Lantmäteriet samlar in och lagrar grunddata om markanvändning och marktäcke i skalområdet 1: Vid kommunal verksamhet som kräver detaljerad mätning samlar kommunerna in data om markanvändning och

15 13 (99) marktäcke. Data lagras i respektive kommuns egna databaser enligt kommunspecifika modeller. Produktionsprocesser Dataproduktion på Lantmäteriet utnyttjar till stor del fotogrammetriska metoder med flygbilder vid insamling och ajourhållning. Vid krav på höjdvärde sker insamling med stereokartering i flygbilder. Utan krav på höjdvärde sker insamling med kartering i digitala ortofoton. Dataproduktion på kommunerna består av foto-grammetriska metoder och geodetsik mätning i fält. Lantmäteriet utför periodisk regelbunden datainsamling och produktion medan kommunerna i större utsträckning utför datainsamling och dataproduktion utifrån behov. Ajourhållning Lantmäteriet ajourhåller data periodiskt enligt bildförsörjningsprogrammet. Vid krav på höjdvärde sker ajourhållning med stereokartering i flygbilder. Utan krav på höjdvärde sker ajourhållning med kartering i digitala ortofoton. Flygfotografering sker med olika intervall i olika delar av landet. Vissa teman ajourhålls i samverkan med de myndigheter och organisationer som ansvarar för respektive informationsslag. På kommuner förekommer både periodisk ajourhållning och ajourhållning utifrån nyinsamling eller kontroll av data. 3 s omfattningar Detta kapitel beskriver hur kan delas in i olika delar, delomfattningar, vilket medför att olika krav kan ställas på de olika delarna ur olika aspekter. Exempel på dessa aspekter kan vara att olika objekt kan ha olika krav på lägesosäkerhet eller aktualitet beroende på om de geografiskt befinner sig i tätort eller på landsbygd. Ett annat exempel är att objekt skapas och ajourhålls av olika organisationer med olika krav. Förutom hela så har åtta delomfattningar identifierats som beskrivs nedan. Delomfattningarna är gjorda av både geografisk/geometriska skäl och utifrån de organisationer och verksamheter som skapar data i de olika delomfattningarna. 3.1 Omfattning A Identifiering av omfattning (HMK Standardnivå 1)

16 14 (99) Hierarkisk nivå 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Datamängd beskrivande befintlig markanvändning och marktäcke. Utsträckning Data förekommer över hela Sverige. Coverages - Ingående omfattningar Delomfattning B Delomfattning B1 Delomfattning B2 Delomfattning C Delomfattning C1 Delomfattning C2 Delomfattning C3 Delomfattning C4 3.2 Delomfattning B - Markanvändning Identifiering av omfattning Hierarkisk nivå Markanvändning (HMK Standardnivå 1) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Utsträckning Markanvändning Data om befintlig markanvändning Data förekommer över hela Sverige men är ej yttäckande Överordnad omfattning Delomfattning B1 Markanvändning Lantmäteriet

17 15 (99) Identifiering av omfattning Hierarkisk nivå Markanvändning Lantmäteriet (HMK Standardnivå 1) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Utsträckning Markanvändning Lantmäteriet Data om markanvändning som samlas in av Lantmäteriet. Data förekommer över hela Sverige men är ej yttäckande. Överordnad omfattning Markanvändning Delomfattning B2 Markanvändning Kommun Identifiering av omfattning Hierarkisk nivå Markanvändning Kommun (HMK Standardnivå 2) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Markanvändning Kommun Data om markanvändning som samlas in av kommunal verksamhet i samband med detaljplanering, fastighetsbildning eller bygglovshantering eller annan kommunal verksamhet. Utsträckning Data förekommer över hela Sverige men är inte yttäckande. Vanligtvis finns kommunala data inom respektive kommuns baskarteområde (vanligen där kommunalt vatten och avlopp finns) men även i små öar utanför baskarteområde där exempelvis fastighetsbildning skett eller nybyggnadskarta upprättats Överordnad omfattning Markanvändning 3.3 Delomfattning C - Marktäcke

18 16 (99) Identifiering av omfattning Hierarkisk nivå Marktäcke (HMK Standardnivå 1) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Utsträckning Marktäcke Data om marktäcke. Data förekommer över hela Sverige. Överordnad omfattning Delomfattning C1 Marktäcke Fullständig version Identifiering av omfattning Hierarkisk nivå Marktäcke fullständig version (HMK Standardnivå 1) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Utsträckning Marktäcke Fullständig version Data om marktäcke som samlas in av Lantmäteriet. Data förekommer inom de områden som omfattas av produktion av Fastighetskartan och Terrängkartan. Se Figur 1. Överordnad omfattning Marktäcke Delomfattning C2 Marktäcke Grundversion Identifiering av omfattning Hierarkisk nivå Marktäcke grundversion (HMK Standardnivå 1) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Marktäcke Grundversion Data om marktäcke som samlas in av Lantmäteriet.

19 17 (99) Utsträckning Data förekommer inom de områden av norra Sverige där Terrängkartans T5-version inte ges ut, förutom i fjällområden. Se Figur 1. Överordnad omfattning Marktäcke Delomfattning C3 Marktäcke Förenklad grundversion Identifiering av omfattning Hierarkisk nivå Marktäcke förenklad grundversion (HMK Standardnivå 1) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Utsträckning Överordnad omfattning Marktäcke Förenklad grundversion Data om marktäcke som samlas in av Lantmäteriet. Data förekommer i fjällområden från Sälen i söder till Treriksröset i norr. Se Figur 1. Marktäcke Delomfattning C4 Marktäcke Kommun Identifiering av omfattning Hierarkisk nivå Marktäcke Kommun (HMK Standardnivå 2) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Marktäcke Kommun Data om marktäcke som samlas in av kommunal verksamhet i samband med detaljplanering, fastighetsbildning eller bygglovshantering eller annan kommunal verksamhet. Utsträckning Data förekommer över hela Sverige men är inte yttäckande. Vanligtvis finns kommunala data inom respektive kommuns baskarteområde (vanligen där kommunalt vatten och avlopp finns) men även i små öar utanför baskarteområde där exempelvisa fastighetsbildning skett eller nybyggnadskarta upprättats

20 18 (99) Överordnad omfattning Marktäcke Figur 1. Lantmäteriets detaljeringsgrad av marktäckedata

21 19 (99) 4 Identifiering av Titel Alternativ titel Versionsnummer Sammanfattning innehåller utrymme för att beskriva befintlig markanvändning med olika detaljeringsnivåer samt marktäcke med olika detaljeringsnivåer. Markanvändning och marktäcke representeras med ytor eller med linjer. Markanvändning är ej ytmässigt heltäckande och överlappande geometrier kan förekomma. Marktäcke är ytmässigt heltäckande representerat. Syfte är väl beskriven och rymmer data om befintlig markanvändning och marktäcke som behövs som underlag vid framförallt detaljplanering, fastighetsbildning och bygglovshantering. Tillsammans med andra geodataspecifikationer ska möjliggöra en kommunal 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ättningsverk-samhetens krav på information från baskartan. Genom enkelt tillgängliga och väl beskrivna data ökar möjligheterna att både snabbt och effektivt fatta rätt beslut och minimera riskerna att felaktiga beslut fattas i brist på underlag eller på grund av att underlaget tolkas fel. kan också bidra till att annan myndighetsutövning underlättas. Ämnesområde 010 Arealtäckande bilder och baskartor Ämnesområde ur den nationella metadataprofilen. Metod för rumslig representation 001 Vektor Ur den nationella metadataprofilen. Rumslig upplösning - Geografisk utsträckning förekommer över hela Sverige.

22 20 (99) Kompletterande information - 5 Datainnehåll och struktur 5.1 Beskrivande text är uppbyggd av en enkel informationsmodell med två objekttyper som representerar markanvändning och marktäcke. Markanvändningstyper och marktäcketyper finns i två hierarkiska kodlistor med två olika detaljeringsnivåer. Dessa kodlistor är baserade på Lantmäteriets data om marktäcke samt anläggningsområden och från kommunernas klassificering av markanvändning respektive marktäcke. Markanvändningskodlistan innehåller en mappning till Inspires HILUCSkodlista (Hierarchical Inspire Land Use Classification System) som används i Inspiretemat Land Use. I kapitlet Informationsmodell nedan beskrivs i detalj alla ingående objekttyper, attribut och associationer som ingår i. Beskrivning sker med hjälp av figurer (UML-diagram), 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. Inom har inga applikationsscheman (enligt ISO 19109) tagits fram utan det sätt som s 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 14.2 för information om hur UML har använts i. 5.2 Informationsmodell Informationsmodellen är uppdelad i flera figurer för att belysa de olika delarna av modellen. Hela informationsmodellen återfinns i Fel! Hittar inte referenskälla.. I avgränsandet av så har företeelser identifierats som s objekttyper har beroenden eller associationer till men som inte omfattas av. I Fel! Hittar inte referenskälla. 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. 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).

23 21 (99) I objekttypskatalogen ingår endast objekttyper skapade för Markanvändning och Marktäcke och ej objekttyper från annan modell eller standard även om dessa syns i figurerna med UML-diagram. 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 visar hur värden i kodlistorna i denna specifikation kan mappas mot Lantmäteriets motsvarande data. 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 2. 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. 1). Krav 2. Informationsmodellens angivelser om multiplicitet ska följas för datamängder enligt denna geodataspecifikation (Se kapitel 7.1, Nr. 1). Krav 3. Endast värden från kodlistor ska användas för attribut vars typ är en kodlista (Se kapitel 7.1, Nr. 2). Krav 4. Kodlistor är utökningsbara. Utökad kodlista ska tillhandahållas av ansvarig part.

24 22 (99) 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>

25 23 (99) </SG_Objekt> <id>yyyyy</id> <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>

26 24 (99) Beroenden till andra specifikationer pkg MarkanvändningPaketBeroenden SG_GemensammaKlasser VN_Vatten (from SvenskGeoprocess) (from SvenskGeoprocess) ML_MarkDetaljer MA_Markanv ändning ss (from SvenskGeoprocess) VJ_VägJärnv äg (from SvenskGeoprocess) (from SvenskaStandarder) Land Use (from SvenskGeoprocess) MT_Marktäcke (from Annex III) (from SvenskGeoprocess) Figur 3. Paketdiagram visande s beroenden. utnyttjar andra standarder och modeller. Detta illustreras genom paketberoenden (Figur 3). s typer har identifierats ha relationer till objekttyper som återfinns i andra geodataspecifikationer inom. Figur 3 visar därför beroenden från Markanvändning och Marktäcke till andra geodataspecifikationer inom 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 4) är en abstrakt superklass (objekttyp) som äger de mest grundläggande attributen som krävs vid utbyte av geodata. Nästan alla andra objekttyper i alla specifikationer inom kan vara specialiseringar av typen SG_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

27 25 (99) två olika id:n, ett nationellt-id eller ett verksamhets-id. Båda är av datatypen Identifier (Figur 5) 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 specifi kation, 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 4. SG_BasKlass

28 26 (99) class Inspire_Id «datatype» Base Types::Identifier + localid :CharacterString + namespace :CharacterString «lifecycleinfo, voidable» + versionid :CharacterString [0..1] Figur 5. 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.1). Krav 8. Då endast en identifierare anges skall den vara av typen nationellid.

29 27 (99) 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. 1). 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 Datum då objekt först skapades i datamängd. [0..1] DateTime

30 28 (99) endlifespanversion externreferens aktualitet Datum från när objekt inte längre ingår i datamängd. Referens till annan objekttyp i eller utanför. Datum då objektet senast befanns vara korrekt. [0..1] DateTime [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 6. De är i huvudsak specialiseringar av geometrityper från SS-ISO 19107:2003 Modell för att beskriva rumsliga aspekter.

31 29 (99) 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 6. 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. 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 7) samt vilken metod som har använts för att fastställa lägesosäkerheten.

32 30 (99) 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 7. 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 8). 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 8. 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.

33 31 (99) Då man inte hanterar ytor utan linjer som geometrisk representation för ytutbredda företeelser i verkligheten så förekommer de ofta tillsammans med en centroid (SG_Punkt med attributet ärcentroid=true) och topologier för att avgränsa en företeelses utbredning. Centroiden tillsammans med linjer kan användas för at konstruera en yta vid behov. En linje kan behöva presenteras i till exempel en karta. För en del linjer kan detta behöva ske utan att ytan som den delvis avgränsar ritas ut. Hur linjen ska presenteras (portrayal/manér) beror på vilka typer av företeelser den avgränsar. Attributet kartografiskrepresentation på objekttypen SG_Linje ger möjlighet att beskriva hur en linje är tänkt att representeras kartografiskt med kodlistan SG_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 9. Geometrimetadata

34 32 (99) I Figur 9 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. 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. Krav 15. Geometri ska finnas för samtliga objekt i datamängd enligt denna geodataspecifikation (Se kapitel 7.1, Nr. 1) 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

35 33 (99) 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 tillsammans med linjer kan användas vid skapande av ytgeometri. [0..1] Boolean 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 Syfte för vilket geometri skapats Beskrivning av hur en geometri är inmätt [0..1] CharacterString [0..1] SG_InmätningsLäge

36 34 (99) tänktupplösningpresentation aktualitet insamlingsdatum beginlifespanversion osäkertläge osäkertlägeanledning endlifespanversion 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 Datum då objekt skapades i datamängd Kommentar: Avser vanligen det datum då ett objekt lagras i en databas men kan också avse det datum då mätning i bild eller tolkning av fältdata görs Markering om att direkt mätning av geometri inte kunnat ske 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. [0..1] MD_Resolution [0..1] DateTime [0..1] DateTime [0..1] DateTime [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

37 35 (99) 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 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. SG_KartografiskRepresentationLinjeTyp SG_KantlinjeEgenskap- Typ Värden Egenskaper som en kantlinje kan ha Beskrivning Kantsten Släntfot Släntkrön 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

38 36 (99) 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. 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 10) class SG_Datamängd «DataSet» SG_GemensammaKlasser:: SG_Datamängd + aktualitet :DateTime + sekretessreglerad :Boolean = false +metadata Metadata entity set information::md_metadata Figur 10. 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 Objekttyper

39 37 (99) SG_DataMängd SG_Datamängd visar hur metadata kopplas till datamängder. Attribut Beskrivning Multiplicitet Datatyp aktualitet sekretessreglerad Det datum datamängden senast befanns vara korrekt. Talar om huruvida en datamängd omfattas av sekretess. Kommentar: Standardvärde är False [1..1] DateTime [1..1] Boolean Markanvändning/Marktäcke datamängd class MA_MarkanvändningDatamängd «DataSet» SG_GemensammaKlasserInformation:: SG_Datamängd + aktualitet: DateTime [0..1] + sekretessreglerad: Boolean [0..1] = false +metadata Metadata entity set information::md_metadata «DataSet» MA_Markanv ändningdatamängd 1..* «FeatureType» MA_Markanv ändning SG_BasKlass + namnmarkanvändningobjekt: CharacterString [0..1] + markanvändningstyp: MA_MarkanvändningTyp + geometri: SG_Geometri Figur 11. Datamängd Markanvändning

40 38 (99) class MT_MarktäckeDatamängd «DataSet» SG_GemensammaKlasserInformation:: SG_Datamängd + aktualitet: DateTime [0..1] + sekretessreglerad: Boolean [0..1] = false +metadata Metadata entity set information::md_metadata «DataSet» MT_MarktäckeDatamängd 1..* «FeatureType» MT_Marktäcke SG_BasKlass + namnmarktäckeobjekt: CharacterString [0..1] + marktäcketyp: MT_MarktäckeTyp + geometri: SG_Geometri Figur 12. Datamängd Marktäcke Figur 11 och Figur 12 visar hur datamängder med markanvändningsdata respektive marktäckedata enligt denna specifikation sätts ihop och att metadata ska anges på datamängdsnivå. 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 Objekttyper MA_Markanvändning- Datamängd Visar hur en datamängd som representerar markanvändning sätts samman och hur koppling till metadata ser ut. Attribut Beskrivning Multiplicitet Datatyp MT_MarktäckeDatamängd Visar hur en datamängd som representerar marktäcke sätts samman och hur koppling till metadata ser ut. Attribut Beskrivning Multiplicitet Datatyp

41 39 (99) Markanvändning class MA_Markanvändning +representerarsammaföreteelse 0..* «FeatureType» SG_GemensammaKlasserInformation:: SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime «FeatureType» MA_Markanv ändning + namnmarkanvändningobjekt: CharacterString [0..1] + markanvändningstyp: MA_MarkanvändningTyp + geometri: SG_Geometri «codelist» MA_MarkanvändningKodlistor:: MA_MarkanvändningTyp Figur 13. Markanvändning Markanvändning avser befintlig eller pågående markanvändning. Exempel på markanvändning är jordbruk, skogsbruk, rekreation, bebyggelseområde med flera. Objekttypen MA_Markanvändning (Figur 13) är en SG_BasKlass och den enda objekttypen i en datamängd om markanvändning. Tillsammans med kodlistan MA_MarkanvändningTyp (se ) utgör MA_Markanvändning informationsmodellen för markanvändning. Ett markanvändningsobjekt är av en viss markanvändningstyp som ges av den hierarkiska kodlistan MA_MarkanvändningTyp. Ett markanvändningsobjekt har en geometri som beskriver dess utbredning. Geometrin är vanligen en yta eller en uppsättning linjer som avgränsar markanvändningsobjektet som ofta identifieras av en centroid ( ). I de fall linjer används skall linjerna vara av linjetypen Kantlinje ( ). Överlappande geometrier för markanvändningsobjekt kan förekomma. Ett markanvändningsobjekt kan ha ett namn, detta kan till exempel användas för att beskriva om ett urbant grönområde i dagligt tal kallas för en park.

42 40 (99) Marktäcke class MT_Marktäcke «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» MT_Marktäcke + namnmarktäckeobjekt: CharacterString [0..1] + marktäcketyp: MT_MarktäckeTyp + geometri: SG_Geometri «codelist» MT_MarktäckeKodlistor:: MT_MarktäckeTyp Figur 14. Marktäcke Marktäcke beskriver hur markytan är täckt av vegetation, bebyggelse eller om det är en öppen markyta. Objekttypen MT_Marktäcke (Figur 14) är en SG_BasKlass och den enda objekttypen i en datamängd om marktäcke. Tillsammans med kodlistan MT_MarktäckeTyp (se ) utgör MT_Marktäcke informationsmodellen för marktäcke. Ett marktäckeobjekt är av en viss marktäcketyp som ges av den hierarkiska kodlistan MT_MarktäckeTyp. Ett marktäckeobjekt har en geometri som beskriver dess utbredning. Geometrin är vanligen en yta eller en uppsättning linjer som avgränsar marktäckeobjektet som ofta identifieras av en centroid (SG_Punkt). I de fall linjer används skall linjerna vara av linjetypen Kantlinje ( ). Ett marktäckeobjekt kan ha ett namn även om detta inte är vanligt förekommande. För delomfattning C2 och C3 används inte marktäcketyperna: Öppen mark Barrskog

43 41 (99) Lövskog Fjällbjörkskog Kalfjäll De ersätts där av marktäcketypen Övrig mark Krav 16. För delomfattning C2 och C3 skall Övrig mark användas och då inkludera marktäckeobjekt av typerna Öppen mark, Barrskog, Lövskog, Fjällbjörkskog och Kalfjäll Markslagsgräns En markslagsgräns beskriver övergången från en typ av marktäcke till en annan och är ett sätt att beskriva linjer som avgränsar marktäckeobjekt. Markslagsgräns används framförallt för olika kartografiska representationer av marktäckedata. Markslagsgräns utgör ingen egen objekttyp i för att undvika att flera objekttyper beskriver samma företeelsetyp. Markslagsgräns anges med hjälp av attributet kartografiskrepresentation på en SG_Linje. För datamängder enligt denna specifikation rekommenderas att de värden, och efterföljande symboler, som används (kodlistan SG_TypAvKartografiskRepresentation) hämtas från HMK Kartografi, bilaga D. 6 Referenssystem Information om det geodetiska referenssystemet för ska anges, referenssystem enligt Tabell 5 är tillåtna (se Figur 15 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 Benämning SWEREF 99 TM SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF

44 42 (99) EPSG:3016 EPSG:3017 EPSG:3018 EPSG:5613 EPSG:5628 EPSG:5845 EPSG:5846 EPSG:5847 EPSG:5848 EPSG:5849 EPSG:5850 EPSG:5851 EPSG:5852 EPSG:5853 EPSG:5854 EPSG:5855 EPSG:5856 EPSG:5857 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 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 15 för en karta med de lokala sweref 99-zonerna. Temporalt referenssystem Referenssystemets omfattning Gregorianska kalendern UTC ±0 UTC +1 UTC +2 normaltid (CET) sommartid (CEST) Data enligt omfattning A, B, B1, C, C1, C2 och C3 görs i referenssystem SWEREF 99, kartprojektion SWEREF 99 TM (EPSG:3006) och höjdsystem RH 2000 (EPSG:5613). Data enligt delomfattning B2 och C4 görs antingen i referenssystem SWEREF 99, kartprojektion SWEREF 99 TM (EPSG:3006) och höjdsystem RH 2000 (EPSG:5613) eller i RH 2000 i höjd samt lokal zon av referenssystem i plan (EPSG:3007 EPSG:3018, EPSG:5846 EPSG:5857) Samma temporala referenssystem används för alla omfattningar. Samma temporala referenssystem används för alla omfattningar. Krav 17. Datamängder enligt denna geodataspecifikation ska tillhandahållas med referenssystem Sweref 99 TM och RH 2000.

45 43 (99) Figur 15. 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

46 44 (99) RT 90 x y I RH 2000 benämns höjden över havet (Normaal Amsterdam Peil) med H. För ytterligare beskrivning av höjd se motsvarande kapitel i geodataspecifikation Stompunkter. 7 Kvalitetskrav Kompletteras till version Datakvalitet Tabell 7 anger datakvalitetskrav för. Referenser inom parentes anger tabeller och Id i bilaga D i ISO för vilka kvalitetsmått som ska användas vid redovisning av datakvalitet. I HMK Geodatakvalitet beskrivs utförligare teori och terminologi rörande geodatakvalitet samt exempel på metoder för kvalitetsutvärdering. Tabell 7. Datakvalitetskrav Nr Kvalitetstema Kvalitetsparameter Kvalitetsmått 1 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). 2 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). 3 Lägesosäkerhet Noggrannhet/mätosäkerhet i position. Konceptuell konsistens Giltiga kombinationer av värden, som stämmer med informationsmodellen. Domänkonsistens Giltig värdemängd. Absolut osäkerhet I förhållande till referenssystemet. 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). Delomfattning, C1, C2 och C3 Krav på RMS i plan (D.49 Id 47) är 15 m för: Öppen mark Kalfjäll Krav på RMS i plan (D.49, Id 47) är 20 m för: Skog Sankmark Övrig mark

47 45 (99) Krav på RMS i plan (D.49, Id 47) är 50 m för: Ej karterat område 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 kapitel ). Metadata kan även sättas på objektnivå för annat än geometri och uttrycks då vanligen som attribut på enskilda objekttyper. I har inga metadataelement på objektnivå identifierats. Krav 18. Aktualitet för datamängder enligt denna geodataspecifikation ska anges. Krav 19. Specifikationsuppfyllelse ska anges i metadata för datamängd enligt denna geodataspecifikation. 9 Tillhandahållande Detta kapitel innehåller rekommenderade sätt för att tillhandahålla datamängder enligt denna specifikation. De rekommenderade formaten och leveransmedierna är de som kommer att kunna testas i samband med framtagandet av specifikationen. Användande av andra sätt för tillhandahållande sker utifrån överenskommelse mellan leverantör och mottagare. Det är framförallt aktuella data som ska tillhandahållas via de medium och format som anges i detta kapitel. Historiska data kan med fördel följa denna specifikation men åtkomst behöver inte vara allmän utan kan göras utifrån specialiserade anrop till en tjänst eller via beställning av datauttag från ansvarig part. 9.1 Leveransmedium Leveransmedium WFS Indelnings-alternativ Geografiska områden utifrån behov

48 46 (99) Medium (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 Teckenuppsättning Utf Leveransformat Bild (för WMS) Beteckning Exempel: Bitmap (rastergrafik) PNG (rastergrafik) Gif (rastergrafik) Jpeg (rastergrafik) Svg (vektorgrafik) Krav 20. WMS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar av denna geodataspecifikation.

49 47 (99) 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 Markanvändning- och Marktäckedata. Dataproduktion på Lantmäteriet utnyttjar till stor del fotogrammetriska metoder med flygbilder vid insamling och ajourhållning t.ex. stereokartering och skärmbildsdigitalisering på digitalt ortofoto. Dataproduktion på kommunerna består av detaljerad mätning för detaljplanering, fastighetsbildning, bygglovshantering med mera. Kommunerna utnyttjar även fotogrammetriska metoder. Lantmäteriet utför periodisk regelbunden datainsamling och produktion medan kommunerna utför datainsamling och dataproduktion utifrån behov Datafångstkrav För att nå enhetlighet för geodata behöver företeelser mätas in enhetligt och de objekt (framförallt objektens geometrier) som skapas för att representera företeelserna behöver skapas enligt gemensamma regler. Det behöver också i informationsmodeller och datamodeller finnas möjlighet att beskriva hur data har samlats in och om eventuella avsteg från regler har gjorts. För nationella data som samlas in, lagras och ajourhålls av Lantmäteriet finns tydliga regler för hur företeelser ska mätas in och hur geometrier som representerar de ska skapas. Det finns dock inte regler för alla företeelsetyper. För mer information om Lantmäteriets regler hänvisas till specifikationen för grundläggande geografiska data på Lantmäteriet (GGD spec.) För data som samlas in, lagras och ajourhålls hos kommuner finns inga nationella regler utan det är upp till varje kommun att fastställa hur insamling sker. I en del (företrädesvis större) kommuner finns tydliga regler och handböcker för hur datainsamling sker. I många kommuner finns å andra sidan inga nedtecknade regler alls utan reglerna finns i huvudet på mätingenjörer/-tekniker. I vissa kommuner finns en del regler nedtecknade och en del är muntligt nedärvda. Det finns således en väldigt stor spridning på hur detta hanteras av kommunala verksamheter och det finns ingen landstäckande sammanställning av hur det skiljer sig åt. Mätningsanvisningar är en specifikation som tas fram för att sammanställa och fastställa regler för inmätning, skapande av objekt och geometrier för geodata både på en nationell nivå och för geodata som skapas i kommunala verksamheter. Med Mätningsanvisningar fylls en lucka igen i arbetet med att skapa enhetliga geodata.

50 48 (99) Datafångstkrav för delomfattning A, B1, C, C1, C2 och C3 Data ska framställas enligt Lantmäteriets processer för ajourhållning där man till stor del använder fotogrammetriska metoder med flygbilder t.ex. stereokartering och skärmbildsdigitalisering på digitalt ortofoto. Upplösningen på flygbilderna ska vara 50 cm för 4-6 års intervall och 6-10 års intervall (se ). Cirka 130 av de största tätorterna och områden med 2 års intervall (se ) fotograferas med en högre upplösning på flygbilderna som ska vara 25 cm Datafångstkrav för delomfattning B1 och C4 Krav 21. 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 22. Dokumenterade insamlingsprocesser för kommunal verksamhet ska användas för delomfattningar B1 och C4. Rekommendation 7. Kommunala insamlingsprocesser ska utgå ifrån HMK Underhåll av data Beskrivning av underhåll och uppdatering av data Underhåll av data med delomfattning B1, C1, C2, C3 Underhållsfrekvens Periodiskt Enligt Lantmäteriets bildförsörjningsprogram (Figur 16) som har olika flygfotointervall för olika delar av landet. 2 års intervall i södra Sverige samt utmed Norrlands kustland 4-6 års intervall i norra Svealands och Norrlands inland 6-10 års intervall i fjälltrakterna

51 49 (99) Figur 16. Lantmäteriets bildförsörjningsprogram Anmärkning: Lantmäteriet dokumenterar inte ajourhållning om inga redigeringar görs. Omfattning B1, C1, C2 och C Underhåll av data med delomfattning B2 och C4 Underhållsfrekvens Vid behov Data ska ajourhållas vid följande:

52 50 (99) Detaljplanering Nybyggnation Fastighetsbildning Inkomna relationshandlingar Stora kommunala projekt med nyinsamling av data Omfattning Delomfattning B2 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. 12 Övrig information 13 Referenser Geodatapecifikation Höjd Geodatapecifikation Stompunkter Geodatapecifikation Vatten Geodatapecifikation Markdetaljer Geodatapecifikation 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 Kartografi, 1996 Vägars och gators utformning, Begrepp och grundvärden, Trafikverkets publikation 2012:199. dpbl, Inspires dataspecifikation för Markanvändning, 3.0 SS :2010 Geografisk information Detaljplan Applikationsschema för planbestämmelser 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

53 51 (99) SS-EN ISO 19108:2005 Geographic information Modell för att beskriva tidsaspekter SS-EN ISO 19115: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,

54 52 (99) 14 Bilagor 14.1 Bilaga A. Test av specifikationsöverensstämmelse Test av specifikationsuppfyllelse ska inte hanteras av de enskilda temauppdragen inom. Kommer att hanteras gemensamt av Samverkan.

55 53 (99) 14.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 17.Symbol för diagram. Modellerna visualiseras av modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa (Figur 18). class Beskriv ning av UML Klass 1 +kännertill +kännertill Klass * Klass 2 Figur 18. 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 18). 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 18 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

56 54 (99) men en superklass (Klass 1 i Figur 18) med de gemensamma egenskaperna. De specialiserade klasserna (Klass 2 i Figur 18) ä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 19. Attribut, stereotyper, datatyper och kodlistor. Klasser kan ha andra egenskaper än associationer, i Figur 19 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 19 ä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 19 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 19). 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

57 55 (99) attributet får anta. Kodlistor är utökningsbara under premissen att utökningen görs tillgänglig tillsammans med datamängden. Stereotyper (exempel <<FeatureType>> på Klass 10 i Figur 19) ä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 20. 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 20 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.

58 56 (99) class Beskriv ning av UML Klass 8 Klass 9 Klass 12 Figur 21. Beroende och realisering Beroende och realisering (Figur 21) ä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 21 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 22. Paketstruktur i Alla modellelement är indelade i paket (mappar). I förekomer följande paket under huvudpaketet (Figur 22, 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.