Hantering av remissvar. Svensk geoprocess - Geodataspecifikationer Version 3.0 Test 1

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

2 (164) U t a r b e t a d a v : G o d k ä n d a v : G i l t i g f r å n : 2017-12-15 Innehållsförteckning 1 2 2 BAKGRUND 3 3 ALLMÄNNA SYNPUNKTER 4 4 BASMODELL 27 5 ADRESS 58 6 MARKANVÄNDNING/MARKTÄCKE 74 7 MARKDETALJER 104 8 VATTEN 150 9 VÄG/JÄRNVÄG 161

3 (164) 1 Bakgrund Inom ramen för Samverkan skickades sex geodataspecifikationer samt Basmodell och Mätningsanvisningar i version 3.0 Test 1 ut på remiss under perioden 15 juni till 15 september 2017. De geodataspecifikationer det gällde var: Adress Byggnad Markanvändning/Marktäcke Markdetaljer Vatten Väg/järnväg (i form av Övriga vägar ) Efter hantering av inkomna synpunkter släpptes sedan geodataspecifikationerna för Markanvändning/Marktäcke, Markdetaljer, Vatten och Väg/järnväg i version 3.0 den 1 november 2017, Mätningsanvisningarna den 15 november och Adress den 15 december 2017. 15 januari 2018 kommer version 3.0 av Byggnadsspecifikationen och version 3.1 av Mätningsanvisningarna att publiceras. Detta dokument syftar till att redovisa inkomna synpunkter och hur de hanterats för geodataspecifikationerna gällande: Adress, Markanvändning/Marktäcke, Markdetaljer, Vatten och Väg/järnväg samt andra synpunkter som inkommit. Dokumentet är indelat i separata kapitel för respektive specifikation (eller motsvarande). Därefter finns en underindelning efter den identitet som synpunkten haft vid remisshanteringen, tex Allmänt R1. Under dessa beskrivs sedan inkommen synpunkt eventuella referenser till var i specifikationen synpunkten hänvisar till, eventuellt åtgärdsförslag eller kommentar. Under rubriken Beslut beskrivs sedan hur specifikationsteam hanterat synpunkten.

4 (164) 2 Allmänna synpunkter 2.1 Allmänt R1 2.1.1 Iakttagelse/Synpunkt Då tänkte jag att jag börjar väl med att titta på geometrimodellen, undrar var den finns. I basmodell tror jag så jag sökte efter geometrimodell i det dokumentet ingen träff. Då gick jag till markdetaljer och där fanns en referens till att geometrimodellen fanns i basmodell. Där finns beskrivning av geometri- kanske bra om det på hemsidan står var man hittar information om geometrimodellen. 2.1.2 Åtgärdsförslag kanske bra om det på hemsidan står var man hittar information om geometrimodellen. 2.1.3 Beslut Av det som i testversionen kallades geometrimodell återstår endast några kodlistor och geometrimetadata. 2.2 Allmänt R2 2.2.1 Iakttagelse/Synpunkt Jag gjorde samma sak med XML-scheman, tror att jag sökte i beskrivningen i adress, där finns en länk till XML-scheman finns tillgängliga för tester på hemsida www.lantmateriet.se/svenskgeoprocess. Men när jag följer den hittar jag inga XML-scheman. 2.2.2 Beslut XML-schemana finns på hemsidan. 2.3 Allmänt R3 2.3.1 Iakttagelse/Synpunkt Singular eller Plural / Bestämd eller Icke bestämd form På flera ställen i Geodataspecifikationerna blandar man mellan singular eller plural. På samma sätt blandar man bestämd eller icke bestämd form. Vet inte om det finns något direktiv på vad som ska användas i olika sammanhäng vad gäller namn på t.ex. - Objekttyper - Datatyper - Attributvärden (kodlistor) - mm 2.3.2 Åtgärdsförslag Om inte så tycker jag det borde tas fram en sådan regel och att sen Geodataspecifikationerna kvalitetssäkras utifrån den regeln. Bra också om regels finns dokumenterad i t.ex. Geodataspecifikation Basmodell.

5 (164) 2.3.3 Beslut Översyn har skett avseende modelltekniska begrepp. 2.4 Allmänt R4 2.4.1 Iakttagelse/Synpunkt Prefix, specialtecken och bokstäverna Å, Ä och Ö På samma sätt som ovan för singular och plural i Geodataspecifikationerna behöver det dokumenteras regler (om dessa inte redan finns) för hur - Stora och små bokstäver - Prefix - Specialtecken - Å, Ä och Ö Ska hanteras för t.ex. - Objekttyper - Datatyper - Attributvärden (kodlistor) - mm 2.4.2 Åtgärdsförslag Dessa regler borde också finns dokumenterad i t.ex. Geodataspecifikation Basmodell. 2.4.3 Beslut Översyn har skett avseende modelltekniska begrepp. 2.5 Allmänt R5 2.5.1 Iakttagelse/Synpunkt Ska Kodlistor börja med stor eller liten bokstav På samma sätt som ovan för singular och plural i Geodataspecifikationerna behöver det dokumenteras regler för om kodlistornas attributvärden ska börja med stor eller liten bokstav. I testversionen av Geodataspecifikationen 3.0 är den en blandning av detta beroende på vilken kodlista man tittar på. Dessa regler borde också finns dokumenterad i t.ex. Geodataspecifikation Basmodell. T.ex. så börjar alla kodlistor för GS_StompunktKodlistor med storbokstav medan alla kodlistor för GE_GeometriKodlistor börjar med liten bokstav i UML-modellerna. Viktigt också att det efter koringering också skrivs på samma sätt i UML-modellerna, XSD-schemana, Geodataspecifikationerna och Mätningsanvisningarna. 2.5.2 Beslut Översyn har skett avseende modelltekniska begrepp.

6 (164) 2.6 Allmänt R6 2.6.1 Iakttagelse/Synpunkt, eller. som decimalavskiljare Det bör dokumenteras i t.ex. Geodataspecifikation Basmodell vilken typ av decimalavskiljare som ska användas vid utbyte av data enligt Svensk Geoprocess, om det ska det vara. (punkt) eller, (komma). 2.6.2 Beslut Synpunkten har tagits med i version 3.0 Det är möjligt att vi missat att lägga in detta men det är decimalpunkt som gäller i XML. 2.7 Allmänt R7 2.7.1 Iakttagelse/Synpunkt Olika utbytes-xml:er Vi tror det behövs olika utbytes-xml:er för utbyte av geodata till olika ändamål. Tex skiljer sig behoven väsentligt mellan geodatautbyte mellan olika myndigheter och mellan kommuner till samhällsbyggnadssektorn. Här borde det finnas erfarenheter från Norge och SOSI hur de har hanterat detta. 2.7.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Ingenting har ändrats här. Respektive aktör väljer de delar de utbyter. Eventuellt kommer användningsfall att tas fram under 2018. 2.8 Allmänt R8 2.8.1 Iakttagelse/Synpunkt Deffinering av vilka utbytes-xml som ska användas vid olika tillfällen. För att säkerställa att leveranser till olika ändamål sker enhetligt så behöver Svensk Geoprocess definiera vilka utbytes-xml som rekommenderas för olika ändamål. Exempel på sådana ändamål till samhällsbyggnadsprocessen är bl.a. - Nybyggnadskarta - Grundkarta - Projekteringskarta (här har Trafikverket idag tagit fram en indirekt standard som alla som vill göra uppdrag åt trafikverket måste följa och skulle kunna vara som mall) - mm 2.8.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Ingenting har ändrats här. Respektive aktör väljer de delar de utbyter. Eventuellt kommer användningsfall att tas fram under 2018.

