Väg och järnväg. Version Förslag till förändring av företeelsetyper i NVDB. Flygbild/ Ortofoto. Laserdata/ Höjdmodell

Transkript

1 Version Flygbild/ Ortofoto Hydrografi Markanvändning Markdetaljer Laserdata/ Höjdmodell Väg/Järnväg Byggnad Adress Stompunkter

2 UPPHOVSMAN DOKUMENTANSVARIG NN Adress DOKUMENTNUMMER DOKUMENTDATUM BETECKNING VERSION FASTSTÄLLD VERSION DOKUMENTDATUM ÄNDRING NAMN Förslag till version 0.5, cirkuleras i arbetsgrupp. Olov Johansson Förslag version 0.5 till styrgrupp och referensgrupp Förslag version 0.8, till referensgrupp. Version till styrgrupp för beslut Olov Johansson Olov Johansson Olov Johansson Flygbild/ Ortofoto Hydrografi Markanvändning Markdetaljer Laserdata/ Höjdmodell Väg/Järnväg Byggnad Adress Stompunkter

3 1 (72) Bakgrund I samverkansprojektet utarbetas dataproduktspecifikationer (DPS) 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 DPS:erna bedrivs i samverkan mellan kommuner, Lantmäteriet och för temat andra berörda myndigheter. DPS:erna inspireras av standarden SS-EN ISO 19131:2008, Geografisk information Specifikation av datamängder och 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 Väg och Järnväg, Förslag till förändring av företeelsetyper i NVDB. Väg och Järnväg är ett förslag som tagits fram i samverkan mellan SKL, Lantmäteriet, kommunerna och Trafikverket. Förslaget behandlar förändringar av företeelsetyper i NVDB beskrivande vägar på ett för kommuner och lantmäteriet mer användbart sätt än befintliga företeelsetyper. När det gäller järnvägsinformation har de dataprodukter som avgränsats i projektet NJDB på Trafikverket studerats och bedömningen har gjorts att dessa initialt är tillräckliga för både kommuner och Lantmäteriets behov. Det rekommenderas dock att Trafikverket i det fortsatta arbetet med NJDB gör det i dialog med både kommuner och Lantmäteriet. Detta förslag skildrar tillsammans med en processbeskrivning (separat dokument) ett framtida scenario av temat Väg och Järnväg 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 ). Den nationella vägdatabasen (NVDB) som förvaltas av Trafikverket är baserad på en väl etablerad modell för att beskriva vägnät och vägnätsanknutna företeelser som används bland annat vid utbyte av data mellan kommunerna och Trafikverket. NVDB har dessutom ambitionen att vara en nationell central vägdatabas vilket detta arbete stödjer. Detta förslag erbjuder alltså INTE en ersättning till NVDB utan kan snarare ses som ett förslag till tillägg av nya företeelsetyper, förändringar/förtydliganden av befintliga företeelsetyper och vissa fall avvecklande av befintliga företeelsetyper och ersätta dem med nya (Figur 1). Detta dokument är skrivet enligt den mall som använts för att ta fram dataproduktspecifikationer för andra teman inom men är inte att betrakta som en dataproduktspecifikation i nuvarande form. Önskvärt vore att en förändring av NVDB skulle kunna ske och förvaltas inom ramen för nuvarande NVDB.

4 2 (72) Figur 1. Dataprodukten Väg och Järnvägs innehåll och förhållande till NVDB. Detta förslag avser de geodata om Väg och Järnväg som framförallt Lantmäteriet och kommunerna men även andra aktörer samlar in, lagrar och tillhandahåller. Med Väg och Järnväg avses nätverksmodeller representerande vägnät och järnvägsnät samt nätanknutna företeelsetyper. Observera att termen företeelsetyp även används i andra sammanhang än för nätverksanknutna företeelsetyper (se Termer och beskrivningar). Många av de egenskaper som är aktuella utifrån projektets fokuserade processer (detaljplanering, fastighetsbildning och bygglovsärenden) och som rör vägar hanteras av andra dataprodukter framtagna inom. Vägars utbredning samt hur vägars uppdelning i olika delar såsom körfält, körbana, slänter med mera beskrivs som markanvändning medan vägars beläggning beskrivs som marktäcke. Skälet till att hantera detta som markanvändning respektive marktäcke är för att ge möjligheten att skapa topologiskt sammanhängande skikt och att återanvända geometrier för ytutbredda företeelsers gränser. En del ytterligare verkliga företeelser som har anknytning till vägar och järnvägar som vägbommar representeras som Markdetaljer. Det finns möjligheter att länka ihop data enligt olika dataproduktspecifikationer som egentligen representerar samma företeelse. Till exempel kan en väg som representeras som en länk i ett nätverk via identifierare länkas till markanvändningen körbana och till marktäcket asfalt. Det finns dock vägrelaterade företeelsetyper som inte är representerade i andra dataprodukter i. Var dessa ska hanteras kommer att beaktas enskilt utifrån befintliga dataproduktspecifikationer och användarbehov. Under arbetets gång har behov identifierats som har representerats med nätverksanknutna företeelsetyper i detta dokument som sannolikt inte kommer att implementeras i NVDB inom överskådlig tid på grund av olika orsaker. Samverkan (fortsättningen efter projektet ) kommer att behöva kika på dessa företeelsetyper och behovet av att utbyta dessa enhetligt utanför den nationella samverkan kring NVDB. Den troliga lösningen är ett enkelt xml-schema baserat på en vedertagen nätverksmodell men där bas för identifierare och geometri etcetera används.

5 3 (72) Förslagets 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å detta förslags informationsmodell Informationsmodellen kan ses som en avgränsning av vilka naturliga företeelser som ingår i temat. Som ett komplement till denna avgränsning så finns i förslaget även illustrationer av andra närliggande företeelser som identifierats i arbetet med specifikationen. I den mån de närliggande företeelserna omfattas av andra teman inom går detta att utläsa. Krav på dataprodukten uttrycks i respektive tillämpligt avsnitt av dataproduktspecifikationen. 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 dataproduktspecifikationen. Deltagande i framtagandet av detta förslag har varit: Åsa Eriksson (Trafikverket), Fredrik Olsson (Karlstad kommun) Helena Andersson (Trafikverket), Jan Elofsson (Helsingborgs stad), Jan Sjöhed (Lantmäteriet), Lars Robertsson (Borlänge kommun) Linda Thelberg (Lantmäteriet), Linnea Söderblom (Lantmäteriet), Marie Ljungh (Botkyrka kommun), Mats Johansson (Linköpings kommun), Suzana Velevska (Lantmäteriet), Torsten Svärd (Lantmäteriet), Ulrika Johansson (Lantmäteriet), Matilda Sörell (Lantmäteriet) och Olov Johansson (Metria AB). Detta förslag är tillgänglig som ett dokument (.pdf) från

6 4 (72) INNEHÅLLSFÖRTECKNING Innehåll Olov Johansson 0 1 FÖRSLAGETS OMFATTNING 6 2 ÖVERSIKT Information om detta dokument Termer och beskrivningar Förkortningar Information om befintliga datamängder om vägar och järnvägar10 3 DETTA FÖRLAGS OMFATTNINGAR Omfattning A Alla omfattningar Delomfattning B Väg och Järnväg Nationell Delomfattning C Väg och Järnväg Kommun Delomfattning D Väg och Järnväg Projektering 14 4 IDENTIFIERING AV DETTA DOKUMENT 14 5 DATAINNEHÅLL OCH STRUKTUR Beskrivande text Informationsmodell och objekttypskatalog Beroenden till andra dataprodukter Gemensamma objekttyper datamängd Trafiknät Nätanknutna företeelsetyper 31 6 REFERENSSYSTEM 58 7 KVALITETSKRAV Datakvalitet 61 8 METADATA 61

7 5 (72) 9 TILLHANDAHÅLLANDE Leveransmedium Leveransmedium WFS Leveransmedium WMS Leveransformat Leveransformat GML Leveransformat Bild (för WMS) DATAFÅNGST OCH AJOURHÅLLNING Datafångstkrav Underhåll av data Underhåll av data med delomfattning B PRESENTATIONSREGLER ÖVRIG INFORMATION REFERENSER BILAGOR Bilaga A. Test av specifikationsuppfyllelse Bilaga B. Beskrivning av UML för informationsmodeller Bilaga C. Fullständig informationsmodell Bilaga D. Kodlistor Bilaga E. Krav och rekommendationer Krav Rekommendationer 71

