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

Transkript

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

2 LANTMÄTERIET SVERIGES KOMMUNER OCH LANDSTING UPPHOVSMAN DOKUMENTANSVARIG Maria Andersson Tema Adress DOKUMENTNUMMER DOKUMENTDATUM BETECKNING Dnr /3028 VERSION FASTSTÄLLD VERSION DOKUMENTDATUM ÄNDRING NAMN Grundversion framtagen Anders Almroth, Göteborgs kommun Anders Carlström, Västerås kommun Eva Wramner, Lunds kommun Jan Karlsson, Hässleholms kommun Johan Reuterham, Lidingö kommun Allan Almqvist, Malmö kommun Karin Ericsson, Lantmäteriet Magnus Linnér, Lantmäteriet Maria Andersson, Lantmäteriet Helena Fyhr, Lantmäteriet Anna Wallin, Lantmäteriet Ulrika Roos, Lantmäteriet Slutversion från projektet Svensk geoprocess. Maria Andersson, Lantmäteriet Geodataspecifikationerna i version är resultat från projektet. Specifikationerna är testade och harmoniserade med hjälp av framtagna datautbytesmodeller (XML-scheman) och exempel (XML). XML-scheman finns tillgängliga för tester på hemsida Projektet avslutade juni 2016 och Samverkan ansvarar nu för förvaltning och vidareutveckling av geodataspecifikationerna. Inför version 3.0 kommer under hösten pilotinföranden och fortsatta tester att genomföras, vilket kan komma att påverka innehållet i geodatasspecifikationerna.

3 3 (85) Styrgruppen Bakgrund I samverkansprojektet utarbetas geodataspecifikationer för nio utvalda geodatateman. Målet med arbetet är att kunna leverera enhetliga geodata oavsett administrativa gränser, vilket bidrar till enklare och effektivare myndighetsutövning för till exempel planarbete, fastighetsbildning och bygglovshantering, miljö- och krisarbete samt infrastrukturbyggande. Arbetet med att utforma och förvalta specifikationerna bedrivs i samverkan mellan kommuner, Lantmäteriet och för temat andra berörda myndigheter. Specifikationerna baseras i stort på standarden SS-EN ISO 19131:2008, Geografisk information Specifikation av datamängder även om avsteg görs. Specifikationerna utnyttjar både internationella och svenska standarder samt är i möjligaste mån överensstämmande med Inspire:s dataspecifikationer för motsvarande geodatateman. Introduktion till Geodataspecifikation Adress Geodataspecifikationen för Adress är ett dokument som tagits fram i samverkan mellan Sveriges Kommuner och Landsting (SKL), Lantmäteriet och kommunerna. Specifikationen innehåller informationsmodell och krav på geodata som beskriver Adress. I temat Adress ingår även intressepunkter som är lokaliserande platser med ett namn som är känt och allmänt använt. Namnet är inte adressgrundande eller fastställt ortnamn. Geodataspecifikationen skildrar tillsammans med processbeskrivningen ett framtida scenario av temat Adress och ett arbetsflöde där flera aktörer samverkar för att effektivisera samhällsbyggnadsprocessen (processbeskrivningen innehåller en redogörelse av hur samverkan kring insamling, lagring och tillhandahållande ska gå till och tas också fram inom ). Med adress avses belägenhetsadress enligt den svenska standarden SS :2015. En belägenhetsadress definieras enligt svensk standard bland annat som ett sätt att ange en plats utan att använda koordinater. Belägenhetsadressen kan ha viss tilläggsinformation, t.ex. populärnamn, postnummer och postort. Geodataspecifikationen avser de geodata om adress som Lantmäteriet och kommunerna samlar in, lagrar och tillhandahåller. Specifikationen för adress ska, tillsammans med andra datamängder möjliggöra en s.k. baskarta. Baskartan ska utgöra en grund för framställning av kommunens olika kartprodukter. Objekt beskrivna i specifikationen kan även ingå i andra typer av kommunala produkter. Adressdatas 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å Adressdatas 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 specifikationen ä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 (se figur 2). I de fall de närliggande företeelserna inte omfattas av andra teman inom så är de dokumenterade och förslag på informationsansvariga aktörer pekas ut.

4 4 (85) Styrgruppen 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. Informationsmodellen är i stor utsträckning baserad på Lantmäteriets befintliga informationsmodell och informationsutbytesmodell, vilka används inom samverkan ABT mellan kommunerna och Lantmäteriet. Som underlag och input till framtagning av modellen har även kommunala processer studerats, INSPIRE (tema Adress), den svenska standarden för belägenhetsadress (SS :2015) granskats samt viss omvärldsanalys gjorts kring blåljusaktörernas behov, lagstiftning m.m. Krav på Adress 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 Styrgruppen 5 (85) Innehållsförteckning 1 GEODATASPECIFIKATIONENS OMFATTNING 6 2 ÖVERSIKT 6 3 ADRESSDATAS OMFATTNINGAR 13 4 IDENTIFIERING AV ADRESSDATA 16 5 DATAINNEHÅLL OCH STRUKTUR 18 6 REFERENSSYSTEM 43 7 KVALITETSKRAV 46 8 METADATA 47 9 TILLHANDAHÅLLANDE DATAFÅNGST OCH AJOURHÅLLNING PRESENTATIONSREGLER ÖVRIG INFORMATION REFERENSER BILAGOR Bilaga A. Test av specifikationsöverensstämmelse Bilaga B. av UML Bilaga C. Fullständig informationsmodell Bilaga D. Objekttypskatalog Bilaga E. Krav och rekommendationer Bilaga F. Relationer till specifikationer eller datamängder som ej omfattas av. 85

6 6 (85) Styrgruppen 1 Geodataspecifikationens omfattning Detta dokument utgör en gemensam geodataspecifikation för Adress och Intressepunkt som framställts på uppdrag av Lantmäteriet, kommunerna, SKL och andra myndigheter. Specifikationen omfattar grundläggande geografiska data om adresser och intressepunkter som tillsammans med andra data (beskrivna inom eller utanför ) ska kunna utgöra ett underlag för användning inom statlig, kommunal och privat verksamhet där man behöver uppgifter om enskilda adresser och platser. 2 Översikt 2.1 Information om geodataspecifikationen Titel Geodataspecifikation Adress 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 Syfte 013 Positionering Ämnesområde ur den nationella metadataprofilen (tabell 33). Specifikation av de nationella krav som ställs på utbyte av Adress och Intressepunkt 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 Adress och Intressepunkt avses utbyte med klassning enligt denna specifikations informationsmodell. Denna geodataspecifikation riktar sig i första hand till dataproducenter, systemleverantörer och systemutvecklare som ansvarar för att utbyta datamängder enligt denna specifikation. Geodataspecifikationen ska också kunna vara ett stöd för användare av data i att få större förståelse för framförallt levererade datamängders användbarhet.