7 (164) 2.9 Allmänt R9 2.9.1 Iakttagelse/Synpunkt Kodlistor i UML-modellerna där detta saknas På flera ställen i UML-modellerna saknas attributvärden för olika kodlistor medan det för andra finns kodlistor. Det vore väldigt önskvärt om det på alla ställen där det finns kodlistor att dessa också finns med i UML-modellerna. 2.9.2 Beslut Original för kodlistor finns i XML-schema. Vi jobbar på att få fram en lösning med ett s k repository för kodlistorna. Beskrivningar av kodlistorna finns i specifikationsdokumenten och UML-schema men några långa kodlistor har inte lagts in i UML p.g.a att vi inte vill underhålla flera original. 2.10 Allmänt R10 2.10.1 Iakttagelse/Synpunkt Tydlig dokumentation av förändringar mellan testversion och kommande skarpa version av Geodataspecifikation 3.0 För att inte leverantörer och användare som påbörjar testarbete utifrån testversion av Geodataspecifikationerna ska riskera att missa någon förändring i samband med att den skarpa versionen av Geodataspecifikationen 3.0 kommer i november är det viktigt att alla förändringar som görs mellan testversion och skarp version dokumenteras och publiceras på ett enkelt och tydligt sätt. 2.10.2 Beslut Vi har försökt att dokumentera de förändringar som gjorts i specifikationerna. 2.11 Allmänt R11 2.11.1 Iakttagelse/Synpunkt Lägesosäkerhet i Plan respektive Höjd Meter eller millimeter Det är viktigt att tydligt definiera i vilken enhet lägesosäkerhet i plan respektive höjd ska anges. Datatekniskt är det en klar fördel om detta kan ändras till millimeter i stället för som det nu är angivet i meter. Anledningen är att det då går att lagra heltal i stället för att behöva hantera tal med decimaler vilket gör lagringen i databasen mycket enklare och mer effektiv. Används heltal (millimeter) så uppstår heller ingen konflikt då en användare ska läsa in geodata utifrån hur decimalkomma redovisas (med. eller, ). Det är också enklare vid hantering av heltal då analyser ska göras, både direkt i databasen eller via GIS-analyser av exporterat data.

8 (164) 2.11.2 Beslut Vi använder SI-enheter (i det här fallet meter) vid utbyte i. Om olika aktörer istället vill lagra informationen i enheten millimeter i sina databaser så står det dem fritt att göra det så länge utbytena via SGP sker i meter. 2.12 Allmänt R12 2.12.1 Iakttagelse/Synpunkt Domäntabell För att värdena för lägesosäkerhet i plan respektive höjd ska bli enkla att ange för användaren vore det bra, ur ett användarperspektiv, om det fanns olika standardvärden i en domäntabell som användes. Förslag till en sådan domäntabell kan vara följande som Topobase Användarförening tog fram 2013 i samråd med Clas-Göran Person på Lantmäteriets Geodetiska enhet. Se PDF-fil i bifogad länk sid 5. 2.12.2 Beslut Vi har valt att inte använda domäntabeller här för att ha en flexibel lösning. 2.13 Allmänt R13 2.13.1 Iakttagelse/Synpunkt InsamlingsMetod För domänvärdena till insamlingsmetod kan jag tycka att det också borde finnas med ett attribut som är: ospecificerad insamlingsmetod på samma sätt som för många andra domänvärdesattribut. 2.13.2 Beslut Ett nytt alternativ annan metod har lagts till. 2.14 Allmänt R14 2.14.1 Iakttagelse/Synpunkt Definition och beskrivning För att inte missförstånd ska uppstå i samband med vad ett attributvärde är för något behöver Definition och beskrivning finnas till alla värden. I testversionen av Geodataspecifikationen 3.0 saknas detta på många ställen. 2.14.2 Beslut Detta är kompletterat.

9 (164) 2.15 Allmänt R15 2.15.1 Referens Allmänt 2.15.2 Iakttagelse/Synpunkt Flera textavsnitt är skrivet som allmän skola om GIS, vad som gäller enligt specifikationen är vagt 2.15.3 Åtgärdsförslag Skriv vad som gäller för Svensk Geoprocess och beskriv processerna utifrån det perspektivet. 2.15.4 Beslut Vi har sett över texter i specifikationer och basmodell. 2.16 Allmänt R16 2.16.1 Referens Flera specifikationer 2.16.2 Iakttagelse/Synpunkt Delar av specifikationerna är skrivna som om det är en databas som beskrivs. Aktörernas underhållsmetoder beskrivs vilket egentligen bör beskrivas hos respektive leverantör. SGP ska vara en specifikation för datautbyte och bara beskriva hur respektive leverantör ska beskriva sin levererade data, se hur Inspire gjort. Om Lantmäteriet skulle ändra något t.ex. flygfotoplan så skulle det med denna lösning även behöva ändras och remissas i SGP! Det är väl inte SGP som beslutat Lantmäteriets flygfotoplan. 2.16.3 Åtgärdsförslag Ta bort kartor med t.ex. flygfotoplan, det ska beskrivas av Lantmäteriet. Beskriv de krav som gäller för SGP-leverans, interna krav får respektive leverantör beskriva i sin specifikation. Behåll de parametrar som ska användas för beskrivning av levererade data. Omfattningskapitlet med delomfattningar kan i vissa fall bli överflödiga. Respektive kommun beskriver sina delomfattningar med deras krav och utfall. 2.16.4 Beslut Vi har gjort en översyn av specifikationerna kring detta.