8 6 (72) 1 Förslagets omfattning Detta dokument utgör ett gemensamt förslag på förändring av NVDB som framställts på uppdrag av Lantmäteriet, kommunerna och andra myndigheter. 2 Översikt 2.1 Information om detta dokument Titel Väg och Järnväg, Förslag till förändring av företeelsetyper i NVDB Datum Ansvarig part Lantmäteriet i samverkan med kommuner och SKL Lantmäteriet, Division Geodata, enheten Geografisk information och sektionen Adress Gävle Telefon E-post URL specifikationer@lm.se Språk Svenska Ämnesområde Syfte 018 Transporter 013 Positionering Ämnesområde ur den nationella metadataprofilen (ref). Detta dokument har flera syften. Ett av syftena är att försöka fånga de nationella krav som ställs på utbyte av geodata om väg och järnväg mellan kommuner, Lantmäteriet, Trafikverket samt andra aktörer i samhällsbyggnadsprocessen som till exempel infrastrukturbyggare. Utbyte kan avse både från producent till datalager eller från datalager till användare. Ett annat syfte är att ta fram förslag på förändring av företeelsetyper i NVDB för att bättre kunna stödja kommuners och Lantmäteriets verksamhet. Med utbyte av Väg och Järnväg avses utbyte av geodata kring vägnät, järnvägsnät samt nätanknutna företeelser. Detta förslag riktar sig i första hand till Trafikverket men även till övriga dataproducenter, systemleverantörer och systemutvecklare som ansvarar för att utbyta datamängder om vägar och järnvägar.

9 7 (72) Termer och beskrivningar För detta dokument har inga specifika termer identifierats som inte är namn på objekttyper eller attribut utan detta kapitel innehåller endast generella termer för modellering av geografisk information inom. Värden i kodlistor kan anses vara termer men då de beskrivs och exemplifieras med figurer i kapitel 5 så utelämnas de här. Källa om annan än anges inom parentes efter definition. UML-specifika termer och vissa modelleringstekniska termer beskrivs i Fel! Hittar nte referenskälla. Generella termer Term Abstrakt objekttyp Abstraktion Applikationsschema Association Attribut Attributtyp Baskarta Baskarteområde 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 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 Exempel: Maxhöjd vid insamlingstillfälle Digitala data (storskaliga) som redovisar grundläggande förhållanden ovan och ofta under 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.

10 8 (72) Begreppsmodell Datamodell Datatyp Egenskap Företeelse Företeelsetyp Informationsmodell Kvalitetsmått (engelska, quality measure) Kvalitetsparameter (engelska, quality element) Vanligtvis grafisk beskrivning av uppträdande hos en avgränsad del av verkligheten utifrån ett visst syfte 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 Ej samma sak som stereotypen <<DataType>> i grafiska modelleringsnotationer Exempel: Textsträng Heltal Decimaltal Sanningstyp (Ja/Nej) Inneboende karakteristik hos en företeelse som kan användas för att beskriva företeelsen och/eller särskilja en företeelse från en annan 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 Kommentar: Inom NVDB används termen företeelsetyp för ett element motsvarade det som i benämns objekttyp. Exempel: Träd En systemoberoende modell som beskriver, strukturerar och definierar den information som ska hanteras och vilka verksamhetsregler som ska gälla. Struktur för informationsinnehåll beskriven som objekttyper, sambandstyper och attributtyper. Föregås oftast av en begreppsmodell, för aktuellt verksamhets- och tillämpningsområde. 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

11 9 (72) Källa: HMK Ordlista Kvalitetstema (engelska, data quality element category) Metadata Objekt Objekttyp Objekttypskatalog Värdelista övergripande indelning av geodatakvalitetens olika aspekter (aktualitet, fullständighet, användbarhet etc.); delas in i kvalitetsparameterar, som mäts med kvalitetsmått Källa: HMK Ordlista 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. 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 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: Kodlista Värdemängd Värdeförråd Förkortningar BIS DPS EPSG GML HMK Baninformationssystem Sverige Dataproduktspecifikation European Petroleum Survey Group Geographic Markup Language Handbok i mät- och kartfrågor. Samverkan mellan Lantmäteriet och andra myndigheter, främst

12 10 (72) NVDB NJDB OGC kommuner och Trafikverket, som arbetar för enhetlig och standardiserad insamling av geodata i form av handböcker. Se HMK:s hemsida sök på HMK. Nationell Väg Databas Se Nationell järnvägsdatabas Se The Open Geospatial Consortium RH 2000 Rikets Höjdsystem 2000 SWEREF 99 SWEREF 99 TM SWEREF 99 dd mm UUID XML 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 Kommentar: degree degree minute minute Universal Unique IDentifier extensible Markup Language 2.2 Information om befintliga datamängder om vägar och järnvägar Namn - Förkortning - Beskrivning av innehåll Utsträckning i tid och rum Syfte Detta förslag innehåller några utvalda och prioriterade företeelsetyper och hur tror att de bäst skulle kunna utformas för att stödja kommuners och Lantmäteriets med flera verksamheter. Hela Sverige Genom att ta fram tydligare klassificeringar av vägar samt utöka möjligheterna att länka vägnätsanknutna företeelsetyper till framförallt adresser så skapas förutsättningar för att: Skapa mer nationellt enhetliga geodata om vägar och järnvägar.

13 11 (72) Förenkla kommuners verksamhet Förenkla Lantmäteriets verksamhet Underlätta navigering och ruttplanering Datakällor Lantmäteriet, kommunerna och Trafikverket. Produktionsprocesser Trafikverkets produktionsprocess kan beskrivas med tre delprocesser: Ta emot Justera och komplettera Lagra I delprocess Ta emot loggas leveransen och kontroll av innehållet sker på en övergripande nivå. Justera och komplettera innebär en mer noggrann kontroll av innehållet. Smärre brister kan justeras direkt medan större ofta kräver kontakt med dataleverantören. I båda delprocesserna kan dataleveransen bedömas så bristfällig att omleverans begärs. I sista delprocessen Lagra sker den slutliga lagringen i NVDB. Lagrad data blir tillgänglig för användning dagen efter att lagring skett. Kommunernas produktionsprocess inleds av att ett beslut av ny/förändring av väg äger rum. I projektet ingår ibland en relationsritning som kan utgöra underlag för ajourföring av geometrier i NVDB. Om projektet inte innefattar en relationsritning så behöver den informationen nå kommunens mätenhet som då mäter in förändringen. I det fallet blir kommunens baskarta underlaget för ajourföring av geometrier i NVDB. När geometrin är inlagd i NVDB så återstår uppdatering av företeelserna. Ajourföring av företeelser kan endast ske när trafikverket godkänt geometrin. Den ajourföringen kan t ex ske genom trafikverkets webbgränssnitt NVDB på webb. Lantmäteriets produktionsprocess sker genom periodisk ajourhållning med hjälp av flygbildstolkning för att hitta förändringar. Förändringar detekteras även genom avvikelserapportering från externa användare av Lantmäteriets produkter. Lantmäteriet skickar förändrade väggeometrier till Trafikverket löpande. För att fånga upp de förändringar som skett i NVDB genom andra aktörer hämtar Lantmäteriet förändringsdata från NVDB varje månad. Ajourhållning När en ny dataprodukt antagits i NVDB sker först en initial insamling. Detta för att få upp datainnehållet till en nivå

14 12 (72) varifrån den mer löpande ajourhållningen sen tar vid. Hur detta ska ske mer i detalj beslutas i varje enskilt fall. För att säkra ajourhållningen tecknar Trafikverket en form av avtal med varje dataleverantör där det framgår vad man kommit överens om kring dataleveranser till NVDB. Dessa avtal tecknas inte för Trafikverkets egna dataleveranser till NVDB. De styrs genom interna kravdokument. För att säkerställa datakvalitet i NVDB finns krav på när data ska senast ska levereras. Kraven är för närvarande högre för det statliga vägnätet än för det kommunala och enskilda. Kraven framgår dels av Trafikverksinterna dokument och dels av de dataproduktspecifikationer som finns för varje dataprodukt. Kommunerna ajourför geometrier för kommunens vägar samt enskilda vägar inom tätort/baskarteområde samt ett antal företeelser för dessa geometrier. I de verktyg som idag finns för att ajourföra kan man inte ajourföra både geometrier och företeelser. Man behöver alltså fler verktyg för att uppdatera en länk och alla dess företeelser. I regel är fler enheter på kommunen inblandade i ajourföringen. Ajourhållning avser framförallt geodata men även ajourhållning av specifikationer och modeller för data behövs i större utsträckning än vad som förekommer idag, till exempel genom borttagande av ej längre aktuella eller ajourhållna företeelsetyper. Lantmäteriet ajourhåller geometrier för vägar utanför tätorter med hjälp av flygbildstolkning. Alla förändringar skickas till NVDB som läggar in alla betydande geometriförändringar. 3 Detta förlags omfattningar Förutom den samlade bilden av alla inbladade intressenters krav och behov har 3 delomfattningar identifierats som beskrivs nedan. Dessa utgår alla från de enskilda intressenternas verksamheters behov och krav. 3.1 Omfattning A Alla omfattningar Identifiering av omfattning Hierarkisk nivå Väg och Järnväg 005 Datamängd Namn på hierarkisk nivå Väg och Järnväg