7 7 (85) Styrgruppen Termer och beskrivningar 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 kapitel Tabell 1. Temaspecifika termer Adress Termer ur Geodataspecifikation Adress Adressområde Adressplats Byadressområde Gatuadressområde Gårdsadressområde Geografisk kommundel Metertalsadressområde Intressepunkt Populärnamn (och eventuella kommentarer) För adressering skapat geografiskt område inom en geografisk kommundel. Adresserbart objekt som utgörs av en geografisk plats. Adressområde där byadresser eller gårdsadresser tillämpas. Adressområde där gatuadresser tillämpas Geografiskt avgränsat, icke överlappande, vanligen sammanhängande område inom ett byadressområde. Geografiskt avgränsat, icke överlappande, vanligen sammanhängande område inom en kommun. Anm. Hela kommunen ska täckas av kommundelar. Adressområde där metertalsadresser tilllämpas Lokaliserande plats med punktgeometri som har ett namn som är känt och allmänt använt. Namnet är inte adressgrundande. Benämning som inte är en adress men som används som ett komplement till belägenhetsadressen för att identifiera en eller en samling av adressplatser. (Svensk standard för belägenhetsadresser, SS :2015) Tabell 2. Generella termer i Generella termer Term (och eventuella kommentarer)

8 8 (85) Styrgruppen Abstrakt objekttyp Abstraktion Applikationsschema Association Attribut Attributtyp Baskarta Baskarteområde Begreppsmodell Coverage Objekttyp som inte själv kan ha några instanser : 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 : Ett värde som representerar det observerade värdet av en Egenskap hos en Företeelse Egenskap hos Objekt : Representerar en eller flera Egenskaper hos en Företeelsetyp : 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. : 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. som anges är rasterbild, polygon-lager, digital höjdmatris.

9 9 (85) Styrgruppen 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. Datamodell Egenskap Företeelse Företeelsetyp Geodataspecifikation Informationsmodell Kvalitetsmått (engelska, quality measure) Kvalitetsparameter för hur data ska struktureras och innehålla vid till exempel lagring eller utbyte Format i vilket attribut anges : Olika datatyper har olika egenskaper och kan användas i olika typer av operationer Ej samma sak som stereotypen <<DataType>> i grafiska modelleringsnotationer : 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 : Barr/Löv Art Höjd Solitärt träd Ett i verkligheten förekommande fenomen : Kan vara ett ting eller en process. Kan vara ett naturligt eller konstgjort fenomen. Är en instans av en Företeelsetyp : Trädet utanför huset Grupp av Företeelser med samma egenskaper : 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, 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.

10 10 (85) Styrgruppen (engelska, quality element) Kvalitetstema (engelska, data quality element category) Kodlista Metadata Modellelement Objekt Objekttyp Objekttypskatalog 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. Källa: HMK Ordlista Uppräknade värden som en attributtyp kan anta : 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 : 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. : Objekttyper och attributtyper. Instans av Objekttyp : Representerar en individ i verkligheten : Ek id: 21 (Id är egentligen ett attribut men behövs för att identifiera just den ek vi avser) Abstraktion av Företeelsetyp : 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. : Lövträd Vedartade växter En sammanställning av en informationsmodell i tabellform Förkortningar ABT Adress Byggnad Topografi. Samverkansavtal kring ABT finns mellan kommunerna och Lantmäteriet.

11 11 (85) Styrgruppen DGNSS EPSG GALILEO GLONASS GML GNSS GPS HMK Nätverks-RTK OGC Differentiell GNSS. Relativ GNSS-mätning där korrektioner för systematiska felkällor beräknas på referensstation och sänds till mobila GNSS-mottagare, som korrigerar sina mätningar. European Petroleum Survey Group System för satellitnavigering som utvecklas på uppdrag av EU och Europeiska rymdorganisationen (ESA). Globalnaja navigatsionnaja sputnikovaja sistema Geographic Markup Language 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 Lantmateriet/Samverkan-med-andra/Handbok-i-mat--ochkartfragor-HMK/ 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 SKL SWEREF 99 SWEREF 99 TM SWEREF 99 dd mm UUID XML Sveriges Kommuner och Landsting 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.

12 12 (85) Styrgruppen 2.2 Information om Adressdata Namn Adress Förkortning - av innehåll Utsträckning i tid och rum Syfte I Fastighetsregistrets Adressdel finns aktuell information om belägenhetsadresser. En belägenhetsadress definieras enligt svensk standard SS :2015, bland annat som ett sätt att ange en plats utan att använda koordinater. Belägenhetsadressen kan ha viss tilläggsinformation, t.ex. populärnamn, postnummer och postort. Adressdata innehåller de objekttyper som har identifierats utgöra underlag vid planering, bygglovshantering, fastighetsbildning, beslut om adress, hantering av lägenhetsregistret samt framställning av kartprodukter. Objekttyperna kan användas för att beskriva befintliga geografiska kommundelar, adressområden, adressplatser med tillhörande geografiskt läge, adresstyper samt namn och andra egenskaper. Datakvaliteten på adresserna varierar beroende på kommunens avtalsnivå i samverkansavtalet ABT mellan kommunerna och Lantmäteriet. Som komplement till adresserna för att möta samhällets behov av namnförtätning innehåller specifikationen även intressepunkter (eng. points of interest). Dessa är platser som personer kan relatera till och som saknar fastställt ortnamn och adress. Intressepunkterna gör det möjligt för blåljusmyndigheterna, post- och distributionsföretag, medborgare m.fl. att hitta till rätt plats. Hela Sverige Adresser används inom många områden, bl.a. inom Skatteverkets folkbokföringsverksamhet, PostNords verksamhet med postnummersättning samt för att lokalisera byggnader, fastigheter och verksamheter i andra verksamhetssystem. Adresserna är också en viktig del i kommunernas ansvar att registrera lägenhetsinformation i lägenhetsregistret. Genom att adressen har ett geografiskt läge (koordinater) kan de tillsammans med annan information användas i geografiska informationssystem (GIS). på användningsområden är bilnavigering och ruttplanering. Blåljusorganisationerna i Sverige samt SOS-Alarm är viktiga exempel på användare av adresser och dess geografiska läge.

13 13 (85) Styrgruppen Datakällor 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. Adressdatadukten bidrar också till att annan myndighetsutövning underlättas, t.ex. för Skatteverkets folkbokföring, Post- Nords hantering av postnummer och postort samt blåljusaktörernas arbete och uppdrag. Intressepunkterna utgör ett komplement till adresserna och gör det möjligt för blåljusmyndigheterna, post- och distributionsföretag, medborgare m.fl. att hitta till rätt plats där fastställt ortnamn saknas. Kommunala databaser, Lantmäteriets databas Produktionsprocesser Dataproduktionen sker hos kommunerna (insamling och ajourhållning) och utförs i första hand i samband med bygglovshanteringen och detaljplanehanteringen. Kommunerna beslutar och registrerar nya adresser och ansvarar för hela kommunen. Ajourhållning Ajourhållning sker kontinuerligt hos kommunerna i samband med, i första hand, bygglovshanteringen och detaljplanearbete. 3 Adressdatas omfattningar Detta kapitel beskriver hur Adressdata kan delas in i olika delar, delomfattningar, vilket medför att olika krav kan ställas på de olika delarna ur olika aspekter. 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 Adressdata har 4 delomfattningar identifierats som beskrivs nedan. 3.1 Omfattning A - Adressdata Identifiering av omfattning Hierarkisk nivå Adresser 005 Datamängd Namn på hierarkisk nivå av hierarkisk nivå Adress Datamängd beskrivande belägenhetsadress.