10 (164) 2.17 Allmänt R17 2.17.1 Referens Alla specifikationer 2.17.2 Iakttagelse/Synpunkt Outnyttjade underrubriker skapar tomrum 2.17.3 Åtgärdsförslag Ta bort outnyttjade rubriker, främst i kapitel 2-4 t.ex. Förkortning, Coverages 2.17.4 Beslut Vi har gjort en översyn av specifikationerna kring detta. 2.18 Allmänt R18 2.18.1 Referens Kap 2.2 och 4 2.18.2 Iakttagelse/Synpunkt Karaktären av sammanfattning är svår att se i kapitel 2.2 2.18.3 Åtgärdsförslag Syfte mm. Ska vi göra en sammanfattning 2.18.4 Beslut Vi har gjort en översyn av specifikationerna kring detta. 2.19 Allmänt R19 2.19.1 Referens Inledning 2.19.2 Iakttagelse/Synpunkt Vs kap 1. Hur mycket ska det stå egentligen 2.19.3 Åtgärdsförslag Diskutera om helheten ska brytas ut och en kortare sammanfattning presenteras i respektive temadokumentation. Ursprungligen var nog syftet att alla teman skulle stå för sig självt.

11 (164) 2.19.4 Beslut Vi har gjort en översyn av specifikationerna kring detta. 2.20 Allmänt R20 2.20.1 Referens Allmänna beskrivningar 2.20.2 Iakttagelse/Synpunkt Beskrivande texter innehåller många negationer, exempel: Då man inte hanterar ytor utan linjer som geometrisk representation för ytutbredda företeelser i verkligheten så förekommer kantlinjer ofta tillsammans med en centroidpunkt och topologier för att avgränsa en företeelses utbredning (mätanv kap 5) 2.20.3 Åtgärdsförslag Beskriv istället de 2 varianterna som är godkända var för sig som 2 likvärdiga alternativ. 2.20.4 Beslut Vi har gjort en översyn av specifikationerna kring detta. 2.21 Allmänt R21 2.21.1 Iakttagelse/Synpunkt Hur hantera centroid plus kantlinje vid ett klippt uttag ur databas där alla kantlinjer inte följer med eller att t o m centroiden inte följer med. Frågan blir aktuell främst för marktäcke där det är krav på heltäckande ytor. 2.21.2 Beslut Ej åtgärdat. Detta är inte en specifikationsfråga i första hand utan måste hanteras av aktörerna vid export av data. 2.22 Allmänt R22 2.22.1 Iakttagelse/Synpunkt Bör det framgå någonstans i XML-filerna vid överföring vilken specifikationsversion man baserar överföringen på? 2.22.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Ej infört.

12 (164) 2.23 Allmänt R23 2.23.1 Iakttagelse/Synpunkt Önskemål om publicerade kodlistor så att de som ska använda SGP inte behöver klippa och klistra för att få in dom i sina egna system. 2.23.2 Beslut Kodlistor finns som XML-schema på SGP:s hemsida. 2.24 Allmänt R24 2.24.1 Iakttagelse/Synpunkt I Stockholms anläggningsregister för Park använder vi samlingsnamnet VA-anläggning där exv. fontän är en detaljtyp. I Stockholm finns en hel del plaskdammar och växtdammar och dessa har egna detaljtyper under VA-anläggning. I markdetaljspecifikationen finns inte denna typ av dammar nämnda och i markanvändningsspecifikationen omnämns endast damm som ngt som är skapat för rening eller magasinering av vatten. I markanvändningsspecifikationen nämns bassängbad och simbassäng men inte heller här ser jag att plaskdammar hör hemma då bassängbad ska ha iordningsställd service exv. badbrygga, livboj, toalett. Detta finns oftast inte vid plaskdammar. Hur kan plaskdammar hanteras i specifikationen? 2.24.2 Beslut Detta är åtgärdat. 2.25 Allmänt R25 2.25.1 Iakttagelse/Synpunkt Det huvudsakliga var att man ville att alla teman som de var intresserade av skulle ha ansvarig organisation och geodataproducent på varje objekt. Ansvarig organisation finns på geometrimetadata. Man föreslog att geodataproducent också skulle finnas som ett attribut där. Det var mkt viktigt att kunna spåra detta på varje enskilt objekt vid utbyte med projektörer. 2.25.2 Beslut Geodataproducent tillagt i Geometrimetadata. 2.26 Allmänt R26 2.26.1 Iakttagelse/Synpunkt Yttrande över Remiss på geodataspecifikationer och mätningsanvisningar 3.0 TEST framtagna inom Samverkan Naturvårdsverket har tagit del av Remiss på geodataspecifikationer och mätningsanvisningar 3.0 TEST framtagna inom Samverkan via det utskick som

13 (164) gjordes den 15:e juni. Den 30:e juni publicerade Lantmäteriet specifikationerna för Övrig väg på sin hemsida där bland annat information om leder ingår. Naturvårdsverket uppmärksammade denna för sent för en detaljerad genomgång men har inkluderat vissa övergripande kommentarer. De specifikationer som remissen avser är väldigt detaljerade. Det har därför varit svårt för Naturvårdsverket att under den korta remisstiden hinna granska, testa och lämna kommentarer på en detaljerad nivå. Därför är Naturvårdsverket remissvar på en relativt generell nivå. För några av de specifikationer som har presenterats i remissen så ser vi det som väldigt viktigt att det finns en fortsatt dialog kring användningen av dessa specifikationer och vi deltar gärna i ett sådant arbete. Synpunkter Naturvårdsverket har granskat specifikationerna för Byggnader, Markdetaljer, Marktäcke/Markanvändning och Övrig väg eftersom myndigheten producerar data inom dessa teman. Byggnader De data som Naturvårdsverket producerar och ajourhåller inom tema byggnader har en väldigt översiktlig beskrivning (oftast en 2D-punkt eller i vissa fall en 2D-yta för läget och en kod för typen av byggnad). Vår bedömning är att specifikationen kan användas om det blir aktuellt för Naturvårdsverkets att leverera data t ex för vindskydd och raststugor. Markdetaljer Exempel på data inom tema markdetaljer som Naturvårdsverket tillsammans med länsstyrelserna samlar in och ajourhåller är torn, informationstavla och lekredskap. Naturvårdsverkets representation av dessa data är mer förenklad än den som beskrivs i svensk geoprocess och därför förordar vi färre obligatoriska attribut. Om de obligatoriska attributen begränsas till typ av markdetalj och geometri (2D-punkt, -linje, eller yta) kan Naturvårdsverket leverera data enligt specifikationen. Naturvårdsverket har inga planer att utöka insamling och ajourhållning med t ex bredd och höjd. Markanvändning/marktäcke För marktäcke är Naturvårdsverkets synpunkt att det behövs en nationell samsyn kring kodlistan i svensk geoprocess och Nationella Marktäckedata (NMD). NMD har en hierarkis indelning som är heltäckande men inte överlappande. Det finns pågående regionala projekt som utreder hur NMD kan detaljeras ytterligare både vad avser indelning och upplösning. Den kodlista som presenteras i remissen går inte att mappa till eller från NMD varför vi föreslår att det görs en särskild studie med målsättning att få en bättre harmonisering. Naturvårdsverket föreslår att denna genomförs inom ramen för det projekt som producerar Nationella Marktäckedata. Övrig väg Specifikationen för Övrig väg har jämförts med de specifikationer som Naturvårdsverket har för att tillhandahålla öppna data kring leder inom skyddade områden och statliga leder i fjällen. Här finns vissa skillnader som behöver åtgärdas för att ett datautbyte ska kunna ske enligt Lantmäteriets specifikation. Naturvårdsverket föreslår därför en gemensam genomgång och jämförelse av kodlista och attribut samt en test av datautbyte. Generella synpunkter för framtida arbete Som nämnts ovan så deltar gärna Naturvårdsverket i tester kring utbyte av information inom tema markanvändning och övrig väg.