15 13 (72) Beskrivning av hierarkisk nivå Vägnät och järnvägsnät samt nätanknutna företeelsetyper oavsett detaljeringsnivå. Utsträckning Data förekommer över hela Sverige. Coverages - Ingående omfattningar Delomfattning Väg och Järnväg Nationell Delomfattning Väg och Järnväg Kommun Delomfattning Väg och Järnväg Projektering 3.2 Delomfattning B Väg och Järnväg Nationell Identifiering av omfattning Hierarkisk nivå Väg och Järnväg Nationell (Standardnivå 1 enligt HMK) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Väg och Järnväg Nationell Data om vägnät och järnvägsnät samt nätanknutna företeelsetyper utifrån ett nationellt perspektiv. Krav gällande lägesosäkerhet utgår från Standardnivå 2 enligt HMK. Utsträckning Överordnad omfattning Kommentar Data förekommer över hela Sverige. Väg och Järnväg /Hela dataprodukten Trafikverket tillämpar +/- 5 meter som undre gräns idag för att uppdatering data i NVDB vilket inte överensstämmer med krav enligt HMK standardnivå Delomfattning C Väg och Järnväg Kommun Identifiering av omfattning Hierarkisk nivå Väg och Järnväg Kommun (Standardnivå 2 enligt HMK) 005 Datamängd Namn på hierarkisk nivå Väg och Järnväg Kommun

16 14 (72) Beskrivning av hierarkisk nivå Data om vägnät och järnvägsnät samt nätanknutna företeelsetyper utifrån ett kommunalt perspektiv. Krav gällande lägesosäkerhet utgår från Standardnivå 3 enligt HMK. Utsträckning Överordnad omfattning Data förekommer över hela Sverige. Väg och Järnväg /Hela dataprodukten 3.4 Delomfattning D Väg och Järnväg Projektering Identifiering av omfattning Hierarkisk nivå Väg och Järnväg Projektering (Standardnivå 3 enligt HMK) 005 Datamängd Namn på hierarkisk nivå Beskrivning av hierarkisk nivå Väg och Järnväg Projektering Data om vägnät och järnvägsnät samt nätanknutna företeelsetyper utifrån ett projekteringsperspektiv. Krav gällande lägesosäkerhet utgår från Standardnivå 4 enligt HMK. Utsträckning Överordnad omfattning Data förekommer över hela Sverige. Väg och Järnväg /Hela dataprodukten 4 Identifiering av detta dokument Titel Alternativ titel Väg och Järnväg, Förslag till förändring av företeelsetyper i NVDB Väg och Järnväg Produktnummer - Versionsnummer 0.5 Sammanfattning Syfte Detta förslag innehåller några utvalda och prioriterade företeelsetyper och hur tror att de bäst skulle kunna utformas för att stödja kommuners och Lantmäteriets med flera verksamheter. Data om vägar och järnvägar behövs som underlag vid detaljplanering samt analyser på både lokal och regional nivå

17 15 (72) av till exempel trafikflöden, buller med mera. Data om vägar och järnvägar används också vid ruttplanering på lokal och regional nivå till exempel för transporter av varor, hemtjänst, skolskjuts och skolval samt för blåljusaktörer. 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. Enhetliga data om vägar och järnvägar kan också bidra till att annan myndighetsutövning underlättas. Ämnesområde Typ av geometrisk representation 018 Transporter Ämnesområde ur den nationella metadataprofilen (ref). 001 Vektor Ur den nationella metadataprofilen (ref). Rumslig upplösning - Geografisk utsträckning Data om vägar och järnvägar förekommer över hela Sverige. Kompletterande information - 5 Datainnehåll och struktur 5.1 Beskrivande text I kapitlet Informationsmodell nedan beskrivs i detalj alla ingående objekttyper, attribut och associationer som ingår i förslaget. 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 dataproduktens innehåll är grafisk dokumenterat är med en informationsmodell. Informationsmodellen är dokumenterad med UML ( och är framförallt avsedd att vara läsbar för människor och är därför i vissa avseenden inte konsekvent eller tekniskt korrekt modellerad. Se bilaga B för information om hur UML har använts i. 5.2 Informationsmodell och objekttypskatalog Informationsmodellen är uppdelad i flera figurer för att belysa de olika delarna av modellen. I avgränsandet av innehållet i detta förslag så har företeelser identifierats som detta förslags objekttyper har beroenden eller associationer till men som inte omfattas

18 16 (72) av detta förslag. En del av dessa företeelser omfattas av andra dataprodukter som utvecklas inom se I objekttypskatalogen ingår endast objekttyper ur detta förslag och ej objekttyper från annan modell/standard även om dessa i vissa fall syns i figurer med UML-diagram. Färgsättning av objekttyper i diagram görs enligt Figur 2 För ytterligare information om hur informationsmodellerna i har skapats och hur namnsättning skett se class Färgsättning 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 DPS (Se kapitel 7.1, Nr. 1). Krav 2. Informationsmodellens angivelser om multiplicitet ska följas för datamängder enligt denna DPS (Se kapitel 7.1, Nr. 1). Krav 3. Krav 4. Endast värden från kodlistor ska användas för attribut vars typ är en kodlista (Se kapitel 7.1, Nr. 2). Kodlistor är utökningsbara. Utökad kodlista ska tillhandahållas av ansvarig part. 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.

19 17 (72) Rekommendation 1. Gemensamma kodlistor ska förvaltas av Lantmäteriet Beroenden till andra dataprodukter class VJ_Paketberoenden SG_Markanv ändningmarktäcke SG_GemensammaKlasser (from SvenskGeoprocess) SG_MarkDetaljer (from SvenskGeoprocess) (from SvenskGeoprocess) SG_VägJärnv äg SS637004:2006 (from SvenskaStandarder) SG_LaserdataHöjdmodell (from SvenskGeoprocess) Transport Networks (from SvenskGeoprocess) (from Annex I) SG_Adress (from SvenskGeoprocess) Figur 3. Paketdiagram visande dataprodukten Väg och Järnvägs beroenden till andra dataprodukter inom samt nationella och internationella standarder/specifikationer. Dataprodukten Väg och Järnväg utnyttjar andra standarder och modeller. Detta illustreras genom paketberoenden (Figur 3). Dataprodukten Väg och Järnvägs objekttyper har identifierats ha relationer till objekttyper som återfinns i andra dataprodukter. Fel! Hittar inte referenskälla. illustrerar dessa relationer som beroenden från dataprodukten Väg och Järnväg till andra dataprodukter och standarder Gemensamma objekttyper För att skapa enhetlighet bland de DPS:er som tas fram inom har en uppsättning gemensamma objekttyper skapats som kan användas av alla DPS:er. 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 DPS:er 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 5) som kommer från Inspire och består av en namnrymd (namespace) och

20 18 (72) ett id (localid) som tillsammans ger ett unikt id vilket förklaras djupare längre ner i detta kapitel. För nationelltid ska namespace inte peka ut en organisation utan en datamängd enligt en viss specifikation. För verksamhetsid ska namespace peka ut en organisation men kan även peka ut en viss datamängd som förvaltas av organisationen. 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 kunna använda samma geometri som representerar båda objekten kan associationen representerarsammaföreteelse användas. class SG_Basklass SG_GemensammaKlasser::SG_BasKlass + aktualitet: DateTime +representerarsammaföreteelse 0..* + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + id: SG_Id [1..2] «union» SG_GemensammaKlasser:: SG_Id + nationelltid: Identifier + verksamhetsid: Identifier «DataType» SG_GemensammaKlasser:: SG_ExternReferens + id: CharacterString Figur 4. SG_BasKlass class Inspire_Id «datatype» Base Types::Identifier + localid :CharacterString + namespace :CharacterString «lifecycleinfo, voidable» + versionid :CharacterString [0..1]

21 19 (72) Figur 5. Inspires identifierare, Identifier Krav 7. Alla objekt i en datamängd enligt denna DPS ska ha en identifierare (Id) (Se kapitel 7.1, Nr. 1). Krav 8 Då endast en identifierare anges skall den vara av typen nationellid 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). 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 DPS 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. 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.

22 20 (72) Rekommendation 3. Attributet beginlifespanversion ska finnas för samtliga objekt i datamängd enligt denna DPS 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 DPS 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 Identitet [1..2] SG_Id beginlifespanversion endlifespanversion aktualitet externreferens Datum då objekt först skapades i datamängd. Datum från när objekt inte längre ingår i datamängd. Datum då objektet senast befanns vara korrekt. Referens till annan objekttyp i eller utanför. [0..1] DateTime [0..1] DateTime [1] DateTime [0..*] SG_ExternReferens Datatyper SG_Id Identifierare Attribut Beskrivning Multiplicitet Datatyp nationelltid verksamhetsid Nationell identiferare Kommentar: namespace pekar ut dataprodukt, ej ansvarig organisation Lokal identifierare skapad utifrån specifika verksamheters behov Kommentar: namespace pekar ut ansvarig organisation, ej dataprodukt, [1..1] Identifier [1..1] Identifier SG_ExternReferens Referens till annat objekt i eller utanför. Attribut Beskrivning Multiplicitet Datatyp id Identifierare för externt objekt som refereras till. [1] CharachterString