14 14 (85) Styrgruppen Utsträckning Data förekommer över hela Sverige. Coverages - Ingående omfattningar Delomfattning B Samverkansavtal ABT Delomfattning C Samverkansavtal ABT, nivå S1 Delomfattning D Samverkansavtal ABT, nivå S2 Delomfattning E Samverkansavtal ABT, nivå S3 3.2 Delomfattning B Samverkansavtal ABT Identifiering av omfattning Hierarkisk nivå Samverkansavtal ABT 005 Datamängd Namn på hierarkisk nivå av hierarkisk nivå Samverkansavtal ABT Adresser ajourförs av kommuner enligt gällande ABT-avtal. Nivåerna S1, S2, S3 Utsträckning Överordnad omfattning Data förekommer över hela Sverige. Adressdata 3.3 Delomfattning C Samverkansavtal ABT, nivå S1 Identifiering av omfattning Hierarkisk nivå Samverkansavtal ABT S1 005 Datamängd Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Samverkansnivå S1 Adress Adressdelen i Fastighetsregistret är upplagd och kommunen ajourför kontinuerligt. Adresser finns till de flesta bostadshusen. Adresser kan saknas inom vissa geografiska områden. Data förekommer över hela Sverige.

15 15 (85) Styrgruppen Överordnad omfattning Samverkansavtal ABT 3.4 Delomfattning D Samverkansavtal ABT, nivå S2 Identifiering av omfattning Hierarkisk nivå Samverkansavtal ABT S2 005 Datamängd Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Samverkansnivå S2 Adress Adressdelen i Fastighetsregistret innehåller samtliga adresser till byggnader med ändamålen bostadshus, verksamhet och industri. Alla byggnader med flera ingångar har en unik adress för varje ingång i markplan. Data förekommer över hela Sverige. Samverkansavtal ABT 3.5 Delomfattning E Samverkansavtal ABT, nivå S3 Identifiering av omfattning Hierarkisk nivå Samverkansavtal ABT S3 005 Datamängd Namn på hierarkisk nivå av hierarkisk nivå Utsträckning Överordnad omfattning Samverkansnivå S3 Adress Adresserna har unika individuella koordinater. Om flera adresser är knutna till samma byggnad, ska läget för adresskoordinaterna avse ingången i markplan. Data förekommer över hela Sverige. Samverkansavtal ABT

16 16 (85) Styrgruppen 4 Identifiering av Adressdata Titel Adress Alternativ titel Adress Produktnummer - Versionsnummer Sammanfattning Adressdata innehåller utrymme för att beskriva belägenhetsadresser och intressepunkter. Fastighetsregistrets Adressdel är ett nationellt register över Sveriges belägenhetsadresser. En belägenhetsadress definieras enligt svensk standard, SS :2015, bland annat som ett sätt att ange en plats utan att använda koordinater. Belägenhetsadressen kan ha viss tilläggsinformation, t.ex. populärnamn, postnummer och postort. Adresser finns för byggnader med ändamålen bostad, verksamhet, industri och samhällsfunktion. Processen ägs av kommunerna. Kommunerna beslutar och registrerar adresserna. Data om adresser ska, tillsammans med andra data, möjliggöra en baskarta som ajourhålls regelbundet och fungerar som underlag inom flera delar inom samhällsbyggnadsprocessen. Bl.a. är adressen en viktig del i kommunernas uppgift att registrera lägenhetsinformation i lägenhetsregistret. Adressinformation ingår i flera andra myndigheters uppdrag, t.ex. Skatteverkets folkbokföringsverksamhet, SCB:s verksamhet med hushålls- och bostadsstatistik, SOS Alarms och blåljusaktörernas verksamhet samt PostNords verksamhet med postnummersättning. Syfte Adressdata är väl beskriven och rymmer data om adresser som behövs som underlag vid framförallt detaljplanering, bygglovshantering samt lägenhetsregistrering och syftar till att skapa en nationell grundläggande datamängd för adresser. 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. ukten Adressdata kan också bidra till att annan myndighetsutövning underlättas.

17 17 (85) Styrgruppen Genom utökning med intressepunkter blir det möjligt att hantera platser som inte är adressgrundande eller som saknar fastställt ortnamn. Dessa platser blir då sökbara i olika aktörers verksamhetssystem, t.ex. blåljusaktörerna. Ämnesområde Typ av geometrisk representation 013 Positionering Ämnesområde ur den nationella metadataprofilen (tabell 33). 001 Vektor Ur den nationella metadataprofilen (tabell 52). Rumslig upplösning - Geografisk utsträckning Adressdata förekommer över hela Sverige. Kompletterande information För ajourhållningen av Adressdata finns handböcker tillgängliga på Lantmäteriets webbplats Närliggande begrepp är folkbokföringsadress och postadress. Dessa begrepp ska inte förväxlas med belägenhetsadress.

18 18 (85) Styrgruppen 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 Adressdata. sker med hjälp av figurer (UMLdiagram), förklarande text och en objekttypskatalog. Objekttypskatalogen är inte utformad efter ISO Feature catalogue som ISO anger, utan istället skapad med fokus på enkelhet och läsbarhet. Inom har inga applikationsscheman (enligt ISO 19109) tagits fram utan det sätt som Adressdatas innehåll är grafisk dokumenterat 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 Allmänt om adresser Adressdata innehåller i huvudsak information om adresser till byggnader med ändamål: Bostad Industri Verksamhet Samhällsfunktion Belägenhetsadressens funktion En belägenhetsadress anger var en geografisk plats är belägen. Plats är enligt Svensk ordbok utgiven av Svenska Akademien "...område med välbestämt läge och begränsad omfattning, ibland mer eller mindre tänkt som en punkt (jämför: position, ställe)". Olika typer av adresser fyller olika syften. En postadress till exempel ger information till postoperatör om slutdestination för postförsändelser och en besöksadress anger var man kan anträffa någon eller något. För att en belägenhetsadress ska fylla sitt syfte är det nödvändigt att den är unik, alltså att varje belägenhetsadress bara förekommer en gång. Den ska också entydigt peka ut en enda plats. Av detta följer att belägenhetsadresser måste sättas, fastställas och registreras på ett enhetligt sätt och att inom varje geografiskt område måste någon organisation ha ansvaret för detta. Belägenhetsadressen har en viktig funktion genom att den kan fungera som identifierare för den byggnad eller anläggning som adressen knutits till. Denna funktion kan utnyttjas för uppbyggnad av register över exempelvis bostadslägenheter eller verksamhetslokaler. En annan viktig funktion är att belägenhetsadresser används i folkbokföringen, i förekommande fall kompletterad med lägenhetsnummer. Till skillnad från många andra referenssystem är belägenhetsadresserna kända och används av dem som besöker, bor på eller verkar på platsen. De redovisas ofta på kartor och också på skyltar vid gator och vägar och på hus. Belägenhetsadresserna är särskilt viktiga för tillfälliga besökare. Ansvaret för att sätta belägenhetsadresser I och med lagen om lägenhetsregister har ansvaret för att sätta belägenhetsadresser till en del lagreglerats. I 10 anges att "För varje entré ska kommunen fastställa en belägenhetsadress".