14 (164) Beslut om detta yttrande har fattats av enhetschef Anna Otmalm. Vid den slutliga handläggningen har deltagit handläggare Birgitta Olsson och Johan Wulff. Bilaga: Ifylld mall: Iakttagelser vid granskning av dokument från 2.26.2 Kommentar Åsa: De specifika delarna är även inkopierade i BY, MA/MT, ML och Övrig väg 2.26.3 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Fortsatt dialog mellan SGP och Naturvårdsverket. 2.27 Allmänt R27 2.27.1 Iakttagelse/Synpunkt Enligt remissen ska företeelser ha samma identitet under hela sin livstid. Däremot beskrivs inte tydligt vad som händer om en företeelse förändras och hur ändringshistoriken då ska hanteras. 2.27.2 Beslut Basmodellen har kompletterats med text kring detta. 2.28 Allmänt R28 2.28.1 Iakttagelse/Synpunkt Önskar utökad remisstid för Markdetalj/Markanvändning och Marktäcke Genom att Markdetalj/Markanvändning och Marktäcke håller på att omarbetas så vill vi ha möjlighet att lämna ytterligare synpunkter på dessa två geodataspecifikationer efter att vi har erhållit ny utgåva. 2.28.2 Beslut Allmän kommentar som inte föranlett någon ändring i specifikationer.

15 (164) 2.29 Allmänt R29 2.29.1 Iakttagelse/Synpunkt Vi på Symetri har gjort en del generella ställningstaganden utifrån hur vi kommer bygga vår databasmodell mot Svensk Geoprocess. Dessa är bl.a.: LeveransId Vi kommer inte lagra leveranser i databasen. Detta innebär att leveransid heller inte kommer lagras utan enbart följa med XML-filen som ett unikt id. RelatedParty För RelatedParty kommer vi i vår databasmodell endast att lagra organisationname. Inga andra attribut. SG_Projekt För Höjd och Stompunkt kommer vi med största sannolikhet inte lagra något om Projekt. Då vi skapar XML-filer kommer då dessa attribut få värdet nilible 2.29.2 Beslut Allmän kommentar som inte föranlett någon ändring i specifikationer. 2.30 Allmänt R30 2.30.1 Iakttagelse/Synpunkt Vi från Symetri vill lämna följande kommentar kring den information som nått oss att man funderar på att göra ytterligare anpassningar av geodataspecifikationerna mot Inspire: Utan att ha frågat några andra leverantörer så tror vi våra synpunkter nedan är rätt samstämmiga. Om vi inte nu till skarp version 3.0 får en BAS-modell där geodataspecifikationerna i sin struktur kommer hålla flera år framåt så kommer vi leverantörer inte våga gå in i Svensk Geoprocess. Vi på Symetri har nu satsats stora resurser på flera versioner av Svensk Geoprocess (1.0, sen 2.0 och ny test 3.0) utan att än så länge få tillbaka en enda krona. Kommer inte den skarpa version som vi håller på att tas fram, oavsett om den kommer heta 3.0 eller något annat, bli en stabil version som man kan lita på håller ett antal år, utan man i stället ska börja göra förändringar direkt i dessa för att anpassa dem till Inspire så kommer vi från Symetri att backa ur alla projekt kring Svensk Geoprocess och inte ta fram någon databasmodell innan dess att det visar sig att det finns en pålitlig version av Svensk Geoprocess på plats som kommer hålla långsiktigt. Att några attributvärden till befintliga attribut kommer att komma till eller försvinna är vi fullt medveten om och detta är inga svårigheter för oss leverantörer eller kunder att hantera. Däremot om det kommer ny struktur med nya attribut för att klara en anpassning mot Inspire efter att version 3.0 är spikad så är jag mycket rädd för att trovärdigheten i Svensk Geoprocess är sänkt till botten och inga leverantörer kommer våga satsa på en implementering. Detta får bara inte ske för Sverige behöver en enhetlig struktur av Geodata och det nu.

16 (164) 2.30.2 Beslut Vi har gjort vårt bästa för att få fram så stabila versioner vi kan. Sen kommer vi ändå att behöva släppa nya versioner för att rätta felaktigheter, uppdatera kodlistor mm som upptäcks när specifikationerna börjar användas. 2.31 Allmänt R31 2.31.1 Iakttagelse/Synpunkt Vi har två viktiga övergripande synpunkter som vi vet att vi delar med många andra kommuner. 1. Alla kommuner använder byggnader och vägkanter. Det måste vara jättetydligt hur de två sakerna ska utbytas. Vi vill jättegärna att vägkanter hör till specifikationen vägjärnväg eftersom det är logiskt att välja den specifikationen för vägkanter. Viktigt att det är tydligt hur man utbyter byggnader i olika LOD-nivåer. LOD0 är ju den som är aktuell för alla än så länge. 2. Vad blir svårigheten om man kan använda olika mätlägen i höjd vid utbyte? Det ser så olika ut vad man utbyter och hur mycket höjdinformation man behöver ha med. Vi ser det som det viktiga är att man kan ange mätläge för höjden. Vi kanske inte förstår, vi har ju inte utbytt så mycket 3D-modeller än. Det vi tänker börja med att utbyta är ju byggnader och då känns det väldigt oklart vad som är SGP:s rekommendation hur man ska göra för LOD1 - LOD3 Skickar med våra synpunkter på specifikationerna för adress och marktäcke/markanvändning och sedan synpunkter på mätningsanvisningar. Där har vi ju svarat flera gånger förut så nu har vi koncentrerat oss på byggnad och marktäcke/markanvändning. 2.31.2 Beslut Vägkanter kommer även fortsättningsvis tillhöra markdetaljer, vägar i allmänhet hänvisas till NVDB enligt styrgruppsbeslut 2016. Dock hanterar inte NVDB vägkanter på samma sätt. 2.32 Allmänt R32 2.32.1 Iakttagelse/Synpunkt Saknar exempel på hur datautbyte konkret ska ske. Saknar koppling till en tänkt specifikations-/produkthierarki till vilken man kan passa in olika behov/produkter mot olika nivåer. Exempel: På grundnivå hanterar vi bara höjder, på en nivå högre upp kan vi förädla höjd till djup om det efterfrågas. Olika produkter på olika nivåer men samma data i botten. Var hör hemma? 1 eller flera nivåer? 2.32.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Frågan behöver utredas vidare.