23 21 (72) Associationer representerarsamma- Företeelse Relation mellan olika objekt i olika modeller som representerar samma verkliga företeelse. Multiplicitet 0..* Geometrityper För de dataprodukter som specificeras av 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. class SG_Geometri SG_GemensammaKlasser::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] SG_GemensammaKlasser:: SG_Punkt + punkt: GM_Point + ärcentroid: Boolean SG_GemensammaKlasser:: SG_Yta + yta: GM_MultiSurface SG_GemensammaKlasser:: SG_Kropp + kropp: GM_Solid SG_GemensammaKlasser::SG_Linje + linje: GM_MultiCurve + typavlinje: SG_TypAvLinje = AnnanLinje + /kartografiskrepresentation: SG_TypAvKartografiskRepresentation [0..*] + kantsten: Boolean [0..1] «codelist» SG_GemensammaKlasser:: SG_TypAv Linje + Kantlinje + Mittlinje + AnnanLinje «codelist» SG_GemensammaKlasser:: SG_TypAvKartografiskRepresentation Figur 6. geometrityper

24 22 (72) 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 (Figur 7) för en enskild geometri samt vilken metod som har använts för att fastställa lägesosäkerheten. class SG_Lägesosäkerhet «DataType» SG_GemensammaKlasser:: SG_LägesOsäkerhet + lägesosäkerhet: DQ_PositionalAccuracy + mätmetod: CharacterString Figur 7. Lägesosäkerhet 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:

25 23 (72) Kantlinje, en linje som används för att beskriva ytterkant på en företeelse. Till exempel kan ett dike representeras av två kantlinjer. Mittlinje, en linje som representerar en utsträckt företeelses mitt. Till exempel så kan ett dike i tillägg till två kantlinjer även ha en mittlinje. Annan linje, alla övriga typer av linjer. Till exempel kan man låta en linje representera ett mindre vattendrag i en småskalig presentation oavsett om den avser vattendragets mitt eller kant. Då man inte hanterar ytor utan linjer som geometrisk representation för ytutbredda företeelser i verkligheten så förekommer de ofta tillsammans med en centroid (SG_Punkt med attributet ärcentroid=true) och topologier för att avgränsa en företeelses utbredning. Centroiden bär uppgifter om ytan som avgränsas av linjerna Till exempel så begränsas en kvadrat av fyra linjer. 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. I det fallet saknas kopplingen mellan en centroid/ytan. Attributet kartografiskrepresentation på objekttypen SG_Linje ger möjlighet att beskriva hur en linje är tänkt att representeras kartografiskt med kodlistan SG_TypAvKartografiskRepresentation. SG_TypAvKartografiskRepresentation kommer att implementeras olika för olika dataprodukter utifrån de behov som respektive dataprodukt representerar. class SG_GeometriMetadata «DataType» SG_GemensammaKlasser::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] + mätlägehögstapunkt: Boolean [0..1] + endlifespanversion: DateTime [0..1] «codelist» SG_GemensammaKlasser:: SG_InmätningsLäge + Enligt SGP mätningsanvisningar + Okänt + Marknivå +... Figur 9. Geometrimetadata 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.

26 24 (72) 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 men samtidigt belysa att inmätningsregler 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. 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. För att tydligt ange om det är högsta punkten på en företeelse som har mätts in så ska attributet mätlägehögstapunkt anges. Attributet är av typen Boolean vilket innebär att det kan anta värdena True eler False, där True innebär att det är företeelsens högsta punkt som mätts in och False att det är läget på marken som mätts in. Exempel: Om man har mätt in toppen på en mur skall mätlägehögstapunkt sättas till True 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 SG_Punkt Endimensionell geometri som beskriver en punkt Attribut Beskrivning Multiplicitet Datatyp

27 25 (72) punkt Geometri [1..1] GM_Point SG_Linje Linjegeometri Attribut Beskrivning Multiplicitet Datatyp linje Geometri [1..1] GM_MultiCurve typavlinje kartografiskrepresentation Kategorisering av linjegeometri utifrån användningssyfte Kommentar: Standardval är AnnanLinje. Beskrivning av hur en linje är tänkt att representeras kartografiskt. [1..1] SG_TypAvLinje [0..1] SG_TypAvKartografisk- Representation 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 upptas i datamängd Kommentar: Avser vanligen det datum då ett objekt lagras i en databas men kan också [0..1] DateTime

28 26 (72) osäkertläge osäkertlägeanledning mätlägehögstapunkt 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. Talar om ifall ett objekt är inmätt på dess högsta punkt Kommentar: "True" = inmätt på högsta punkten, "False" = inmätt på marken Datum då objekt ersatts av annat objekt i datamängd. 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 [1..1] Boolean [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 Geometrins standardosäkerhet Metod för fastställning av geometrins läge. [1..1] DQ_PositionalAccuracy [1..1] CharacterString 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 SG_typAvKartografisk- Representation Beskrivning av hur en linje är tänkt att representeras kartografiskt. Kommentar: Kodlistan kommer att variera i olika dataprodukter och hur den ska implementeras beskrivs av respektive dataproduktspecifikation. SG_InmätningsLäge Beskrivning av hur en geometri är inmätt Kommentar: Kodlistan kommer att variera för olika dataprodukter och hur den ska implementeras beskrivs av respektive dataproduktspecifikation. Startvärde ("default") är Enligt SGP mätningsanvisning.

29 27 (72) Värden Beskrivning Enligt SGP mätningsanvisning Marknivå Okänt Företeelsen som geometri representerar är inmätt enligt mätningsanvisningar. Företeelsen som geometri representerar är inmätt i marknivå. Företeelsen som geometri representerar är inmätt på ett okänt sätt. Höjd och 3D Efterfrågan på höjddata 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 DPS. 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 DPS för Laserdata och Höjdmodell. För mer information om punkthöjder som referenshöjder se DPS Stompunkter. Det rekommenderas att inmätning av företeelser görs på deras högsta punkt (att attributet mätlägehögstapunkt på SG_GeometriMetadata sätts till True ) då läget på marken oftast kan fås av en höjdmodell. Detta förfarande medför att man i större utsträckning kan använda geometrin i frågeställningar som kräver 3D-representation av företeelser. Rekommendation 5 Företeelsers höjd ska mätas in på sin högsta punkt. SG_Datamängd För att visa hur datamängder sätts ihop av objekttyper i teman inom samt 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)

30 28 (72) 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 i form av aktualitet samt information om datamängden är sekretessreglerad eller inte Objekttyper 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 datamängd Datamängder med data om vägar och järnvägar (Figur 11) sätts samman av minst en men vanligen flera väganknutna företeelsetyper respektive järnvägsanknutna företeelsetyper. SG_VägFöreteelseTyp och SG_JärnvägFöreteelseTyp är abstrakta klasser som behöver specialiseras i konkreta företeelsetyper för att kunna användas. De fungerar primärt som sammanhållande för alla specialiseringar och bär möjligheten att beskriva en företeelsetyp med hjälp av en (frivillig) geometri.

31 29 (72) class SG_VägJärnvägDatamängd «DataSet» SG_GemensammaKlasser:: SG_Datamängd + aktualitet: DateTime + sekretessreglerad: Boolean = false +metadata Metadata entity set information::md_metadata SG_VägDatamängd SG_JärnvägDatamängd 1..* SG_BasKlass SG_VägFöreteelseTyp + geometri: SG_Geometri [0..*] 1..* SG_BasKlass SG_JärnvägFöreteelseTyp + geometri: SG_Geometri [0..*] Figur 11. Vägdatamängd samt Järnvägdatamängd och metadata för vägdatamängd samt metadata för järnvägdatamängd Objekttyper SG_VägDatamängd Sammansättning av en datamängd beskrivande väg. SG_JärnvägDatamängd Sammansättning av en datamängd beskrivande järnväg. SG_VägFöreteelseTyp Sammanhållande supertyp för alla vägnätsanknutna företeelsetyper. Attribut Beskrivning Multiplicitet Datatyp geometri Geometri för vägnätsaknuten företeelsetyp. [0..*] SG_Geometri SG_JärnvägFöreteelse- Typ Sammanhållande supertyp för alla järnvägnätsanknutna företeelsetyper. Attribut Beskrivning Multiplicitet Datatyp geometri Geometri för järnvägnätsanknuten företeelsetyp. [0..*] SG_Geometri