19 19 (85) Styrgruppen Genom kommunallagens regler om kommunernas allmänna kompetens får i praktiken kommunerna ansvaret för att fastställa belägenhetsadresser när sådana uppenbarligen behövs, som för lokaler där verksamhet bedrivs och för samlingslokaler. God ortnamnssed Belägenhetsadresserna innehåller alltid ortnamn. Det är med hjälp av ortnamnen som en belägenhetsadress blir unik och entydig. Ortnamnen är samtidigt en viktig bärare av landets kulturarv och detta avspeglas i regler om god ortnamnssed i kulturmiljölagen. Standarden stöder också inom ramen för god ortnamnssed lokala traditioner i adressskicket. Vid fastställandet av namnen i belägenhetsadressen ska god ortnamnssed iakttas i enlighet med kapitel 1 4 i kulturmiljölagen: Vid statlig och kommunal verksamhet ska god ortnamnssed iakttas. Det innebär att: hävdvunna ortnamn inte ändras utan starka skäl ortnamn i övrigt stavas enligt vedertagna regler för språkriktighet, om inte hävdvunna stavningsformer talar för annat påverkan på hävdvunna namn beaktas vid nybildning av ortnamn och namn på svenska, samiska, finska och meänkieli så långt möjligt används samtidigt på kartor samt vid skyltning och övrig utmärkning i flerspråkiga områden. Namn som godkänts av Lantmäteriet ska i statlig och kommunal verksamhet användas i sin godkända form. Lag (2013:548). Adressättning i svenska kommuner utgår från en särskild geografisk indelning. Denna specifikation beskriver principerna för denna geografiska indelning. Denna specifikation specificerar regler för adresskomponenter i belägenhetsadresser för gatuadressplatser, metertalsadressplatser, byadressplatser och gårdsadressplatser. Hierarki Grunden för belägenhetsadresser ska vara en indelning av Sverige i kommuner. Kommunerna ska i sin tur delas in i namngivna geografiska kommundelar. I många fall omfattas hela kommunen av endast en geografisk kommundel. Den typ av adress som är lämpligast för ett visst område inom en geografisk kommundel avgör om området ska betraktas som gatuadressområde, metertalsadressområde, byadressområde eller gårdsadressområde. Inom gatuadressområden tillämpas gatuadresser och inom metertalsadressområden tillämpas metertalsadresser. Inom ett byadressområde tillämpas byadresser utom då det innehåller ett gårdsadressområde. Där ska gårdsadresser tillämpas. På yttersta nivån finns olika typer av adressplatser. Figur 1 visar relationerna mellan olika typer av områden och platser.

20 20 (85) Styrgruppen Figur 1. Hierarki för olika typer av platser och områden. Samtliga adresser har en lägesuppgift i form av koordinater. Från adressobjektet finns samband/kopplingar mot objekten fastighet, byggnad och lägenhet En avgränsning är gjord mot lägenhet, som inte ingår i denna specifikation Allmänt om intressepunkter Adresser och ortnamn är nödvändiga för att kunna lokalisera oss i samhället. Som komplement till dessa finns intressepunkter. Dessa utgör en förtätning av namn och ska vara till nytta för lokalisering i olika sammanhang. Intressepunkterna ska enbart registreras med en punktgeometri, samt ett namn. Namnet blir sökbart, men är inte beslutat och ska inte betraktas som ett officiellt ortnamn. Objekttypen Intressepunkt är egentligen inte ett adressobjekt men hanteras i tema Adress eftersom behovet beskrivs i samband med att adresser diskuteras och ses som ett komplement till adress för att hitta rätt i samhället. /avgränsning av Intressepunkt: - är en lokaliserande plats, t.ex. en mötesplats. - har punktgeometri - namnet är inte adressgrundande - är ett namn som är känt och allmänt använt - kan i vissa fall ha flera namn på platser som är intressepunkter: Staty, Utslagsplats (driving range) på golfbana, ett visst gatuhörn Det är kommunerna som ansvarar för registrering och ajourhållning av intressepunkter, som sker antingen via LINA eller via kommunens applikation, och som levereras till Lantmäteriet för lagring, liknande byggnad och adress. Varje kommun ansvarar för ajourhållning av kommunens intresspunkter, så att de hålls aktuella.

21 21 (85) Styrgruppen Namn på intressepunkter är per definition aldrig officiellt beslutade. Det är namn som används allmänt, men som också kan förändras snabbt och/eller ersättas med ett annat namn. Förslag på platser som behöver registreras, kan komma från t.ex. blåljusaktörer eller allmänheten. Ett tydligt regelverk beskriver vilka företeelser som ska ses som intressepunkter. Intressepunkter ska användas för företeelser som inte representeras av annan objekttyp. Park, parkering och badplats är exempel på företeelser som representeras av objekttyper inom temat Markanvändning. 5.2 Informationsmodell och objekttypskatalog Informationsmodellen är uppdelad i flera figurer för att belysa de olika delarna av modellen. Hela informationsmodellen återfinns i 14.3 bilaga C. I avgränsandet av Adressdata så har företeelser identifierats som har beroenden eller associationer till Adress, men som inte omfattas av Adressdata. I 14.6 bilaga F illustreras dessa företeelser samt eventuella aktörer ansvariga för specifikationer som motsvarar företeelser som inte omfattas av andra specifikationer som utvecklas inom. er och objekttyper har, där det har varit möjligt, hämtats från Svensk standard för belägenhetsadresser (SS :2015). I standarden finns inte något UMLdiagram. Därför har inga klasser importerats därifrån som det är gjort i temat Hydrografi. informationsmodeller är framförallt skapade för att visa informationen utifrån ett verksamhetsperspektiv vilket redovisas i specifikationerna. För att kunna skapa datautbytesmodeller i form av XML-scheman motsvarande informationsmodellerna har en del avgränsningar och uppdelningar behövt göras. Dessa nya schemagrundande informationsmodeller redovisas ej i specifikationerna utan tillhandahålls tillsammans med XML-scheman, kodlistor och exempel via projektets hemsida De schemagrundande informationsmodellerna tillhandahålls som html eller som en.eap-fil (Sparx systems Enterprise Architecht). I objekttypskatalogen ingår endast objekttyper skapade för Adressdata 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 Fel! Hittar inte referenskälla..

22 Styrgruppen 22 (85) 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. Krav 2. Krav 3. Krav 4. Krav 5. Krav 6. Informationsmodellens obligatoriska attribut och associationer ska finnas med i datamängd enligt denna geodataspecifikation (se avsnitt 7.1, Tabell 2, nr.3). Informationsmodellens angivelser om multiplicitet ska följas för datamängder enligt denna geodataspecifikation (se avsnitt 7.1, Tabell 2, nr. 3). Endast värden från kodlistor ska användas för attribut vars typ är en kodlista (se avsnitt 7.1, Tabell 2, nr. 4). Kodlistor är utökningsbara. Utökad kodlista ska tillhandahållas av ansvarig part. Koder/värden i utökade kodlistor ska inte stå i konflikt med värden i ursprunglig kodlista. Utökning av kodlistor ska ske i samverkan mellan alla identifierade intressenter. Rekommendation 1. Gemensamma kodlistor ska förvaltas av Lantmäteriet 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 XML-schemaspecifikationen 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

23 23 (85) Styrgruppen 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 3), orsaken till att värdet saknas. Tabell 3. 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 i normalfallet då ett värde finns <SG_Objekt> <id>xxxxx</id> <typ xlink.href= </SG_Objekt> då värde saknas och nil används: <SG_Objekt> <id>yyyyy</id> <typ xsi:nil= true nilreason= unknown /> </SG_Objekt> 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.). : <SG_Objekt> <Geometri srsname= epsg:3006>