17 (164) 2.33 Allmänt R33 2.33.1 Iakttagelse/Synpunkt Här kommer en allmän synpunkt från mig. Det gäller generella termer som finns i specifikationerna. - Begreppsmodell - Informationsmodell Just när det gäller dessa termer vore det bättre att använda definitioner som finns i Rikstermbanken respektive i Ekvator (som hanterar geodatatermer hos SIS). Synpunkt: En informationsmodell är inte en begreppsmodell Definition enligt Rikstermbanken som också används av e-delegationen Begreppsmodell grafisk representation av relationerna mellan begreppen i ett sammanhängande begreppssystem Informationsmodell grafisk beskrivning av de informationsobjekt en viss verksamhet behöver och hur de relaterar till varandra Båda dessa modeller är till för att kunna läsa och förstås av människor. - Begreppsmodellen är till för att förstå hur relationer mellan begrepp ser ut, i de fall de behöver redas upp. Kan vara en delmängd av det som verksamheten hanterar. En begreppsmodell har inte klasser med attribut, utan visar relationer till relevanta begrepp, som kan vara egenskaper. Även värden i värdemängd hanteras som begrepp i en begreppsmodell. - Informationsmodellen däremot avgränsar och omfattar all information som verksamheten hanterar. Här förekommer objekttyper inklusive relationer samt attribut med tillhörande värdemängder. 2.33.2 Beslut Vi använder Informationsutbytesmodell i SGP. 2.34 Allmänt R34 2.34.1 Iakttagelse/Synpunkt Boverket tolkar att samverkan svensk geoprocess handlar om att standardisera utbytet av grundläggande geodata för baskartor, huvudsakligen mellan Lantmäteriet och kommunerna, men anser att utbytesspecifikationerna inte bara handlar om utbyte mellan dessa aktörer. Boverket är öppen för att ta en mer aktiv roll framöver för att bättre kunna ge mer heltäckande återkoppling vid revideringar av specifikationerna som vi kan komma att beröras av eller har något indirekt ansvar för. Sannolikt handlar det då i första hand om teman markanvändning, vatten, byggnad, adress och markdetaljer. 2.34.2 Beslut Allmän kommentar som inte föranlett någon ändring i specifikationer.