32 30 (72) Trafiknät class SG_Trafiknät SG_VägJärnv äginformation:: TrafikNät +trafiknät 1..* +trafiknät 1..* +länk 1..* +nod 2..* SG_VägJärnv äginformation::länk SG_VägJärnv äginformation::nod NVDB:: NVDB_VägNät BIS:: NJDB_Järnv ägsnät Figur 12. Trafiknät Figur 12 visar en generell bild över trafiknät. Ett TrafikNät består av minst en länk och minst två noder. tar inte fram någon egen nätverksmodell utan använder den etablerade modellen från SS Väg- och järnvägsnät. För mer information om länk-nod-modellen för nätverk refereras till SS eller DPS Det svenska vägnätet ( VägNät och JärnvägsNät hämtas från NVDB respektive i dagsläget NJDB/BIS. I NVDB förekommer tre typer av vägnät: Bilvägnät, Cykelvägnät och gångvägnät.

33 31 (72) Nätanknutna företeelsetyper class SG_NätanknutnaFöreteelsetyper NVDB:: NVDB_VägNät BIS:: NJDB_Järnv ägsnät +vägnät 1..* +järnvägsnät 1..* +anknutenföreteelsetyp 0..* SG_BasKlass SG_VägJärnvägInformation:: SG_VägFöreteelseTyp + geometri: SG_Geometri [0..*] +anknutenföreteelsetyp 0..* SG_BasKlass SG_VägJärnvägInformation:: SG_JärnvägFöreteelseTyp + geometri: SG_Geometri [0..*] Figur 13. Nätanknutna företeelsetyper Figur 13Figur 13 visar en principiell bild över hur de abstrakta supertyperna SG_Väg- FöreteelseTyp och SG_JärnvägFöreteelseTyp är kopplade till ett vägnät. Realiseringen av detta kommer att ske enligt SS

34 32 (72) Vägnätsanknutna företeelsetyper class SG_VägNätsanknutnaFöreteelsetyper SG_GemensammaKlasser:: SG_BasKlass +representerarsammaföreteelse 0..* SG_VägJärnvägInformation:: SG_VägFöreteelseTyp SG_VägJärnv äginformation:: SG_VägStatus SG_VägJärnv äginformation:: SG_Uppfart SG_VägJärnv äginformation:: SG_KörfältsBeskriv ning SG_VägJärnv äginformation:: SG_Öv rigled SG_VägJärnv äginformation:: SG_VägNamn SG_VägJärnv äginformation:: SG_VägKartografi SG_VägJärnv äginformation:: SG_MötesfriVäg SG_VägJärnv äginformation:: SG_Belysning Figur 14. Vägnätsanknutna företeelsetyper Till ett vägnät kan olika vägnätsanknutna företeelsetyper knytas (Figur 14). De vägnätsanknutna företeelsetyperna kan vara antingen linjeföreteelser längs en sträcka av vägnätet eller punktföreteelser som bara anknyts till vägnätet i en punkt. De vägnätsanknutna företeelsetyper som beskrivs i denna dataproduktspecifikation är en komplettering och/eller en utökning av de vägnätsanknutna företeelsetyper som beskrivs av Trafikverkets dataproduktspecifikationer ( sök på dataproduktspecifikation) och som ingår i NVDB. Företeelsetyperna beskrivna i detta dokument är specialiseringar av SG_BasKlass ( ) vilket innebär att de ärver egenskaperna från SG_BasKlass.

35 33 (72) SG_VägStatus class SG_VägStatus SG_VägFöreteelseTyp SG_VägJärnv äginformation:: SG_VägStatus + vägstatustyp: SG_VägStatusTyp «codelist» SG_VägJärnv äginformation:: SG_VägStatusTyp + Planerad + I drift + Påbörjad + Avvecklad + Destruerad Figur 15. Vägstatus I Figur 14Figur 15. Vägstatus beskrivs ett sätt att tillsammans med startdatum på en väglänk i NVDB ge information om en väg befinner sig i planeringsstadium, är påbörjad etc. Objekttyper SG_VägStatus Anger status för en väg avseende dess tillblivande, drift eller avveckling. Attribut Beskrivning Multiplicitet Datatyp vägstatustyp Benämning på vägens status. [1] SG_VägStatusTyp Kodlistor SG_VägStatusTyp Stadier i en vägs livscykel. Attribut Beskrivning Multiplicitet Datatyp Planerad Påbörjad I drift Avvecklad Destruerad

36 34 (72) SG_VägNamn class SG_Vägnamn SG_VägJärnv äginformation::sg_vägnamn + namn: CharacterString + namntyp: SG_VägNamnTyp + adressbildande: Boolean + namnsättare: SG_NamnSättareTyp + namnsättandeorganisation: RelatedParty «codelist» SG_VägJärnv äginformation:: SG_VägNamnTyp + Fastställt namn + Övrigt namn + Populärnamn «codelist» SG_VägJärnv äginformation:: SG_NamnSättareTyp SG_AdressInformation::SG_Adressområde + Statlig + Kommunal + Skoglig + Enskild + Övrig Figur 16. Vägnamn Figur 16 visar SG_VägNamn. SG_VägNamn kan vara av olika typer som anges av attributet namntyp och kodlistan SG_VägNamnTyp. Attributet adressbildande anger om vägnamnet är adressbildande med datatypen Boolean, True = adressbildande, False = icke adressbildande. Det finns dessutom möjlighet att via en instansiering av den generella associationen representerarsammaföreteelse i SG_Basklass ( ) koppla ett SG_VägNamn till ett SG_Adressområde ur DPS Adress. Attributet namnsättare anger vilken organisation som har satt namnet på vägen. SG_Vägnamn är en linjeföreteelsetyp som sträcker sig längs en eller flera alternativt längs delar av länkar i ett vägnät. SG_Vägnamn är ett konceptuellt förslag på hur en teknisk lösning skulle kunna se ut och tar inte hänsyn till eventuella frågor om vem (organisation, system etc.) som ska äga en koppling mellan vägnamn och adresser. Objekttyper SG_VägNamn Namn på en väg Attribut Beskrivning Multiplicitet Datatyp namn [1] CharacterString namntyp [1] SG_VägNamnTyp adressbildande [1] Boolean namnsättare [1] SG_NamnSättareTyp

37 35 (72) namnsättandeorganisation [1] RelatedParty Kodlistor SG_VägNamnTyp Typ av namn på en väg. Attribut Beskrivning Multiplicitet Datatyp Fastställt namn Övrigt namn Populärnamn SG_NamnSättareTyp Typ av organisation som satt namn på väg Attribut Beskrivning Multiplicitet Datatyp Statlig Kommunal Skoglig Enskild Övrig SG_Uppfart class VJ_Uppfart SG_VägJärnv äginformation: :SG_Uppfart 0..* SG_AdressInformation::SG_Adressplats Figur 17. Uppfart Figur 17 visar SG_Uppfart. En uppfart saknar egen länk i nätverket och är en punktföreteelsetyp. SG_Uppfart har ingen nod i ett vägnät och representeras i verkligheten

38 36 (72) ofta av en avfasning eller ett hål i kantstenen längs en väg. Det kan också vara en kort belagd infart till en fastighet eller ett område med fastigheter inom vilket ingen väg finns lagrad hos ansvariga aktörer. För att kunna användas av utryckningsfordon kan SG_Uppfart instansiera den generella associationen representerarsammaföreteelse i SG_Basklass ( ) genom en association till en eller flera SG_Adressplats och talar därigenom om vilka adresser som kan nås från uppfarten. Liksom för SG_Vägnamn så är detta bara ett konceptuellt förslag på en teknisk lösning och tar inte hänsyn till eventuella frågor om vem (organisation, system etc.) som ska äga en koppling mellan uppfarter och adressplatser. Objekttyper SG_Uppfart Infartsväg till fastighet eller område som saknar egen väglänk. Kan ha koppling till en eller flera adresser. Attribut Beskrivning Multiplicitet Datatyp Funktionell Vägklass Funktionell Vägklass kan användas som komplement till VägKartografiTyp för att kartografiskt urskilja eller betona vissa vägavsnitt. Trafikverkets dataproduktspecifikation för Funktionell Vägklass är konsekvent däremot är den i vissa avseenden otydlig och användandet av den skulle kunna förenklas bland annat med hjälp av tillämpningsexempel. Trots att flertalet av de funktionella vägklasserna (0-9) kan omsättas, framförallt i storstäder så är de inte konsekvent satta och ur ett nationellt perspektiv kan det vara svårt att jämföra samma funktionella vägklass i olika områden. I Tabell 1 presenteras ett förslag på förtydliganden av de funktionella vägklasserna. Tabell 1. Funktionell Vägklass FVK Sammantagen beskrivning Beskrivning specifikt Statligt Beskrivning specifikt Kommunalt 0 Nätverk på nationell nivå med de Nätverk på nationell nivå viktigaste vägarna. Europavägar. med de viktigaste vägarna. Europavägar. 1 Näst viktigaste vägarna på nationell nivå. Näst viktigaste vägarna på nationell nivå. De viktigaste riksvägarna, såsom De viktigaste riksvägarna, 25, 26, 31, 33, 40, 45, 47, 48, 50, 53, 55, 56, 64 och 70. såsom 25, 26, 31, 33, 40, 45, 47, 48, 50, 53, 55, 56, 64 och Stora statliga vägar. Riksvägar som inte klassificeras under nivå 1. Stora leder i tätort med mestadels planskilda korsningar Stora statliga vägar. Riksvägar som inte klassificeras under nivå 1. Stora leder i tätort med mestadels planskilda korsningar

39 37 (72) 3 Stora statliga vägar. Primära länsvägar. Stora genomfarts-, infarts-leder i tätort med få avbrott i form cirkulationsplatser. Ringleder. 4 Medelstora statliga vägar. Genomfartsleder och större huvudgator genom tätort där man vill leda trafik. 5 Mindre statliga vägar. Sekundära och tertiära länsvägar. Huvudgator i tätort. 6 Uppsamlingsgator och större gator inom tätort, ex.vis där kollektivtrafik leds. Större vägar inom handels/industriområden. Huvudgator i tätort där man inte vill leda trafik genom. Småvägar på landsbygd. Stora statliga vägar. Primära länsvägar. Stora genomfarts-, infarts-leder i tätort med få avbrott i form cirkulationsplatser. Ringleder. Medelstora statliga vägar. Genomfartsleder och större huvudgator genom tätort där man vill leda trafik. Mindre statliga vägar. Sekundära och tertiära länsvägar. Stora genomfarts-, infarts-leder i tätort med få avbrott i form cirkulationsplatser. Ringleder. Genomfartsleder och större huvudgator genom tätort där man vill leda trafik. Huvudgator i tätort. Småvägar på landsbygd. Uppsamlingsgator och större gator inom tätort, ex.vis där kollektivtrafik leds. Större vägar inom handels/industriområden. Huvudgator i tätort där man inte vill leda trafik genom. 7 Gator (Lokalgator). Gator (Lokalgator). 8 Gågator. Leveransgator där genomfart kan förekomma. Infarter/Utfarter som leder trafik genom Parkeringsområden. Uppfartsvägar på landsbygd där genomfart kan förekomma. Gågator. Leveransgator där genomfart kan förekomma. Infarter/Utfarter som leder trafik genom Parkeringsområden. 9 Kvartersvägar. Parkeringsgator. Kvartersvägar. Parkeringsgator. Vägar inom parkytor. Figur 18 till Figur 23 innehåller exempel på hur Funktionell Vägklass bör användas enskilt och tillsammans med andra företeelsetyper.

40 38 (72) Figur 18. Exempel kombination av Vägkartografityp och FVK. Huvudgata förekommer med 3 olika stilsättningar beroende på Funktionell Vägklass.

41 39 (72) Figur 19. Exempel kombination av flera företeelser för kartografi. Stilsättning är beroende av en kombination flera företeelser, Vägkategori, Vägkartografityp, Funktionell Vägklass, m.m.

42 40 (72) Figur 20. Exempel, parkeringsgata och Funktionell Vägklass. Parkeringsgator, Infart/Utfart klassificeras som lägsta möjliga nivå, d.v.s. Funktionell Vägklass 9. I enstaka fall kan man tänka sig att delar av dessa vägavsnitt kan höjas till Funktionell Vägklass 8. Figur 21. Exempel Kvartersväg och Funktionell Vägklass. Parkeringsgator, Infart/Utfart klassificeras som lägsta möjliga nivå, d.v.s. Funktionell Vägklass 9. I detta exempel visas ett av de enstaka fall där kan man tänka sig att delar av dessa vägavsnitt kan höjas till Funktionell Vägklass.

43 41 (72) Figur 22. Exempel Funktionell Vägklass 2-4. Figur 23. Exempel Funktionell Vägklass 4-7.

44 42 (72) SG_VägKartografi class SG_VägKartografi SG_VägJärnv äginformation:: SG_VägKartografi + vägtyp: SG_VägkartografiTyp «codelist» SG_VägJärnv äginformation:: SG_VägkartografiTyp Figur 24. VägKartografi SG_VägKartografi (Figur 24) är ett förslag till ny klassificering av vägar som bättre svarar upp mot kommuners och Lantmäteriets behov än befintliga företeelsetypen Vägtyp i NVDB idag. Klassificeringen utgår från typerna i kodlistan SG_VägKartografi- Typ. Tabell 2. SG_VägKartografiTyp Kategori Typ Kort Beskrivning Generell Motorväg Väg som motsvarar trafikregler för motorväg Generell Motortrafikled Väg som motsvarar trafikregler för motortrafikled Generell Avfart/Påfart Avfarter och påfarter tillhörande motorvägar. Landsbygd Landsväg stor Utanför tätort, motsvarar vägbredd >7 Landsbygd Landsväg mellan Utanför tätort, motsvarar vägbredd 5-7 Landsbygd Landsväg mindre Utanför tätort, Vägbredd, motsvarar vägbredd <5 Landsbygd Småväg Landsbygd Småväg sämre Landsbygd Traktorväg Landsbygd Uppfartsväg Oftast enskilda vägar, bra som bilväg Oftast enskilda vägar, sämre som bilväg, skogsbilväg Väg är i regel framkomlig för jordbrukstraktor. Väg till hus, bebyggelse från Landsväg, Småväg. Normalt enskild väghållare.

45 43 (72) Tätort Genomfartsgata Leder, Genomfartsvägar, Ringleder, Infarter städer/samhällen. Tätort Huvudgata Större Gata inom tätort Tätort Uppsamlingsgata Matargata. Tätort Gata Lokalgata/Tätortsgata. Tätort Kvartersgata Gränd/kvartersväg Tätort Parkeringsgata Väg inom eller genom parkeringsplats Tätort Infart/Utfart Vägavsnitt som leder in till parkering, kvartersgator, Tätort Leveransgata Väg fram till industrilokaler, varuintag. Adressplats kan förekomma. Tätort Bussgata Längre sträckningar, likväl korta genvägar för buss. Genom bostadsområden. Nedan följer en genomgång av respektive typ i SG_VägKartografiTyp. Motorväg Motorväg enligt trafikförordning. Motortrafikled Motortrafikled enligt trafikförordning.

46 44 (72) Avfart/Påfart Avfarter och påfarter tillhörande motorvägar. Accelerationsfält, retardationsfält. Ramper, större cirkulationsplatser i anslutning till dessa. Mötesfri enkelriktad väg. Landsväg stor Landsväg, genomsnittlig bredd >= 7 m. Har vägnummer. Kan ha skilda körbanor.

47 45 (72) Landsväg mellan Landsväg, genomsnittlig bredd >=5 och <7 m med dubbelriktad trafik. Har vägnummer. Landsväg mindre Mindre landsväg, genomsnittlig bredd < 5 m med dubbelriktad trafik. Småväg Mindre bilväg med körbanebredd på minst 3,5 m och som är framkomlig för lastbil med släp (24 m) utom vid tjällossning eller under ihållande regnperioder. Vägen bör vara dikad och vägbanan normalt i sådant skick att personbil kan framföras året runt. Saknar vägnummer.

48 46 (72) Småväg sämre Mindre bilväg som har anlagd vägbana, men som inte uppfyller kraven för småväg. På bäriga marker med god dräneringsförmåga kan egentlig vägkropp saknas. Vissa vägar inom klassen är framkomliga för lastbil med kort släp (18 m), övriga vägar för lastbil utan släp i huvudsak när vägen är tjälad. Personbilstrafik är normalt möjlig utom vid tjällossning eller under ihållande regnperioder. Traktorväg Väg som normalt saknar vägkropp men har iordningställd vägbana av varaktig beskaffenhet. Vägen är i regel framkomlig för jordbrukstraktor med släp. Kan inkluderas om väg: Har en längd som överstiger 500 meter. Leder till bebyggelse eller odlad mark (minimilängd 100 meterleder till annat specifikt mål (minimilängd 250 meter). Sammanbinder vägar. Följer strand. Rekommenderas att inte inkludera, om: Drivningsväg (tillfällig väg som används för att ta fram timmer). Vinterväg (gammal väg som går över sankmarksområden).

49 47 (72) Uppfartsväg Framfartsväg till hus och bebyggelse från Landsväg eller från Småväg. Normalt enskild väghållare. Genomfartsgata Genomfartsled i samlad bebyggelse avsedd för genomgående trafik och som knyter samman det statliga vägnätet. Innefattar även större infarter till tätorter/stad. Ofta benämnda som leder, ringvägar m.m. Oftast ej adress-satt. Huvudgata En större gata inom tätort som har en central betydelse för att binda samman stadsdelar och är ett huvudstråk genom stadsdelar.

50 48 (72) Uppsamlingsgata Större gata och viktigare gatuförbindelse i samlad bebyggelse. Uppsamlingsgata bostadsområde. Uppsamlingsgator kan typiskt leda upp mot Huvudgator, Trafikleder

51 49 (72) Gata Gata i samlad bebyggelse Innefattar även gågator Kvartersgata Mindre väg inom bebyggda områden som endast används för biltrafik vid transporter till och från bostadsfastigheter.

52 50 (72) Parkeringsgata Innefattar all väg-geometri inom parkeringsytor, dels genomfarter inom parkeringsytan, men även detaljerad väg-geometrin som leder fram till parkeringsplatsen. Infart/Utfart Vägavsnitt som leder in till parkering, kvartersväg. Ofta skyltat med Utfart från större parkering. Även kortare anslutningsvägar till fastigheter och byggnader och väg-avsnitt till skafttomter. Syftet med Infart/Utfart är att kartografiskt kunna visualisera endast själva Infarten/Utfarten och inte nödvändigtvis detaljerade geometrier såsom parkeringsgator och kvartersvägar. Dessutom, Gata, Kvartersväg eller parkeringsgata, är inte naturliga begrepp att använda för att beskriva dessa vägavsnitt. Det här är snarare Infart/Utfart. Exempel på Infart/Utfart till fastigheter och byggnader och väg-avsnitt till s.k. skafttomter.

53 51 (72)

54 52 (72) Leveransgata Vägavsnitt fram till industrilokaler, varuintag. Adressplats kan förekomma. Bussgata Väg som endast får användas för busstrafik Objekttyper SG_VägKartografi Typ av väg ur ett kartografiskt perspektiv Attribut Beskrivning Multiplicitet Datatyp vägkartografi Kategorisering av väg för kartografi [1] SG_VägKartografiTyp Kodlistor SG_VägKartografi Typer av vägar för kartografi Attribut Beskrivning Multiplicitet Datatyp

55 53 (72) SG_KörfältsBeskrivning class SG_Körfältsbeskriv ning SG_VägFöreteelseTyp SG_VägJärnv äginformation:: SG_KörfältsBeskriv ning + körfältsindelning: SG_KörfältIndelning + antalkörfält: Integer «codelist» SG_VägJärnv äginformation:: SG_KörfältIndelning + Ingen uppdelning Annan Figur 25. Körfältsbeskrivning Objekttyper SG_KörfältsBeskrivning (Figur 25) är ett förslag på hur man kan separera vägtyp och information om körfälten och smala all information om körfält i en företeelsetyp. SG_KörfältsBeskrivning har attributet antalkörfält som anger antal körfält i heltal samt attributet körfält som tillsammans med kodlistan SG_Körfält anger hur de är konfigurerade. SG_KörfältsBeskrivning Beskrivning av körfält Attribut Beskrivning Multiplicitet Datatyp körfältsindelning Konfigurering av körfält [1] SG_Körfältsindelning antalkörfält Antal körfält [1] Integer Kodlistor SG_KörfältIndelning Indelning av körfält Attribut Beskrivning Multiplicitet Datatyp Ingen uppdelning

56 54 (72) Annan SG_ÖvrigLed class SG_Öv rigled SG_VägFöreteelseTyp SG_VägJärnv äginformation:: SG_Öv rigled + övrigled: SG_ÖvrigLedTyp + vinterled: Boolean + sommarled: Boolean «codelist» SG_VägJärnv äginformation: :SG_Öv rigledtyp + Motionsspår + Elljusspår + Ridväg + Vandringsled + MTB-led + Kanotled + Stig Figur 26. Övrig led SG_ÖvrigLed (Figur 26Figur 26) ger möjlighet att beskriva andra typer av leder än de som i nuläget kan beskrivas i NVDB och som kan vara av intresse ur ett kommunalt perspektiv. SG_Övrig led är en linjeföreteelsetyp. De olika typerna av övriga leder anges av attributet övrigledtyp och kodlistan SG_ÖvrigLedTyp. I tillägg kan man ange om leden är avsedd och rustad för bruk under sommar respektive vinter med attributen vinterled (Ja = True, Nej = False ) och sommarled (Ja = True, Nej = False ). Objekttyper SG_ÖvrigLed Leder av sammansatta väglänkar utifrån ett visst syfte enligt attributet övrigled- Typ. Attribut Beskrivning Multiplicitet Datatyp övrigled Typ av övrig led. [1] SG_ÖvrigLedTyp vinterled Anger om en övrig led är anordnad för att brukas vintertid [1] Boolean

57 55 (72) sommarled Anger om en övrig led är anordnad för att brukas sommartid [1] Boolean Kodlistor SG_ÖvrigLedTyp Olika typer av övriga leder Attribut Beskrivning Multiplicitet Datatyp Motionsspår Elljusspår Ridväg Vandringsled MTB-led Kanotled Se även DPS Hydrografi. Stig SG_Belysning class SG_Belysning SG_VägFöreteelseTyp SG_VägJärnv äginformation: :SG_Belysning Figur 27. Belysning SG_Belysning (Figur 27) är en linjeutbredd företeelsetyp som anger om en sträcka längs en väg är belyst. I NVDB finns endast möjlighet att ange om en GCM-väg är belyst. Om man även vill beskriva/markera belysningsstolparna kan man ange de som Markdetaljer (5.18.1, Belysningsstolpe) enligt DPS Markdetaljer och med attributet externreferens på SG_Belysning (arv från SG_BasKlass) koppla flera belysningstolpar till företeelsetypen SG_Belysning. Objekttyper SG_Belysning Anger om en väg är belyst. Attribut Beskrivning Multiplicitet Datatyp

58 56 (72) SG_MötesfriVäg class SG_MötesfriVäg SG_VägJärnv äginformation:: SG_MötesfriVäg Figur 28. Mötesfri väg Figur 28 är ett förslag till ny företeelsetyp som beskriver om en väg är mötesfri, det vill säga att den är beskaffad med fysisk anordning som förhindrar fordon att mötas då de färdas i motsatt färdriktning. Objekttyper SG_MötesfriVäg Väg med körbanor skilda av fysiskt hinder som förhindrar att fordon kan mötas. Attribut Beskrivning Multiplicitet Datatyp Vägegenskaper som hanteras av andra dataprodukter Många vägegenskaper, framförallt avseende vägars fysiska 2-dimensionella utbredning hanteras av andra dataprodukter. Nedan visas två exempel på detta i form av vägbredd (Figur 29) och slitlager (Figur 30). I båda fallen kan kopplingen mellan de olika objekttyperna enligt olika dataproduktspecifikationer instansiera den generella associationen representerarsammaföreteelse i SG_Basklass ( ).

59 57 (72) class SG_Exempel_Vägbredd SG_GemensammaKlasser::SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime +representerarsammaföreteelse 0..* NVDB::NVDB_Vägbredd notes Vägbanans medelbredd. Definierad avgräsning. SG_Markanv ändningmarktäckeinformation:: SG_Markanv ändning + namnmarkanvändningobjekt: CharacterString [0..1] + markanvändningstyp: SG_MarkanvändningTyp + geometri: SG_Geometri Härledd egenskap ur geometrier för vägars utbredning. som hanteras som Markanvändning. Eller är det ett nominellt attribut som sätts på en väg utifrån t.ex. VägTyp? Figur 29. Exempel Vägbredd class SG_Exempel_Slitlager NVDB::NVDB_VV-Slitlager notes Heltäckande på statlig väg Typ: 1 Bituminös 2 Oljegrus 3 Grus 4 Sten 5 Betong 6 Y1G 7 Förseglad grusväg SG_GemensammaKlasser::SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime +representerarsammaföreteelse 0..* NVDB::NVDB_Slitlager Marktäcke, "Hårdgjorda ytor" mm. SG_Markanv ändningmarktäckeinformation:: SG_Marktäcke + namnmarktäckeobjekt: CharacterString [0..1] + marktäcketyp: SG_MarktäckeTyp + geometri: SG_Geometri Typ: 1. Belagd 2. Grus notes Figur 30. Exempel Slitlager Slitlager uppdelas i NVDB i de nätverksanknutna företeelsetyperna Slitlager och VV_Slitlager men det finns behov av ytterligare förfining för kommunala behov och detta kommer att kunna ske genom en utökning av kodlistan SG_MarktäckeTyp som hanteras av dataprodukten Marktäcke.

60 58 (72) 6 Referenssystem Information om det geodetiska referenssystemet för dataprodukten ska anges, följande referenssystem är tillåtna (se Figur 31 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 3. 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 EPSG:5849 EPSG:5850 EPSG:5851 EPSG:5852 EPSG:5853 EPSG:5854 EPSG:5855 EPSG:5856 EPSG:5857 Benämning SWEREF 99 TM SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF RH 2000 SWEREF 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 31 för en karta med de lokala sweref 99-zonerna.

61 59 (72) Temporalt referenssystem Gregorianska kalendern UTC ±0 UTC +1 normaltid (CET) UTC +2 sommartid (CEST) Referenssystemets omfattning Data enligt alla omfattningar. Samma temporala referenssystem används för alla omfattningar. Krav 15. Datamängder enligt denna specifikation ska tillhandahållas med referenssystem Sweref 99 TM och RH 2000.

62 60 (72) Figur 31. Rekommenderade lokala SWEREF-zoner för kommuner Benämning på plankoordinater Tabell 3. Koordinatsystem Nordlig koordinat (Northing) Östlig koordinat (Easting) SWEREF 99 N E RT 90 x y

63 61 (72) 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 dataproduktspecifikation Stompunkter. 7 Kvalitetskrav 7.1 Datakvalitet 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. Kraven gällande lägesosäkerhet utifrån HMK:s standardnivåer förhåller sig för insamlande organisationer: Trafikverket, Standardnivå = 0 Lantmäteriet, Standardnivå = 1 Kommun, Standardnivå = 2 och 3 Tabell 4. 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. Alla omfattningar 100 % av förekomsterna ska överensstämma med informationsmodellen. (D.13, Id 13). Alla omfattningar 100 % av förekomsterna ska överensstämma med värden i kodlistor. (D.17, Id 17). Alla omfattningar Kraven på lägesosäkerhet följer HMK:s standardnivåer till fullo. Redovisning: RMS i plan (D.49, Id 47) RMS i höjd (D41, Id 39) 8 Metadata Metadata anges på datamängdsnivå enligt den Nationella metadataprofilen (aktuell version).

64 62 (72) För detaljplanering, fastighetsbildning och bygglovshantering är aktualitet en mycket viktig parameter. Aktualitet betraktas i många fall som ett datakvalitetselement, dock inte i ISO Eftersom denna DPS använder ISO för att beskriva datakvalitet hanteras aktualitet som en del av metadata som inte avser datakvalitet. Metadata kan också anges på objektsnivå framförallt när det gäller geometrier (se kapitel ). Metadata kan även sättas på objektsnivå och uttrycks då vanligen som attribut på enskilda objekttyper. Krav 16. Aktualitet för datamängder enligt denna specifikation ska anges. Krav 17. Specifikationsuppfyllelse ska anges i metadata för datamängd enligt denna specifikation. 9 Tillhandahållande Detta kapitel innehåller möjliga alternativ för att tillhandahålla datamängder enligt detta förslag. De rekommenderade formaten och leveransmedierna är de som kommer att kunna testas i samband med framtagandet av förslaget. 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 detta förslag 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. För väg och järnväg är det som kommer att kunna testas inom projektet sådana nätanknutna företeelsetyper som sannolikt ej kommer att implementeras i NVDB. 9.1 Leveransmedium Leveransmedium WFS Medium Geografiska områden och urval av objekttyper utifrån behov (Web Feature Service) Leveransmedium WMS Indelnings-alternativ Indelnings-alternativ Medium Geografiska områden och urval av objekttyper utifrån behov (Web Map Service)

65 63 (72) 9.2 Leveransformat Leveransformat GML Beteckning GML (Geography Markup Language) Version Leverantör och mottagare kommer överens om version Specifikation - Filstruktur - Språk Svenska Teckenuppsättning Utf Leveransformat Bild (för WMS) Beteckning Exempel: Bitmap (rastergrafik) PNG (rastergrafik) Gif (rastergrafik) Jpeg (rastergrafik) Svg (vektorgrafik) Krav 18. WMS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar. Rekommendation 6. WFS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar. 10 Datafångst och ajourhållning 10.1 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.

66 64 (72) 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. I HMK Fotogrammetrisk detaljmätning finns i bilaga C exempel på mätanvisningar som kan utgöra ett stöd för kommunala verksamheter och hur man ska skapa regler för insamling. För data som samlas in, lagras och ajourhålls i NVDB tillhandahåller Trafikverket ett regelverk med olika specifikationer som beskriver hur insamling och leverans av data ska ske. Regelverket består av såväl kravdokument som dokument av mer stödjande karaktär. I regelverket ingår bland annat ett större antal dataproduktspecifikationer, dels för produkter som ingår i NVDB s ansvar och dels för produkter som är mer av Trafikverksinternt intresse. Att skapa korrekta dataleveranser till NVDB är inte helt okomplicerat, även om man tar del av dokumentationen. För att underlätta i detta arbete har Trafikverket därför ett antal medarbetare vars arbetsuppgift är att stödja dataleverantörer. 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 Beskrivning av underhåll och uppdatering av data Underhåll av data med delomfattning B Underhållsfrekvens Omfattning Lantmäteriet ajourför väginformation genom att visuellt söka efter förändringar i vägnätet och eventuella brister i geometriredovisning. Metoden är i huvudsak fotogrametrisk med inmätning i stereomodell, viss inmätning i ortofoto sker vid åtgärdande av felrapporter. Ajourhållningsintervallet med denna metod är 2 årsintervaller i södra Sverige och Norrlands kustland, 4-6 år i Norrlands inland samt norra Svealand och 6-10 år i Norrlands fjälltrakter. Lantmäteriet hämtar uppdateringar från NVDB månadsvis och sänder uppdateringar till NVDB med geometrier och tillkomstuppgifter undantaget kommuners ansvarsområden. Delomfattning B

67 65 (72) 11 Presentationsregler Det är tänkt att dataprodukter som specificeras inom ska kunna visas tillsammans, men hur detta ska ske har ännu inte fastställts. När detta är beslutat kommer presentationsregler att beskrivas gemensamt för alla dataprodukter. 12 Övrig information 13 Referenser DPS Laserdata och höjdmodell () DPS Stompunkter () Mätningsanvisningar () DPS Markanvändning och Marktäcke () DPS Markdetaljer () DPS Adress () DPS Hydrografi () Specifikation för Grundläggande Geografiska Data (GGD - Lantmäteriet) HMK Fotogrammetrisk detaljmätning HMK Geodatakvalitet HMK Ordlista HMK Introduktion Dataproduktspecifikation Det svenska vägnätet, Version 3.0, Trafikverket. SS637004:2006 Geografisk information Väg- och järnvägsnät. SIS/TK 489 N247 Geodata- Nationell metadataprofil DPS och vägledning version SIS-TR 14:2012 Geografisk information Metadata på svenska SIS-TR 40:2012 Geografisk information Tekniskt ramverk Handbok för Dataproduktspecifikation SS-EN ISO 19107:2005 Geographic information Modell för att beskriva rumsliga aspekter SS-EN ISO 19108:2005 Geographic information Modell för att beskriva tidsaspekter SS-EN ISO 19109:2006 Geografisk information 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 :2010 Geographic information Metadata Del 2: Metadata för rasterdata SS-EN ISO 19131:2008 Geographic information Specifikation av datamängder SS-EN ISO 19157:2013 Geografisk information Datakvalitet

68 66 (72) 14 Bilagor 14.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 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 32. Symbol för diagram. Modellerna visualiseras av modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa (Figur 32). class Beskriv ning av UML Klass 1 +kännertill +kännertill Klass * Klass 2 Figur 33. 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 33). Hur klasserna känner till

69 67 (72) varandra ges av rollerna de har i associationen. Man kan även specificera multiplicitet för parterna i associationen, i Figur 33 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 men en superklass (Klass 1 i Figur 33) med de gemensamma egenskaperna. De specialiserade klasserna (Klass 2 i Figur 33) ä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 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 34. Attribut, stereotyper, datatyper och kodlistor. Klasser kan ha andra egenskaper än associationer, i Figur 34 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 34 ä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 34 för förekomma noll till många gånger, 0..*).

70 68 (72) 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 34). Den komplexa datatypen kan man definiera själv som en klass med stereotypen <<DataType>> (se nedan) eller så kan man använda någon av de i standarder fördefinierade komplexa datatyperna. Exempelvis finns i metadatastandarden ISO :2014 en komplex datatyp för att tala om ansvarig part för en datamängd eller del av datamängd (CI_ResponsibleParty). Attribut kan också vara av en typ som kallas kodlista. En kodlista är en lista med värden som attributet får anta. 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 34) ä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 35. 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 35 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

71 69 (72) 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 Beskriv ning av UML Klass 8 Klass 9 Klass 12 Figur 36. Beroende och realisering Beroende och realisering (Figur 36) är två andra specialiserade associationer som förekommer i modeller. Dessa associationer används för att belysa vissa aspekter men de implementeras inte själva direkt i en datamodell som övriga associationer. Ett beroende (streckad pil med öppen spets) innebär att Klass 8 har ett beroende till Klass 9. Ett konkret exempel är att respektive tema pekar ut de standarder som används i temat, detta görs med ett beroende, tema Hydrografi är till exempel beroende av den svenska vattensystemstandarden (SS637008:201x). Realisering (streckad pil med stängd, ofylld spets) i Figur 36 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 37. Paketstruktur i Alla modellelement är indelade i paket (mappar). I förekomer följande paket under huvudpaketet (Figur 37, 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.