24 24 (85) Styrgruppen <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> Beroenden till andra specifikationer pkg SG_AdressPaketBeroenden SG_GemensammaKlasser SG_Byggnad (from SvenskGeoprocess) SS637003:2007 Belägenhetsadresser (from SvenskGeoprocess) SG_Adress Addresses + Addresses (from SvenskGeoprocess) (from Annex I) SG_VägJärnv äg (from SvenskGeoprocess) ISO 19115:2006 Metadata (Corrigendum) ISO 19107:2003 Spatial Schema + Geometry + Topology (from ISO TC211) (from ISO TC211) Figur 3. Paketdiagram visande dataprodukten Adress beroenden till andra teman inom Svensk geoprocess samt standarder. Adressdata utnyttjar andra standarder och modeller. Detta illustreras genom paketberoenden (figur 3). Adressdatas objekttyper har identifierats ha relationer till objekttyper som återfinns i andra specifikationer inom. I informationsmodellen beskrivs sambandet med Byggnad. I samverkansprocessen beskrivs sambandet med hanteringen av vägar 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.

25 25 (85) Styrgruppen De gemensamma klasserna medför att identifierare, livcykelinformation, geometrier och beskrivning av datamängder och metadata hanteras enhetligt SG_BasKlass SG_BasKlass (Fel! Hittar inte referenskälla.) ä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. en 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 (Fel! Hittar inte referenskälla.) som kommer från Inspire och består av en namnrymd (namespace) och ett id (localid) som tillsammans ger ett unikt id vilket förklaras djupare i För nationelltid ska namespace inte peka ut en organisation utan en datamängd enligt en viss specifikation. För verksamhetsid ska namespace peka ut en organisation men kan även peka ut en viss datamängd som förvaltas av organisationen. Se ytterligare om identifierare i Attributet externreferens, av typen SG_ExternReferens ger möjlighet att associera ett objekt enligt en specifikation med ett annat objekt enligt en annan specifikation, exempel: möjlighet att koppla en byggnad till ett ortnamn ur Ortnamnsregistret. Objekt enligt olika specifikationer i kan representera samma verkliga företeelse men ur olika aspekter. Associationen representerarsammaföreteelse ger möjlighet att tala om att ett objekt enligt en specifikation i representerar samma verkliga företeelse som ett annat objekt ur en annan specifikation i. : 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

26 26 (85) Styrgruppen 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} på ett nationellt id skulle då kunna bli: fd5e-90ec-e040-ed8f66333c3f på ett verksamhets-id skulle då kunna bli: Krav 4. Alla objekt i en datamängd enligt denna geodataspecifikation ska ha en identifierare (Id) (Se kapitel 7.1). Krav 5. Då endast en identifierare anges skall den vara av typen nationellid. Krav 6. Då två identifierare anges skall de vara ett av varje typ, nationelltid och verksamhetsid.

27 Styrgruppen 27 (85) Krav 7 nationelltid:s namespace ska identifiera en datamängd. Krav 8. verksamhetsid:s namespace ska identifiera en organisation. Krav 9 Identifierare ska vara av typen Identifier (Inspire - Generic conceptual model - BaseTypes) (Se kapitel 7.1) Krav 10. 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 Multiplicitet id Identifierare [1..2] SG_Id beginlifespanversion endlifespanversion externreferens aktualitet Datum då objekt först skapades i datamängd. 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..1] DateTime [0..*] SG_ExternReferens [1] DateTime

28 Styrgruppen 28 (85) er SG_Id Identifierare Attribut Multiplicitet nationelltid verksamhetsid Nationell identiferare : namespace pekar ut datamängd, ej ansvarig organisation Lokal identifierare skapad utifrån specifika verksamheters behov : namespace pekar ut ansvarig organisation, ej datamängd, [1..1] Identifier [1..1] Identifier SG_ExternReferens Referens till annan objekttyp i eller utanför. Attribut Multiplicitet id Identifierare för externt objekt som refereras till. [1] CharachterString SG_Projekt SG_Projekt, Figur 6, är en objekttyp som kan användas i olika teman inom. SG_Projekt är en subtyp till SG_BasKlass och ärver därifrån id livscykelinformation och extern referens. SG_Projekt innehåller flera attribut som hänförs till myndigheter eller företag som på något sätt deltar i projekten som utförare eller beställare. Informationen lagras i en datatyp Related Party, vilken importerats från Inspire Generic Conceptual Model.

29 Styrgruppen 29 (85) class SG_Proj ekt «FeatureType» SG_GemensammaKlasser::SG_BasKlass + id :SG_Id [1..2] + beginlifespanversion :DateTime [0..1] + endlifespanversion :DateTime [0..1] «FeatureType» SG_GemensammaKlasser::SG_Proj ekt + geodataproducent :RelatedParty [0..*] + geodataägare :RelatedParty [1..*] + projektid :CharacterString + projektnamn :CharacterString [0..1] + projektrapportlänk :URI [0..1] + uppdragsgivare :RelatedParty [0..*] Figur 6. SG_Projekt class RelatedParty «datatype» Base Types 2::RelatedParty «voidable» + individualname :PT_FreeText [0..1] + organisationname :PT_FreeText [0..1] + positionname :PT_FreeText [0..1] + contact :Contact [0..1] + role :PartyRoleValue [0..*] «datatype» Base Types 2::Contact «voidable» + address :AddressRepresentation [0..1] + contactinstructions :PT_FreeText [0..1] + electronicmailaddress :CharacterString [0..1] + hoursofservice :PT_FreeText [0..1] + telephonefacsimile :CharacterString [0..*] + telephonevoice :CharacterString [0..*] + website :URL [0..1] Figur 7. RelatedParty

30 30 (85) Styrgruppen Objekttyper SG_Projekt Information om dataskapande/-insamlande verksamhet som bedrivs i projektform Attribut Multiplicitet geodataproducent geodataägare Organisation som producerar geodata. Rättighetsinnehavare till datamängd [0..*] RelatedParty [1..*] RelatedParty projektid Unik identifiering av projekt. [1..1] CharacterString projektnamn projektrapportlänk Namn på projektområdet, t.ex. ortnamn Länk till en adress där projektrapport är tillgänglig [0..1] CharacterString [0..1] URI uppdragsgivare Beställare av projekt [0..*] RelatedParty Geometrityper För specifikationer har en grunduppsättning geometrityper tagits fram, figur 8. De är i huvudsak specialiseringar av geometrityper från SS-ISO 19107:2003 Modell för att beskriva rumsliga aspekter. 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 7. geometrityper

31 Styrgruppen 31 (85) 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 ) samt vilken metod som har använts för att fastställa lägesosäkerheten. class SG_Lägesosäkerhet «DataType» SG_GemensammaKlasserer:: SG_LägesOsäkerhet + mätmetod: CharacterString [0..1] + lägesosäkerhet: DQ_PositionalAccuracy + tidpunktmätning: DateTime [0..1] Figur 8. Lägesosäkerhet för geometrier. GeometriId anges på samma sätt som för SG_BasKlass (Fel! Hittar inte referenskälla.). GeometriKälla anges med Inspire-klassen RelatedParty (Figur ). 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 9. RelatedParty