18 (164) 2.35 Allmänt R35 2.35.1 Iakttagelse/Synpunkt Omfattning med specifikationerna Målet med SGP är enligt specifikationerna att man ska 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. En fråga blir då omfattningen av SGP (huvudsakligen leveransformat eller en mer komplett geodataspecifikation (enligt ISO 19131) samt relationen till HMK (och avtal). SGP:s inriktning känns lite oklar och läsaren får olika besked om omfattningen. I SGP:BY, sid 61 står det: Svensk Geoprocess som koncept ställer inga krav på innehållet i leveranserna. På följande sidor finns dock en tabell som innehåller en del kvalitetskrav. Vidare innehåller specifikationerna flera krav på vilka referenssystem som ska användas, t.ex. SGP:BA, sid 23 För höjd innehåller kodlistan GE_Höjdsystem bara värdet RH 2000 som är det gällande höjdsystemet för Svensk Geoprocess samt SGP:BY sid 67 Kontrollera att datamängden är levererad enligt tabell 5 - tillåtna koordinatsystem (SWEREF 99 TM inkl. lokala zoner och RH 2000). I Mätanvisningarnas kapitel 1.1 framgår förvaltar och utvecklar geodataspecifikationer, mätanvisningar och XML/GML-scheman för datautbyte. Dataägaren ansvarar för datalagring samt att kunna leverera och ta emot geodata enligt specifikationer. ställer inga krav på hur insamlingen utförs, hur data ska lagras eller att bara utbytesmodell ska användas vid utbyte. Detta stycke indikerar att man avser en komplett geodataspecifikation med mera för datautbyte. Den sista meningen talar om vad man inte ställer för krav. Den bör kompletteras översiktligt med vad man ställer för krav på leveransen i form av standardiserade kodlistor och tillåtna värdemängder med mera. 2.35.2 Åtgärdsförslag Rekommendation Mer tydlighet önskas om SGP framförallt syftar till att bara vara ett utbytesformat eller om det ska vara en komplett geodataspecifikation med tillhörande mätanvisningar, utbytesformat och processbeskrivningar för användningsfall som nämns i målet ovan. De olika dokumenten behöver ensas så att omfattningen blir tydlig och enhetlig i alla dokument. Det bör också framgå att krav ställs på leveranserna bl a i form av tillåtna värdemängder på olika attribut som referenssystem, datakvalitet, lod-nivåer, kod-listor med mera. Vi tycker att specifikationerna i svensk geoprocess ska ligga till grund för indirekt styrning av innehåll i kommunala geodatabaser (primär-/baskartor) - och på så vis vara ett stöd enligt de förslag som anges i rapporten DIGITALT FÖRST: Föreskrifter om gemensamma standarder för information i grundkartor. Vi kan dock konstatera att viktig information i en grundkarta rörande fastigheter, rättigheter och bestämmelser (Gränser och beteckningar för fastigheter och samfälligheter, Områden för servitut och nyttjanderätt samt Områden för planer och markreglerande bestämmelser) samt övriga administrativa gränser inte ingår i SGP för närvarande. I slutrapporten från SGP hänvisas till samarbetet med företrädare för projektet SPF sammanhållen detaljplane- och fastighetsbildningsprocess som resulterade i förslaget

19 (164) att även genomföra temauppdrag för planer, rättigheter och bestämmelser på liknande sätt som i. Men som vi förstått det har det inte tagits fram några specifikationer eller liknande för detta ännu. SPF-projekt lades ner 2014 och ersattes av dpbl, digitalt sammanlänkad plan- och bygglovsprocess. 2.35.3 Beslut Vi har försökt att ensa specifikationerna. I dagsläget är SGP:s specifikationer anpassade för utbyte av data. 2.36 Allmänt R36 2.36.1 Iakttagelse/Synpunkt Kopplingen mellan SGP:BY och Inspire känns oklar. På SGP:BY står det att 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. Ur en praktisk synvinkel vore det intressant att veta om SGP:BY följde direktivets regler för hur en informationsmodell får utökas, detta eftersom det avgör om en informationsansvarig organisation måste använda dubbla tjänster (en SGP-tjänst och en Inspiretjänst). Ett exempel där SGP:BY inte följer Inspire är att geometrin i SGP:BY endast finns på Byggnadsdel och inte på Byggnad (SGP:BY, sid 33-34). 2.36.2 Åtgärdsförslag Detta bör tydligt framgå i specifikationerna om SGP-temat följer Inspire-direktivets krav för hur utökning av en Inspire-specifikation får gå till. Vidare bör det utredas vilka konsekvenser det skulle få om alla SGP-teman (som har motsvarighet i Inspire) gjordes om till godkända Inspire-utökningar. En tydlig beskrivning för tillägg och avsteg bör framgå i geodataspecifikationerna och inte bara generella uttryck som följer Inspire i möjligaste mån osv. 2.36.3 Kommentar Se Byggnad R40 2.36.4 Beslut En utredning om detta har gjorts och efter beslut så blev det så att Byggnad och Adress av kostnadsskäl inte följer Inspires regler för hur utökning får gå till men har en Inspire-liknande struktur. Markanvändning/Marktäcke, Vatten, Bild och Höjd-specifikationerna är dock gjorda som utökningar av Inspire. 2.37 Allmänt R37 2.37.1 Iakttagelse/Synpunkt Generellt ser vi att det är av vikt att specifikationerna formas för att främja en fortsatt utveckling, en utbyggnad och komplettering med ytterligare datateman. Detta för att göra dem brett användbara, och inte endast inom samhällsbyggnadssektorn. De är en värdefull grund att bygga vidare på.

20 (164) 2.37.2 Beslut Allmän kommentar som inte föranlett någon ändring i specifikationer. 2.38 Allmänt R38 2.38.1 Iakttagelse/Synpunkt Generella synpunkter Materialets omfattning gör det svårt att få en överblick på innehållet. En första fråga att ställa sig är vilken status dessa specifikationer och anvisningar kommer att få. Vad kan bli styrande/tvingande och vad är bara ett stöd för datafångst, datautbyte och datalagring. Enköpings kart- och GIS-avdelning anser att geodataspecifikationerna ska täcka in alla tänkbara företeelser och därtill hörande geometriska representationer för grundläggande geodata. Med alla tänkbara menar vi att alla geodata inom i utvalda teman som behöver hanteras i det offentliga uppdraget hos kommuner och lantmäteri behöver specificeras. Sedan är det så att andra nödvändiga teman såsom fastighetsinformation och detaljplaner främst, också behöver standardiseras. Det är även så att verksamhetsspecifika data ska kunna kopplas till de data som ingår i. Det kan dessutom finnas behov av att mäta in detaljer som inte är beskrivna i mätningsanvisningarna. En fråga som är av stor vikt är om det kommer att bli författningsreglerat att någon organisation läs lantmäteriet eller någon annan - kan föreskriva kommunerna att ta fram vissa geodata enligt specificerade SGP- standarder. Likaså kan frivilliga avtal tecknas där vi binder oss att leverera geodata enligt SGP-standard. Det står att det bara är datautbytet som är standardiserat och i vissa delar tvingande, men i praktiken måste data från början i källsystemet bära på nödvändig information. Eftersom SGP inte modellerar data utifrån verksamhetsprocesser är det svårt att säga om dessa grunddata är tillräckliga att bygga vidare på i olika verksamhetstillämpningar. Det är också en fråga att ställa sig hur ofta vektordata med egenskaper behövs. Ofta räcker det att ha vissa grunddata som bilder i en bakgrund till verksamhetsdata. I de fallen kan WMS-tjänster tillhandahållas. För andra data kan WFS-tjänster användas istället för omfattande filer som tillverkas med XML-scheman. Likaså kommer säkert andra dataformat att användas under lång tid framöver när det är det för tillfället enklaste sättet att utbyta data. Val av datautbytesmetod styrs av behoven och i det ligger t ex om data ska hanteras kort eller lång tid och om de ska kunna utbytas i flera led. Möjligheten till XML-standard är dock viktig. 2.38.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Denna fråga behöver utredas vidare. 2.39 Allmänt R39 2.39.1 Iakttagelse/Synpunkt Klassificering av data En viktig förutsättning är vilken kvalitet och struktur som geodata har i nuvarande system hos kommuner och andra organisationer. De flesta av landets kommuner har sina primärkartedata inmätta i plan. Även dessa data behöver kunna utbytas enligt SGP-

21 (164) standard. Det behövs därför en kvalitetsnivå mellan nivå ett och två. Data i nivå två ska som regel även innehålla uppgift om höjd, vilket oftast inte finns. Även om höjdsatta data kan vara en långsiktig ambition bör det gå att standardisera utbyte av 2-dimensionella data. HMK-standardnivåer enligt följande är inte en lämplig klassificering: 1. Nationell/regional mätning och kartläggning 2. Mätning och kartläggning av tätort 3. Projektinriktad mätning och kartläggning Klassificeringen borde kunna kallas kvalitetsnivåer 1-4 och mer spegla vilket resultat man vill uppnå för färdigbearbetade data. Kvaliteten visar noggrannhet och geometrisk representationsnivå. Det är missvisande att utgå från om syftet är nationellt eller lokalt i tätort eftersom kvalitetskraven kan variera. Även nationella data kan delvis få samma kvalitet som i tätort. 2.39.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Detta är en fråga som behöver utredas vidare. 2.40 Allmänt R40 2.40.1 Iakttagelse/Synpunkt Kompletteringar av standarden Det står att SGP och mätningsanvisningarna inte tar med projektinriktad mätning. Det kan vara svårt att förutse alla tänkbara behov. Datautbyte är dock lika viktigt för projekt. Om det visar sig att datautbyte behövs för några vanliga typfall borde standarden kunna kompletteras i framtiden. Överenskommelser bilateralt att använda XML kan kanske leda till standardisering senare. Specifikationerna för SGP kan kanske jämföras med överföringsstandarden för arkivdata FGS (förvaltningsgemensamma specifikationer). FGS:er ska kunna anpassas till olika leveransfall vilket också borde kunna vara fallet med XML-filer inom SGP-struktur. 2.40.2 Beslut Mätningsanvisningarna syftar främst till att beskriva hur geodata ska representeras vid utbyte varför de även bör kunna användas vid projektinriktad mätning. Vid utbyte via XML är det möjligt att anpassa innehållet för olika typer av leveransfall. 2.41 Allmänt R41 2.41.1 Iakttagelse/Synpunkt Datakvalitet och verksamhetsanpassning För att SGP ska bli vad vi alla hoppas på krävs det att de data som lagras, och sedan kan utbytas mellan olika verksamhetsprocesser, håller en tillräckligt hög kvalitet i form av geometrisk noggrannhet, fullständighet och aktualitet. Detta blir den stora utmaningen för de flesta kommuner. Det är viktigare att ha en god heltäckande kvalitet i två dimensioner än att ha tredimensionella data som inte kan underhållas. 3D-data kan med fördel användas projektvis och utbytas enligt standarden. Först när efterfrågan

22 (164) kräver det är det motiverat att ha en heltäckande redovisning i 3D. Förutsättningarna är mycket olika i olika kommuner. 2.41.2 Beslut Allmän kommentar som inte föranlett någon ändring i specifikationer. 2.42 Allmänt R42 2.42.1 Iakttagelse/Synpunkt Standard för kartmanér Ett område som också behöver standardiseras är kartmanér. För att kunna förstå en karta som är den vanligaste presentationen av geodata behöver en tydlig och standardiserad kartografi tas fram för ett antal vanliga kartprodukter såväl digitalt som analogt. 2.42.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Allmän kommentar som inte föranlett någon ändring i specifikationer. 2.43 Allmänt R43 2.43.1 Iakttagelse/Synpunkt Finansiering och implementation Avgörande för ett införande av SGP frivilligt eller tvingande är att det ges rimlig tid och tillräcklig finansiering. För detta måste staten dedicera medel till kommunerna. Det är ett nationellt intresse som inte kan finansieras av kommunerna själva. Det är också nödvändigt att lantmäteriet tar täten och inför SGP. 2.43.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Allmän kommentar som inte föranlett någon ändring i specifikationer. 2.44 Allmänt R44 2.44.1 Iakttagelse/Synpunkt Här kommer utarbetat förslag på hur vi skulle vilja att kodlistan för specifikationerna skulle kunna se ut och hur också en koppling mot mätningsanvisningarna skulle kunna vara gjord. Jag bifogar också den kodlista som Peter idag själv har byggt upp (observera att den inte är 100% komplett eller kvalitetssäkrad) för att få ytterligare exemplet på hur den kan se ut samt få en förståelse för hur mycket dubbeljobb det skulle vara för alla olika inblandade att själva bygga något liknande och hur stor felkällan är att det inte blir lika över allt.

23 (164) Som jag sa så tror jag alla inblandade skulle ha stor nytta av detta arbete för att slippa dubbeljobb och risk för fel. T.ex. bara detta med att UML XSD Geodataspecifikationerna inte ska misstämma mellan varandra. En viktig synpunkt som Peter framförde är att det ur en programmeringstekniks synvinkel är viktigt att är viktigt att det går att exportera informationen från en databas om man väljer den typen av lösning. Skulle det visa sig att en databaslösning är det bästa men inte genomförbar idag pga IT-resurser saknas så hoppas jag ändå man kan påbörja arbetet enligt någon typ av den som bifogas så att vi stärker kvalitén och vet vilken källa som är den rätta om det skulle vara så att det framöver misstämmer mellan olika delar. Och då tycker jag excel är en mycket bättre lösning än tabeller i ett wordformat så att det i framtiden gan exporteras till en databas när tiden är moden för det. 2.44.2 Kommentar Se bifogade filer i LÄNKEN. 2.44.3 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Kodlistornas original finns i XML-scheman. Vi jobbar också på en lösning för att istället kunna publicera kodlistorna i ett s k Repository. 2.45 Allmänt R45 2.45.1 Iakttagelse/Synpunkt Nivåer av stöd av svensk geoprocess Det behövs tas fram en matris för vad som är minimikrav (och ev. olika nivåer) för att man ska kunna säga att man som kommun kan leverera och ta emot enligt Svensk Geoprocess. T.ex.: För många alternativ av leveransformat. 6st listas. Det borde finnas ett format, för att följa standard. Som det är nu med 6 listade format så om en leverantör implementerar DWG/DXF så stödjer de svensk geoprocess, men om en annan stödjer CityGML så stödjer de också SGP, dock kan inte informationen mellan de utbytas. Standarden borde nämna ett specifikt format som ska stödjas. Likadant vad gäller olika leveransmodeller av byggnaders LOD-information a, b, c. Vilken ska kommunerna leverera enligt? Alla? En, i så fall vad händer om olika leverantörer stödjer olika leveransmodeller? 2.45.2 Beslut Leveransformaten var felaktiga i testversionen och har ensats till XML. Vad som ska utbytas är upp till de parter som utbyter data att komma överens om.

24 (164) 2.46 Allmänt R46 2.46.1 Iakttagelse/Synpunkt Måluppfyllnad Ett av målen är att effektivisera och sänka kostnader för kommunerna. Är det gjort eller kommer det göras en analys för hur mycket det kommer kosta kommunerna att underhålla all data? Är det kommunicerat med kommunerna hur mycket deras kostnader kommer öka/minska genom att använda Svensk Geoprocess i olika nivåer (t.ex. mycket mer kostsamt att underhålla data på LOD3 än LOD2, eller alla detaljer för stompunkter, men sparar in kostnader vid framtagande och leverans av tema till kund)? 2.46.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Det är inte gjort någon analys på detta och är inte inplanerat på kort sikt. 2.47 Allmänt R47 2.47.1 Iakttagelse/Synpunkt Upplösningen på UML-diagrammen i PDF er måste vara hög nog att vara tydliga, för läsbarhet. 2.47.2 Beslut UML-scheman finns tillgängliga separat på hemsida. Vi har också bytt bildformat i specifikationsdokumenten som ska ge tydligare bilder vid skapande av pdf-filer. 2.48 Allmänt R48 2.48.1 Iakttagelse/Synpunkt Ska Svensk Geoprocess införas som standard i Sverige måste kvaliteten på t.ex. beskrivningar förbättras. T.ex. beskrivningarna av termer rörande 2D, 2.5D och 3D, är inte korrekt beskrivna. 2.48.2 Beslut Komplettering av definitioner har skett.

25 (164) 2.49 Allmänt R49 2.49.1 Iakttagelse/Synpunkt Flytta ut all generell information från varje geodataspecifikation till ett eget generellt dokument, på samma sätt som gjorts för gemensamma klasser i XSD. Detta för att förenkla läsbarhet, undvika dubblering och risk för inkonsekvens mellan samma tänkta beskrivning i olika dokument. 2.49.2 Beslut Den Basmodell som tagits fram är en del i detta för att förenkla läsandet. Sen är det en avvägning hur mycket information som ska ligga i respektive specifikation och i Basmodellen. 2.50 Allmänt R50 2.50.1 Iakttagelse/Synpunkt Kodlistor med en kod som har två värden, där ska värdena inte avgränsas med / utan stå som och eller eller. Är det få värden i kodlistan så utöka den hellre. T.ex. rondell/mot är två olika saker och borde finnas som två koder. 2.50.2 Beslut Vi har försökt att se över samtliga kodlistor. 2.51 Allmänt R51 2.51.1 Iakttagelse/Synpunkt Värden ska vara giltiga för hela Sverige. T.ex. mot är en västsvensk eller österbottnisk term, med två skilda betydelser. I resten av Sverige är den väldigt ovanlig. 2.51.2 Beslut Vi försöker vara universella. 2.52 Allmänt R52 2.52.1 Iakttagelse/Synpunkt Numrera kraven. I t.ex. Adress är kraven onumrerade. 2.52.2 Beslut Fixat.

26 (164) 2.53 Allmänt R53 2.53.1 Iakttagelse/Synpunkt Hur hantera koder som tas bort? Ska kod matchas till något annat, obestämd eller vilket värde? Detta behöver beskrivas eftersom kommunerna redan har vissa värden i sina system som kanske inte finns i Svenska Geoprocess och därför måste kopplas annorlunda. 2.53.2 Beslut Synpunkten har inte tagits med i version 3.0 men kommer att utredas mer inför kommande versioner. Vi har ingen hantering av detta i nuläget. 2.54 Allmänt R54 2.54.1 Iakttagelse/Synpunkt Hur hantera så att information lagras i rätt objektklass, med tanke på överlapp av olika objektklasser i olika tema - att en viss objektklass kan förekomma i flera teman? Regler för detta måste sättas upp inom Svensk Geoprocess. 2.54.2 Beslut SGP hanterar utbyte och inte lagring av geodata. Dock har vi försökt att minimera överlapp mellan teman. Genom att varje objekt som utbyts ska ha ett unikt ID bör det vara möjligt för aktörerna att hantera lagringen. 2.55 Allmänt R55 2.55.1 Iakttagelse/Synpunkt Test av specifikationsuppfyllelse Punkten Samverkan om utökning av kodlistor - detta har inte med test av specifikationsuppfyllelse att göra. Det står redan i punkten Kontrollera att datamängdens värden överensstämmer med de värden som är uppräknade i värdelistor. 2.55.2 Beslut Vi anser att den ska vara kvar. 2.56 Allmänt R56 2.56.1 Iakttagelse/Synpunkt Krav 6 definiera vilka intressenterna är. Detta bör vara kommuner, myndigheter, räddningstjänst och liknande, som föreslår till Svensk Geoprocess, ej via Leverantörerna. Leverantörer däremot troligtvis vara med som granskare. Det behöver nämnas hur att utöka nya kodlistor. Bör ske i samförstånd med Lantmäteriet? En bestående grupp inom Svensk Geoprocess? Beskriv denna process.

27 (164) 2.56.2 Beslut Texten är kompletterad. 2.57 Allmänt R57 2.57.1 Iakttagelse/Synpunkt Exempelfilerna Mycket var odefinierat. Behöver vara fyllda med information. 2.57.2 Beslut Nytt testdata är framtaget i december 2017. 3 Basmodell 3.1 Basmodell R1 3.1.1 Iakttagelse/Synpunkt GE_PlanLägeTyp och GE_HöjdLägeTyp Attributvärdena för hur texten för hur GE_PlanLägeTyp och GE_HöjdLägeTyp ska kodas stämmer inte överens med hur det är beskrivet i Mätningsanvisningarna för vad hos ett objekt som ska mätas in gällande Planläge respektive Höjdläge. Denna nomenklatur behöver synkroniseras för att förenkla för användarna som ska följa Mätningsanvisningarna och sätta koder för Planläge och Höjdläge enligt Geodataspecifikationen. Exempel är att det i Mätningsanvisningarna används ord som Centrum och Ytterkant medan det i Geodataspecifikationen används ord som Kant och Mitt. Sen används det också ord i Mätningsanvisningarna som inte finns med i Geodataspecifikationen. Ett sådant ord är t.ex. Yta. 3.1.2 Kommentar Viktigt om det gäller väsentliga begrepp och objekttyper 3.1.3 Beslut Vi försöker använda samma terminologi men lyckas inte alltid. 3.2 Basmodell R2 3.2.1 Referens Bas 5.3.13 Namn 3.2.2 Iakttagelse/Synpunkt Saknar regel

28 (164) 3.2.3 Åtgärdsförslag Ansvarig beslutsfattare obligatorisk om namntyp=godkänd 3.2.4 Beslut Infört regel på namnstatus (fd namntyp) 3.3 Basmodell R3 3.3.1 Referens Bas SG_CoClass 3.3.2 Iakttagelse/Synpunkt Attributen saknar definitioner 3.3.3 Beslut Infört 3.4 Basmodell R4 3.4.1 Referens Bas SG_Basklass beginlifespanversion 3.4.2 Iakttagelse/Synpunkt Definitionen pekar på ursprungsversionen: datum då objekt först skapades i datamängd. Lifespan är ett ord 3.4.3 Åtgärdsförslag datum och tidpunkt då denna version av det rumsliga objektet infördes eller ändrades i den rumsliga datamängden [Inspire 2010/1089]. Lifespan 3.4.4 Kommentar Inspireanpassing 3.4.5 Beslut Infört 3.5 Basmodell R5 3.5.1 Referens Bas SG_Basklass endlifespanversion

29 (164) 3.5.2 Iakttagelse/Synpunkt datum från när objekt inte längre ingår i datamängd 3.5.3 Åtgärdsförslag datum och tidpunkt då denna version av det rumsliga objektet ersattes eller upphörde att gälla i den rumsliga datamängden [Inspire 2010/1089]. Lifespan. Regel saknas i EA (2 st) 3.5.4 Kommentar Inspire-anpassning 3.5.5 Beslut Infört 3.6 Basmodell R6 3.6.1 Referens Bas SG_Basklass och SG_Datamängd. 3.6.2 Iakttagelse/Synpunkt Identifierare 3.6.3 Åtgärdsförslag extern objektidentifierare för det rumsliga objektet [Inspire 2010/1089]. Den externa objektidentifieraren som ger den unika identifieringen av rumsliga objekt får inte ändras under ett rumsligt objekts livscykel. [artikel 9]. Olika versioner av samma rumsliga objekt ska alltid vara instanser av samma rumsliga objekttyp. [Artikel 10] 3.6.4 Kommentar Inspire-anpassning 3.6.5 Beslut Infört genom Inspire-identiteter 3.7 Basmodell R7 3.7.1 Referens Bas SG_CoClass 3.7.2 Iakttagelse/Synpunkt coclassid definition 3.7.3 Beslut

30 (164) Infört 3.8 Basmodell R8 3.8.1 Referens Bas SG_AbsolutHöjd 3.8.2 Iakttagelse/Synpunkt datatyp som omfattar själva höjdvärdet och information om var det uppmättes 3.8.3 Åtgärdsförslag Höjd i förhållande till referenssystem (RH 2000) 3.8.4 Beslut ej infört byggnad datatyp 3.9 Basmodell R9 3.9.1 Referens Bas SG_RelativHöjd 3.9.2 Iakttagelse/Synpunkt datatyp som omfattar höjdvärdet mellan två höjdlägen och information om hur det uppmättes. högsta/lägsta höjd anger byggnad, är det bara byggnad? 3.9.3 Beslut ja, flyttat till byggnadsmodell 3.10 Basmodell R10 3.10.1 Referens 6 3.10.2 Iakttagelse/Synpunkt Detta dokument utgör en gemensam geodataspecifikation för gemensamma klasser som framställts på uppdrag av Lantmäteriet, kommunerna, SKL och andra myndigheter. 3.10.3 Åtgärdsförslag Detta dokument utgör en geodataspecifikation för klasser som är gemensamma för flera temaspecifikationer inom. Dokumentet har framställts på uppdrag av Lantmäteriet, kommunerna, SKL och andra myndigheter.