32 32 (85) Styrgruppen I många kommunala verksamheter används inte ytor (polygoner) för att representera företeelser med ytutbredning i verkligheten utan istället används linjer, till exempel begränsningslinje eller kantlinje. För att kunna tala om vad en linje representerar gällande en verklig företeelse så är attributet typavlinje obligatoriskt för alla linjer. En linje kan vara: Kantlinje, en linje som används för att beskriva ytterkant på en företeelse. Till exempel kan ett dike representeras av två kantlinjer. Mittlinje, en linje som representerar en utsträckt företeelses mitt. Till exempel så kan ett dike i tillägg till två kantlinjer även ha en mittlinje. Annan linje, alla övriga typer av linjer. Till exempel kan man låta en linje representera ett mindre vattendrag i en småskalig presentation oavsett om den avser vattendragets mitt eller kant. Då man inte hanterar ytor utan linjer som geometrisk representation för ytutbredda företeelser i verkligheten så förekommer de ofta tillsammans med en centroid (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_KartografiskRepresentationLinjeTyp 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 kantlinje- Egenskap som använder kodlistan SG_KantlinjeEgenskapTyp.

33 33 (85) Styrgruppen class SG_GeometriMetadata «DataType» SG_GemensammaKlasserer::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 10. Geometrimetadata I Figur 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ätningslä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

34 34 (85) Styrgruppen avser det datum då själva geometrin tolkats/skapats och lagrats i en databas. På liknande sätt anger endlifespanversion när en geometri ersatts av en nyare geometri databas eller beslutats inte längre vara aktuell eller användbar. I vissa fall kan en företeelse vara skymd, helt eller delvis, i en flygbild eller ett ortofoto och den som skapar geometrin gör en uppskattning av geometrin utifrån erfarenhet, regler och/eller andra indikatorer i bilden. När så inträffar skall attributet osäkert läge (skymd geometri) sättas till True (standardvärde för attributet är False ) och attributet osäkertlägeanledning skall anges Objekttyper SG_Geometri Geometrityper och kvalitetsmärkning av ett objekts geometri - framtagna för ändamål. Attribut Multiplicitet geometriid Identifierare för geometri [1..2] SG_Id LägesOsäkerhetPlan LägesOsäkerhetHöjd geometrikälla Mätmetod och standardosäkerhet för geometris läge i plan Mätmetod och standardosäkerhet för geometris läge i höjd Organisation ansvarig för geometri [0..1] SG_LägesOsäkerhet [0..1] SG_LägesOsäkerhet [1..1] RelatedParty geometrimetadata Metadata för geometri [0..1] SG_GeometriMetadata SG_Punkt Endimensionell geometri som beskriver en punkt Attribut Multiplicitet 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 Multiplicitet linje Geometri [1..1] GM_MultiCurve typavlinje kartografiskrepresentation kantlinjeegenskap Kategorisering av linjegeometri utifrån användningssyfte 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

35 Styrgruppen 35 (85) Attribut Multiplicitet yta Geometri [1..1] GM_MultiSurface SG_Kropp Tredimensionell geometri som avgränsas av gränsytor Attribut Multiplicitet kropp Geometri [1..1] GM_Solid er SG_GeometriMetadata Geometrityper och kvalitetsmärkning av ett objekts geometri - framtagna för ändamål. Attribut Multiplicitet geometrinamn Namn på geometri [0..1] CharacterString geometrisyfte inmätningsläge tänktupplösningpresentation aktualitet insamlingsdatum beginlifespanversion osäkertläge Syfte för vilket geometri skapats 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 : Avser vanligen det datum då flygbild tagits eller geodetisk fältmätning utförts Datum då objekt skapades i datamängd : 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 : Kallas även skymd geometri, False = ej osäkert läge är standardval [0..1] CharacterString [0..1] SG_InmätningsLäge [0..1] MD_Resolution [0..1] DateTime [0..1] DateTime [0..1] DateTime [1..1] Boolean osäkertlägeanledning endlifespanversion 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. : Objekt ersatta med nyare objekt/versioner är vanligtvis inte tillgängliga via [0..1] CharacterString [0..1] DateTime

36 Styrgruppen 36 (85) normala sökningar/frågor mot datamängd. SG_LägesOsäkerhet av mätmetod och standardosäkerhet för lägesbestämning av en geometri. Attribut Multiplicitet lägesosäkerhet mätmetod tidpunktmätning Geometrins standardosäkerhet Metod för fastställning av geometrins läge. Tidpunkt för mätning. : Används då olika metoder används för mätning i plan och höjd, annars används bara insamlingsdatum på SG_GeometriMetadata [1..1] DQ_PositionalAccuracy [1..1] CharacterString [0..1] DateTime Kodlistor SG_typAvLinje Värden Kantlinje Mittlinje AnnanLinje Kategorisering av linjegeometri utifrån användningssyfte. 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 av hur en linje är tänkt att representeras kartografiskt. : Kodlistan kommer att variera i olika specifikationer och hur den ska implementeras beskrivs av respektive specifikation. SG_KartografiskRepresentationLinjeTyp SG_SG_KantlinjeEgenskapTyp Värden Egenskaper som en kantlinje kan ha Kantsten Släntfot Släntkrön SG_InmätningsLäge Värden Enligt SGP mätningsanvisning av hur en geometri är inmätt : Kodlistan kommer att variera för olika specifikationer och hur den ska implementeras beskrivs av respektive specifikation. Startvärde ("default") är Enligt SGP mätningsanvisning. 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.

37 37 (85) Styrgruppen : 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å höjddata i olika frågeställningar ö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öjdkoordinat på en geometri. För adresser finns endast plankoordinater. Ingen anpassning till tredimensionell representation av byggnader sker. Däremot ska adresser kunna kopplas till flera fastigheter vid 3D-fastighetsbildning, både till markfastigheten och till 3D-utrymmet t.ex. en ägarlägenhetsfastighet SG_Datamängd För att visa hur datamängder sätts ihop av objekttyper i teman inom samt att för att visa hur metadata förhåller sig till en datamängd har en gemensam objekttyp för datamängd, SG_Datamängd, skapats (figur 9) class SG_Datamängd «DataSet» SG_GemensammaKlasser:: SG_Datamängd + aktualitet :DateTime + sekretessad :Boolean = false +metadata Metadata entity set information::md_metadata Figur 11. 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 Multiplicitet aktualitet sekretessad Det datum datamängden senast befanns vara korrekt. Talar om huruvida en datamängd omfattas av sekretess. : Standardvärde är False [1..1] DateTime [1..1] Boolean

38 Styrgruppen 38 (85) Adress datamängd class Adress_Datamängd «DataSet» SG_Datamängd + aktualitet: DateTime [0..1] + sekretessad: Boolean [0..1] = false «DataSet» SG_AdressDatamängd +representerarsammaföreteelse 0..* 1..* «FeatureType» SG_BasKlass + id: SG_Id [1..2] + beginlifespanversion: DateTime [0..1] + endlifespanversion: DateTime [0..1] + externreferens: SG_ExternReferens [0..*] + aktualitet: DateTime «FeatureType» AR_Kommun - NamnAdressObjekt: AR_NamnAdress [1..*] +tillhörkommun 1 «FeatureType» AR_Adressplats - /adressplatsbeteckning: CharacterString - namnadressobjekt: AR_NamnAdress [0..*] - adressnummer: CharacterString - bokstavstilllägg: CharacterString [0..1] - lägestillägg: AR_Lägestillägg [0..1] - lägestilläggsnummer: Integer [0..1] - adressplatstyp: AR_Adressplatstyp - insamlingsläge: AR_Adressplatspunktläge - avvikerfrånstandarden: boolean - postnummer: Integer [0..1] - postort: CharacterSting [0..1] - giltigfrån: DateTime [0..1] - objektstatus: AR_AdressStatusTyp - geometri: SG_Punkt «FeatureType» AR_GeografiskKommundel - namnadressobjekt: AR_NamnAdress [1..*] - objektstatus: AR_AdressStatusTyp - geometri: SG_Yta [0..1] +liggerinomgeografiskkommundel 1 +hörtilladressområde 1 «FeatureType» AR_Adressområde - namnadressobjekt: AR_NamnAdress [1..*] - giltigfrån: DateTim[0..1] - objektstatus: AR_AdressStatusTyp - geometri: SG_Geometri [0..1] Figur 12.. Adressdata Figur 12 visar hur datamängder med adress enligt denna specifikation sätts ihop. Metadata ska anges på datamängdsnivå. Figur 9 visar hur metadata associeras till en datamängd som följer denna specifikation. Metadata används för att identifiera en datamängd enligt denna specifikation samt beskriver hur datamängden är beskaffad och om den uppfyller denna specifikation.

39 39 (85) Styrgruppen class Adress_översikt Kommun 1 tillhör 1..* GeografiskKommundel Intressepunkt Adressplats 0..* hör till 1 1 ligger inom 0..* Adressområde Gatuadressområde Metertalsadressområde Byadressområde 1 ligger inom 0..* Gårdsadressområde Figur 13. Översikt av informationsmodellen för Adress och Intressepunkt.

40 40 (85) Styrgruppen Adress class Typer_adressområden «DataType» AR_NamnAdress + namn: characterstring + namntyp: AR_NamnAdressTyp + fastställare: AR_NamnAdressFastställare «codelist» AR_AdressStatusTyp - planerad - gällande - avregistrerad «FeatureType» AR_Adressområde SG_BasKlass - namnadressobjekt: AR_NamnAdress [1..*] - giltigfrån: DateTim[0..1] - objektstatus: AR_AdressStatusTyp - geometri: SG_Geometri [0..1] «codelist» AR_NamnAdressTyp + Fastställt kommunnamn + Fastställt namn på geografisk kommundel + Fastställ adressnamn (på adressområde) + Populärnamn (på adressplats) + Namn intressepunkt «codelist» AR_NamnAdressFastställare + Kommun + Lantmäteriet «FeatureType» AR_Gatuadressområde «FeatureType» AR_Metertalsadressområde «FeatureType» AR_Byadressområde +liggerinom 0..1 «FeatureType» AR_Gårdsadressområde Figur 14. Olika typer av adressområden. En belägenhetsadress består av komponenterna kommun, kommundel, adressområde och adressplats som tillsammans bildar en adress. Adressområden kan vara av typen gatuadress, metertalsadress, byadress eller gårdsadressområde. Gårdsadressområden ligger inom ett byadressområde. Ett adressområde ska kunna anges på flera språk; svenska, samiska, meänkieli och finska. Det ska gå att använda våra territoriella minoritetsspråk i adresser.

41 Styrgruppen 41 (85) class Adressplats_Adressområde «FeatureType» AR_Kommun SG_BasKlass - NamnAdressObjekt: AR_NamnAdress [1..*] +tillhörkommun 1 «FeatureType» AR_Adressplats SG_BasKlass - /adressplatsbeteckning: CharacterString - namnadressobjekt: AR_NamnAdress [0..*] - adressnummer: CharacterString - bokstavstilllägg: CharacterString [0..1] - lägestillägg: AR_Lägestillägg [0..1] - lägestilläggsnummer: Integer [0..1] - adressplatstyp: AR_Adressplatstyp - insamlingsläge: AR_Adressplatspunktläge - avvikerfrånstandarden: boolean - postnummer: Integer [0..1] - postort: CharacterSting [0..1] - giltigfrån: DateTime [0..1] - objektstatus: AR_AdressStatusTyp - geometri: SG_Punkt «FeatureType» AR_GeografiskKommundel «FeatureType» AR_Adressområde SG_BasKlass - namnadressobjekt: AR_NamnAdress [1..*] - objektstatus: AR_AdressStatusTyp - geometri: SG_Yta [0..1] +liggerinomgeografiskkommundel 1 +hörtilladressområde 1 SG_BasKlass - namnadressobjekt: AR_NamnAdress [1..*] - giltigfrån: DateTim[0..1] - objektstatus: AR_AdressStatusTyp - geometri: SG_Geometri [0..1] Figur 15. Adressplats relation till Adressområden Geografisk kommundel Kommun. En adressplats hör till ett adressområde. Ett adressområde ligger inom en geografisk kommundel. En geografisk kommundel tillhör en kommun. class Adressplats_fastighet «FeatureType» AR_Adressplats SG_BasKlass «conceptual» Registerenhet +liggerpå 1 +användsav 0..* - /adressplatsbeteckning: CharacterString - namnadressobjekt: AR_NamnAdress [0..*] - adressnummer: CharacterString - bokstavstilllägg: CharacterString [0..1] - lägestillägg: AR_Lägestillägg [0..1] - lägestilläggsnummer: Integer [0..1] - adressplatstyp: AR_Adressplatstyp - insamlingsläge: AR_Adressplatspunktläge - avvikerfrånstandarden: boolean - postnummer: Integer [0..1] - postort: CharacterSting [0..1] - giltigfrån: DateTime [0..1] - objektstatus: AR_AdressStatusTyp - geometri: SG_Punkt Figur 16. Adressplats relation till Registerenhet. En registerenhet kan vara en fastighet eller samfällighet. I nedanstående beskrivning används begreppet fastighet. En fastighet består av en eller flera enhetsområden och/eller enhetsutrymmen. Ett enhetsområde är en vanlig fastighet på marken. Ett enhetsutrymme är 3D-utrymme som urholkar en eller flera enhetsområden. Se figur 15 Ex. Ägarlägenhetsfastighet, Byggnad, Tunnel, Bergrum, Bro och Övrig anläggning

42 Styrgruppen 42 (85) Enhetsområden och enhetsutrymmen identifieras med ett unikt områdesnummer inom fastigheten. 1:1 Figur 17. Enhetsområde (1:1) och enhetsutrymmen (1:3, 1:4, 1:5). En adressplats ska kunna kopplas till flera fastigheter, t.ex. både till markfastigheten och till 3D-utrymmet (ägarlägenhetsfastigheten). Detta uttrycks i informationsmodellen som att 12A ligger på 1:1 och används av 1:3 och 1:4. 12B ligger på 1:1 och används av 1:3 och 1:5. Se figur 15. I normalfallet, dvs. vid 2D-fastighet, ska det inte gå att koppla en adressplats till flera fastigheter pga. kvalitetsaspekten, eftersom det blir svårt att kontrollera kopplingarna maskinellt Intressepunkt class Intressepunkt «FeatureType» AR_Intressepunkt SG_BasKlass - namnintressepunktobjekt: AR_NamnAdress [1..*] - objektstatus: AR_AdressStatusTyp - geometri: SG_Punkt «DataType» AR_NamnAdress + namn: characterstring + namntyp: AR_NamnAdressTyp + fastställare: AR_NamnAdressFastställare «codelist» AR_NamnAdressTyp + Fastställt kommunnamn + Fastställt namn på geografisk kommundel + Fastställ adressnamn (på adressområde) + Populärnamn (på adressplats) + Namn intressepunkt «codelist» AR_NamnAdressFastställare + Kommun + Lantmäteriet Figur 18. Intressepunkt

43 43 (85) Styrgruppen Intressepunkt är ett komplement till adress för att hitta rätt i samhället. Intressepunkt är en lokaliserande plats med punktgeometri som har ett namn som är känt och allmänt använt. Namnet är inte adressgrundande. 5.3 Objekttypskatalog Objekttypskatalogen beskriver vilka objekttyper, attribut, datatyper och kodlistor som ingår för Adress och Intressepunkt. För dessa finns definitioner, beskrivningar och exempel. Efter version 1.0 kommer även regler läggas till. Objekttypskatalogen är sorterad i bokstavsordning. Se Bilaga D. 6 Referenssystem Information om det geodetiska referenssystemet för Adressdata ska anges, referenssystem enligt Fel! Hittar inte referenskälla. är tillåtna (se Figur 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 4. 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:5846 EPSG:5847 EPSG:5848 EPSG:5849 EPSG:5850 EPSG:5851 EPSG:5852 EPSG:5853 Benämning SWEREF 99 TM SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF SWEREF 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

44 44 (85) Styrgruppen EPSG:5854 EPSG:5855 EPSG:5856 EPSG:5857 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 SWEREF RH 2000 Se figur 17 för en karta med de lokala SWEREF 99-zonerna. Temporalt referenssystem Gregorianska kalendern UTC ±0 UTC +1 normaltid (CET) UTC +2 sommartid (CEST) Referenssystemets omfattning Data enligt omfattning A görs i referenssystem SWEREF 99, kartprojektion SWEREF 99 TM (EPSG:3006) och höjdsystem RH 2000 (EPSG:5613). Data enligt delomfattning B, C, D och E 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. Krav 14. Datamängder enligt denna specifikation ska tillhandahållas med referenssystem SWEREF 99 TM och RH 2000.

45 Styrgruppen 45 (85) Figur 19. Rekommenderade lokala SWEREF-zoner för kommuner. Benämning på plankoordinater görs enligt Fel! Hittar inte referenskälla.. Tabell 5 Plankoordinater Koordinatsystem Nordlig koordinat (Northing) SWEREF 99 N E RT 90 x y Östlig koordinat (Easting)

46 46 (85) Styrgruppen I RH 2000 benämns höjden över havet (Normaal Amsterdam Peil) med H. 7 Kvalitetskrav 7.1 Datakvalitet Tabell 6 anger datakvalitetskrav för Adressdata. 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 6. Datakvalitetskrav Nr Kvalitetstema Kvalitetsparameter Kvalitetsmått 1 Fullständighet Datamängdens innehållsmässiga överensstämmelse med geodataspecifikationen; brist eller övertalighet för objekt, attribut eller relationer. Brist För få Omfattning A För bostäder är kravet 100%. Samtliga bostäder ska ha minst en adress. För byggnader med ändamålet Verksamhet, Industri och Samhällsfunktion är kravet 100%. Dessa ska ha minst en adress. 2 Fullständighet 3 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). 4 Logisk konsistens Överensstämmelse med logiska regler för datastruktur, attribut eller relationer (till exempel sammanhängande nätverk och slutna ytor). Datamängdens innehållsmässiga överensstämmelse med geodataspecifikationen; brist eller övertalighet för objekt, attribut eller relationer. Övertalighet För många Konceptuell konsistens Giltiga kombinationer av värden, som stämmer med informationsmodellen. Domänkonsistens Giltig värdemängd. Omfattning A Övertalighet ska inte förekomma. Omfattning A 100 % av förekomsterna ska överensstämma med informationsmodellen. (D.13, Id 13). Omfattning A 100 % av förekomsterna ska överensstämma med värden i kodlistor. (D.17, Id 17).

47 47 (85) Styrgruppen 6 Lägesosäkerhet Noggrannhet/mätosäkerhet i position. Absolut osäkerhet I förhållande till referenssystemet. Omfattning A Adressplatsernas koordinater ska vara unika. Annan adressplats får inte vara belägen inom 1 meter från adressplatsen. Adressplatspunkterna ska ligga i adressplatsens byggnadsyta eller mindre än 10 meter utanför byggnaden. 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. Krav 15. Aktualitet för datamängder enligt denna geodataspecifikation ska anges. Krav 16. 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 Medium Geografiska områden utifrån behov (Web Feature Service)

48 48 (85) Styrgruppen Leveransmedium WMS Indelnings-alternativ 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 Teckenuppsättning Utf Leveransformat Bild (för WMS) Beteckning : Bitmap (rastergrafik) PNG (rastergrafik) Gif (rastergrafik) Jpeg (rastergrafik) Svg (vektorgrafik) Krav 17. WMS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar av denna geodataspecifikation. Rekommendation 1. WFS-tjänster ska kunna tillhandahållas för datamängder enligt samtliga omfattningar av denna geodataspecifikation.

49 49 (85) Styrgruppen 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. 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 Underhåll av data Ajourhållning sker kontinuerligt hos kommunerna i samband med, i första hand, bygglovshanteringen och detaljplanearbete. 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 Mätningsanvisningar HMK Fotogrammetrisk detaljmätning HMK Geodatakvalitet HMK Ordlista HMK Introduktion Svensk standard för belägenhetsadress SS :2015

50 50 (85) Styrgruppen Inspire specifikation för tema Adress 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 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

51 51 (85) Styrgruppen 14 Bilagor 14.1 Bilaga A. Test av specifikationsöverensstämmelse Kommer att utvecklas av mottagande/förvaltande organisation Bilaga B. av UML för informationsmodeller av de i använda modellelementen. Modellerna visualiseras med modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa. Figur 18.Symbol för diagram. Modellerna visualiseras av modellelementen i olika diagram (vyer) utifrån vilken aspekt av temat de ska belysa (Figur 19) 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 19.) 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 19 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 assoclass Beskriv ning av UML Klass 1 +kännertill +kännertill Klass * Klass 2 Figur 19. Klasser, associationer och generaliseringar.

52 52 (85) Styrgruppen ciationen, 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 19) med de gemensamma egenskaperna. De specialiserade klasserna (Klass 2 i figur 19) ä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 20. Attribut, stereotyper, datatyper och kodlistor. Klasser kan ha andra egenskaper än associationer, i figur 20 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 Fel! Hittar inte referenskälla. ä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 20 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 20). 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. vis 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å

53 53 (85) Styrgruppen 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 20) ä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 Svensk geoprocess. <<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 21. 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 21 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. vis så kan inte ett personnummer finnas utan att det finns en person att koppla det till.

54 54 (85) Styrgruppen class Beskriv ning av UML Klass 8 Klass 9 Klass 12 Figur 22. Beroende och realisering Beroende och realisering (figur 22) ä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 Fel! Hittar inte referenskälla. 22 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 23. Paketstruktur i Alla modellelement är indelade i paket (mappar). I förekomer följande paket under huvudpaketet (figur 23, 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., geometrier och identifierare. SG_Temanamn Innehåller den enskilda modellen för varje tema inklusive kringinformation. o TemanamnAnvändningsfall Innehåller användningsfall för aktuellt tema, antingen uppräknade eller