Stilsättning av geografiska data

Transkript

1 Examensarbete i geografisk informationsteknik nr 24 Stilsättning av geografiska data Måns Andersson & Moa Eklöf Civilingenjörsutbildningen i Lantmäteri Lunds Tekniska Högskola Institutionen för Naturgeografi och Ekosystemvetenskap Lunds Universitet

2 Stilsättning av geografiska data EXTM05 Master uppsats, 30 hp Civilingenjörsutbildningen i Lantmäteri Måns Andersson & Moa Eklöf Handledare: Lars Harrie Institutionen för Naturgeografi och Ekosystemvetenskap

3 Juni 1, 2017

4 Opponent: Leonard Berge Examinator: Micael Runnström Copyright Måns Andersson & Moa Eklöf, LTH Institutionen för Naturgeografi och Ekosystemvetenskaper Lunds Universitet Sölvegatan Lund Telefon: Fax: Hemsida: Examensarbete i geografisk informationsteknik nr 24 Tryckt av E-tryck, E-huset, 2017

5 Abstract Geographic data are data that is linked to a geographic location and is used in many different areas of society, such as all types of community and community planning, climate and environment, culture and nature, crisis management, transport and logistics. In order for geographic data to be used across county and municipal boundaries as well as in different organisations, a uniform system and standards are required. There are therefore major society benefits of having well-functioning systems and standards for geographic data. There are standards for the formats in which geographic data is to be delivered, how to deliver style, but also the reference system to be used in Sweden. There are several different initiatives for the implementation and use of geographic data standards and systems. An area where formal standards have not been given a sufficient impact is the visualisation of geographic data. The importance of visualisation of geographic data can not be emphasised enough and it is the process that turns raw data into an analytical and explanatory tool. At present, many Swedish authorities deliver geographic data primarily in a proprietary standard that cannot be used by all programs. A format that is only useful in supplier-specific software can not be considered to meet the requirement that geographic data is useful and easily accessible. OS MasterMap Topography Layer is being used in Britain and the symbolisation of the geographical data is delivered in three different formats: QML (which is used in QGIS), LYR (which is used in ArcMap) and SLD (which is a formal standard from OGC). This is a good example of how style can be delivered in multiple formats from an authority. In this study formats for visualisation of geographic data is evaluated. The aim is to identify which solutions are available to increase the compatibility of different software regarding visualisation of geographic data. Interviews are being conducted with Lantmäteriet and the association for standardisation, SIS, with the purpose of investigating how styles are handled today and how the future evolves. The solutions for styles are mapped and tested in a case study. Restrictions have been made that the case study only includes conversion from formats that authorities primarily deliver data in, namely Shape and LYR-files. The data used in the case study only covers topographic data. The solutions are evaluated after a requirement specification and proposals for how styles should be managed are presented. The case study resulted in GeoCat Bridge being the only solution that converted LYR-file to SE-file well enough. Together with manually creating the style in the desired format, these are the best solutions for increasing the compatibility of styling in different software. Creating styles manually is a time-consuming job that makes most effort if it is done as centrally as possible in an organization. The result shows that there is currently no format for styling that is perfect in all respects. A proposal has been developed for the best solution for convertering style from LYR to other formats. Proposedly, authorities should create styles in more than one format to ensure that more than one software can be used as it allows more users to use the data. OS MasterMap Topography Layer is a good example of how geographic data can be offered in different formats.

6 Sammanfattning Geografiska data är all data som är knutna till ett geografiskt läge och används inom många olika områden i samhället såsom all form av samhällsbyggnad och samhällsplanering, klimat och miljö, kultur och natur, krishantering samt transporter och logistik. För att geografiska data ska kunna användas över läns- och kommungränser samt i olika organisationer krävs ett enhetligt system och standarder för geografiska data. Det finns därmed stora samhällsekonomiska nyttor med att ha väl fungerande system och standarder för geografiska data. Det finns standarder för i vilka format geografiska data ska levereras i, hur stilsättning ska levereras men också vilket referenssystem som ska användas i Sverige. Det finns flera olika initiativ som verkar för införandet och användningen av standarder och system inom geografiska data. Ett område där formella standarder inte har fått ett tillräckligt stort genomslag är stilsättning av geografiska data. Vikten av visualisering av geografiska data kan inte betonas nog och det är stilsättningen som förvandlar rådata till ett analyserande och förklarande verktyg. I dagsläget levererar många myndigheter i Sverige geografiska data främst i format som är proprietära och som inte kan användas i alla programvaror. OS MasterMap Topography Layer används i Storbritannien och där levereras stilsättning för geografiska data i tre olika format: QML (som används i programvaran QGIS), LYR (som används i programvaran ArcMap) samt SE som är en formell standard från OGC. Det här är ett bra exempel på hur stilsättning kan levereras i flera format från en myndighet. I denna studie utreds olika format för visualisering av geografiska data. Syftet är att kartlägga vilka lösningar som finns för att öka kompatibiliteten mellan format som hanterar stilsättning. Intervjuer genomförs med Lantmäteriet och standardiseringsorganet SIS med syftet att utreda hur format för stilsätt- ning hanteras idag samt hur framtidsutsikterna ser ut. Lösningar som konverterar stilsättning ska kartläggas och testas i en fallstudie. Avgränsningar har gjorts till att fallstudien endast omfattar konvertering från det format som myndigheter främst levererar data i, nämligen Shape och LYR-fil. Datan som används i fallstudien omfattar endast topografiska data. Lösningarna utvärderas efter en kravspecifikation och förslag för hur stilsättning ska hanteras tas fram. Fallstudien resulterade i att GeoCat Bridge är den enda lösningen som konverterade LYR-fil till SE-fil tillräckligt bra. Ett lösningsförslag har tagits fram där GeoCat Bridge och att manuellt skapa stilsättning i det format som önskas är de bästa lösningarna för att öka kompatibiliteten för stilsättning i olika programvaror. Att skapa manuell stilsättning är ett tidskrävande arbete som gör mest nytta om det görs så centralt som möjligt i en organisation. Resultatet visar att det för nuvarande inte finns ett format för stilsättning som är perfekt i alla avseenden. Förslagsvis bör myndigheterna skapa stilsättning i flera format för att säkerställa att flera programvaror kan användas då det möjliggör att fler användare kan bruka datan. OS MasterMap Topography Layer är ett bra exempel på hur geografiska data kan erbjudas i olika format.

7 i Förord Denna studie är resultatet av det avslutande examensarbetet för utbildningen Civilingenjör inom Lantmäteri på Lunds Tekniska Högskola. Examensarbetet omfattar 30 hp och är genomfört samt publicerat för Institutionen för Naturgeografi och Ekosystemvetenskaper vid Lunds Universitet. Studien är gjord i samarbete med avdelningen för Geografisk Informationsteknik på Tyréns i Malmö. Vi vill tacka vår akademiske handledare Lars Harrie, universitetslektor, för ett stort stöd och engagemang samt värdefull och konstruktiv kritik genom examensarbetets gång. Vi vill också tacka vår handledare på Tyréns, Johan Larsson-Wallin, samt Pär Hagberg och Peter Alstorp för grundidéen till examensarbetet, för all hjälp vi har fått samt intresset för vår studie. Vi vill även tacka alla andra medarbetare på avdelningen i Malmö för en väldigt rolig tid. Ett tack riktas också till Jörgen Berkán samt övriga medarbetare på kart-och mätavdelningen på Tyréns kontor i Stockholm då vi har fått möjligheten att även vara på deras kontor under examensarbetets gång. Slutligen vill vi tacka Sara Stefansson på Lantmäteriet samt Anders Skog på SIS för att de tog sig tid att svara på våra frågor. Lund den 1 juni 2017 Måns Andersson & Moa Eklöf

8 Förkortningar BSD CSS DNF EPL GET GML GNU GPL HMK HTML INSPIRE JSON LYR OGC OS OSD OSGeo OSI SDI SE SIS SLD SOSI SVG W3C WCS WFS WMS WMTS XML Berkeley Software Distribution Cascading Style Sheets Data National Framework Eclipse Public License Geodata Extraction Tool Geography Markup Language GNU General Public License Handbok till Mätningskungörelsen HyperText Markup Language Infrastructure for Spatial Information in Europe JavaScript Object Notation Layer-file Open Geospatial Consortium Ordnance Survey Open Source Definition Open Source Geospatial Foundation Open Source Initiative Spatial Data Infrastructure Symbol Encoding Swedish Standards Institutes Styled Layer Descriptor Samordnet Opplegg for Stedfestet Informasjon Scalable Vector Graphics World Wide Web Consortium Web Coverage Service Web Feature Service Web Map Service Web Map Tile Service extensible Markup Language

9 Figurförteckning Figur 2.1 Nationell infrastruktur för geografiska data Figur 2.2 Den nationella geodataportalen Figur 2.3 Lager kombineras i en webbkarttjänst Figur 2.4 Geografiska objekt lagras i GML Figur 3.1 WMS funktionalitet Figur 3.2 Exempel på CSS-kod Figur 3.3 Resultat av CSS-kod Figur 3.4 Användning av SLD och SE Figur 3.5 Schema för SLD Figur 3.6 Exempel på stilsättning i SE Figur 3.7 Schema för elementet FeatureTypStyle Figur 3.8 Kod i SVG Figur 3.9 Resultat av SVG-kod Figur 3.10 Modell för SLD-prototyp Figur 5.1 Verktyget Resource Sharing i QGIS Figur 6.1 Enkel lösning Figur 6.2 Kommer överens med producenterna och beställer kartskikt Figur 6.3 Hämta all data och göra hela arbetet själv Figur 6.4 Bra lösning är att använda de bästa av de alternativa kartskikt som erbjuds Figur 6.5 Flexibel lösning Figur 6.6 SLD-prototyp Figur 7.1 Flödesschema för fallstudien Figur 7.2 Tyréns kartportal Figur 7.3 Produktpopularitet för Tyréns kartportal Figur C.1.a Punkter före konvertering, presenterat i ArcMap Figur C.1.b Punkter efter konvertering med GeoCat Bridge via GeoServer Figur C.1.c Punkter efter konvertering med GeoCat Bridge Figur C.1.d Punkter efter konvertering med GeoCat Bridge, presenterat i udig Figur C.1.e Punkter efter konvertering med Arc2Earth Figur C.1.f Symboler efter konvertering med Arc2Earth, presenterat i udig Figur C.2.a Symboler före konvertering, presenterat i ArcMap.. 84 Figur C.2.b Symboler efter konvertering med GeoCat Bridge via GeoServer Figur C.2.c Symboler efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.2.d Symboler efter konvertering med GeoCat Bridge, presenterat i udig Figur C.2.e Symboler efter konvertering med Arc2Earth, presenterat i QGIS Figur C.2.f Symboler efter konvertering med Arc2Earth, presenterat i udig Figur C.3.a Symboler före konvertering, presenterat i ArcMap.. 85 Figur C.3.b Figur C.3.c Figur C.3.d Figur C.3.e Figur C.3.f Figur C.4.a Figur C.4.b Figur C.4.c Symboler efter konvertering med GeoCat Bridge via GeoServer Symboler efter konvertering med GeoCat Bridge, presenterat i QGIS Symboler efter konvertering med GeoCat Bridge, presenterat i udig Symboler efter konvertering med Arc2Earth, presenterat i QGIS Symboler efter konvertering med GeoCat Bridge, presenterat i udig Begränsningslinjer före konvertering, presenterat i ArcMap Begränsningslinjer efter konvertering med GeoCat Bridge via Geoserver Begränsningslinjer efter konvertering med GeoCat Bridge, presenterat i QGIS

10 iv FIGURFÖRTECKNING Figur C.4.d Begränsningslinjer efter konvertering med GeoCat Bridge, presenterat i udig Figur C.4.e Begränsningslinjer efter konvertering med Arc2Earth, presenterat i QGIS Figur C.4.f Begränsningslinjer efter konvertering med Arc2Earth, presenterat i udig Figur C.5.a Administrativa gränser innan konvertering, presenterat i ArcMap Figur C.5.b Administrativa gränser efter konvertering med GeoCat Bridge via GeoServer Figur C.5.c Administrativa gränser efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.5.d Administrativa gränser efter konvertering med GeoCat Bridge, presenterat i udig Figur C.5.e Administrativa gränser efter konvertering med Arc2Earth, presenterat i QGIS Figur C.5.f Administrativa gränser efter konvertering med Arc2Earth, presenterat i udig Figur C.6.a Kraftledningar innan konvertering, presenterat i ArcMap Figur C.6.b Kraftledningar efter konvertering med GeoCat Bridge Figur C.6.c via GeoServer Kraftledningar efter konvertering med GeoCat Bridge, 88 presenterat i QGIS Figur C.6.d Kraftledningar efter konvertering med GeoCat Bridge, presenterat i udig Figur C.6.e Kraftledningar efter konvertering med Arc2Earth, presenterat i QGIS Figur C.6.f Kraftledningar efter konvertering med Arc2Earth, presenterat i udig Figur C.7.a Vägar före konvertering, presenterat i ArcMap Figur C.7.b Vägar efter konvertering med GeoCat Bridge via Geo- Server Figur C.7.c Vägar efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.7.d Vägar efter konvertering med GeoCat Bridge, presenterat i udig Figur C.7.e Vägar efter konvertering med Arc2Earth, presenterat i QGIS Figur C.7.f Vägar efter konvertering med Arc2Earth, presenterat i udig Figur C.8.a Högexploaterad kust före konvertering, presenterat i ArcMap Figur C.8.b Högexploaterad kust efter konvertering med GeoCat Bridge via GeoSever Figur C.8.c Högexploaterad kust efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.8.d Högexploaterad kust efter konvertering med GeoCat Bridge, presenterat i udig Figur C.8.e Högexploaterad kust efter konvertering med Arc2Earth, presenterat i QGIS Figur C.8.f Högexploaterad kust efter konvertering med GeoCat Bridge, presenterat i udig Figur C.9.a Naturvård före konvertering, presenterat i ArcMap. 91 Figur C.9.b Naturvård efter konvertering med GeoCat Bridge via GeoServer Figur C.9.c Naturvård efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.9.d Naturvård efter konvertering med GeoCat Bridge, presenterat i udig Figur C.9.e Naturvård efter konvertering med Arc2Earth, presenterat i QGIS Figur C.9.f Naturvård efter konvertering med Arc2Earth, presenterat i udig Figur C.10.a Bebyggd mark före konvertering, presenterad i ArcMap 92 Figur C.10.b Bebyggd mark efter konvertering med GeoCat Bridge via GeoServer

11 FIGURFÖRTECKNING v Figur C.10.c Bebyggd mark efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.10.d Bebyggd mark efter konvertering med GeoCat Bridge, presenterat i udig Figur C.10.e Bebyggd mark efter konvertering med Arc2Earth, presenterat i QGIS Figur C.10.f Bebyggd mark efter konvertering med Arc2Earth, presenterat i udig Figur C.11.a Jordart, grundlager innan konvertering, presenterat i ArcMap Figur C.11.b Jordart, grundlager efter konvertering med GeoCat Bridge med GeoServer Figur C.11.c Jordart, grundlager efter konvertering med GeoCat Bridge, presenterat i QGIS Figur C.11.d Jordart, grundlager efter konvertering med GeoCat Bridge, presenterat i udig Figur C.11.e Jordart, grundlager efter konvertering med Arc2Earth, presenteras i QGIS Figur C.11.f Jordart, grundlager efter konvertering med Arc2Earth, presenterat i udig Figur E.1.a Resulterande QGS-fil för metoden MXD2QGS Figur F.1.a Terrängkartan före konvertering Figur F.1.b Terrängkartan efter konvertering Figur F.1.c Översiktskartan före konvertering Figur F.1.d Översiktskartan efter konvertering Figur F.2.a Terrängkartan före konvertering Figur F.2.b Terrängkartan efter konvertering Figur F.3.a Terrängkartan före konvertering Figur F.3.b Terrängkartan efter konvertering Figur F.4.a Terrängkartan före konvertering Figur F.4.b Terrängkartan efter konvertering

12 Tabellförteckning Tabell B.1 Punktobjekt i fallstudie från lagret Bebyggelsesymboler i Vägkartan Tabell B.2 Linjeobjekt från Vägkartan Tabell B.3 Linjeobjekt från lagret Begränsningslinjer för markslag i Vägkartan Tabell B.4 Ytobjekt i fallstudie från lagret Bebyggd mark i Terrängkartan Tabell B.5 Ytobjekt i fallstudie från lagret Jordart, grundlager i Jordartskartan 1:1 miljon Tabell D.1 Punkt med enkel stilsättning Tabell D.2 Symbol för järnväg Tabell D.3 Bebyggelsesymboler (objekt: badplats) Tabell D.4 Begränsningslinjer för markslag Tabell D.5 Administrativa gränser (objekt:kommungräns) Tabell D.6 Kraftledningar (objekt:region) Tabell D.7 Vägar (objekt: motorväg) Tabell D.8 Högexploaterad kust Tabell D.9 Naturvård Tabell D.10 Bebyggd mark (objekt: Fritidsbybyggelse, objekt Y1). 97 Tabell D.11 Jordart, grundlager (objekt: Moränlera eller lerig morän, objekt Y6) Tabell G.12 Resultat för konvertering med GeoCat och Arc2Earth 101

13 Innehållsförteckning 1 introduktion 1.1 Bakgrund Problemformulering Syfte Metod Avgränsning Disposition infrastruktur för geografiska data Geografiska data Spatial Data Infrastructure - SDI Open Geospatial Consortium Inspire Riktlinjer för nationellt genomförande av Inspires nedladdningstjänster Data National Framework Nationell infrastruktur för geografiska data Geodatarådet Nationell geodatastrategi Geodatasamverkan Geodataportal SIS/TK 323 Geodata Intressenter och användningsområde för öppna geografiska data Leverantörer av öppna geografiska data Svensk Geoprocess Webbtjänsten Geodata Extraction Tool Projekt inom stilsättning av geografiska data SIS/TK 570 Webbkartografi Riktlinjer för webbkartografi inom krishantering Geografisk information - Modell för avbildning av geografiska data HMK-Kartografi Stilsättning inom QGIS Sverige SOSI OS MasterMap Topography layer Oskari CartoCSS Datalagring Shape MapInfo TAB GML KML GeoPackage GeoJSON hantering av stilsättning Visningstjänst för geografiska data Cascading Style Sheet Styled Layer Descriptor och Symbology Encoding Styled Layer Descriptor Komponenter i SLD och SE Användningsområde för SLD och SE Begränsningar i SLD och SE Filter Encoding Projektfiler Programspecifika format för stilsättning Scalable Vector Graphics Funktionalitet SLD-prototyp

14 viii INNEHÅLLSFÖRTECKNING 4 programvaror Öppen källkod Licenser Öppen källkod i GIS QGIS GeoServer Kommersiella programvaror ArcMap lösningar för stilsättning Konvertering av LYR-fil GeoCat Bridge Arc2Earth ArcGIS-map to SLD Converter MXD2QGS Användning av befintliga stilsättningar Befintliga stilar Resource Sharing QGS-fil intervjuer Sara Stefansson, Produktchef Lantmäteriet Anders Skog, Projektledare SIS fallstudie Tyréns kartportal Befintlig hantering av stilsättning Kravspecifikation Generell kravspecifikation Kravspecifikation för Konvertering av LYR-fil Kravspecifikation för Användning av befintliga stilsättningar Kravspecifikation för QGS-fil Geografiska objekt i test Data i studien Metod Konvertering av LYR-fil Användning av befintliga stilsättningar QGS-fil Resultat för konvertering av LYR-fil GeoCat Bridge Arc2Earth ArcGIS-map to SLD Converter MXD2QGS Resultat för Användning av befintliga stilsättningar Sammanfattning Resultat för QGS-fil diskussion Utvärdering av lösningar GeoCat Bridge Arc2Earth MXD2QGS Användning av befintliga stilsättningar QGS-fil Sammanfattning av fallstudien Nuvarande hantering av stilsättning av geografiska data Framtida utveckling SLD-prototyp Nationell kartportal Lärdomar från andra länder Framtida format för stilättning av geografiska data slutsatser 73

15 INNEHÅLLSFÖRTECKNING ix appendix 80 a Myndigheter med informationsansvar b Geografiska objekt i fallstudien. c Resultat för GeoCat Bridge och Arc2Earth d Lagers uppbyggnad e Resultat för MXD2QGS f Resultat för Användning av befintliga stilsättningar g Resultat enligt kravspecifikation för GeoCat och Arc2Earth

16 x INNEHÅLLSFÖRTECKNING

17 1 Introduktion 1.1 Bakgrund Geografiska data är knutna till ett visst geografiskt läge som exempelvis städer, länder, distriktsindelningar eller en exakt punkt på marken. Den geografiska positionen samt attribut som beskriver det aktuella objektet ingår i den geografiska datan. För att underlätta och främja användningen av geografiska data krävs en infrastruktur som består av lagar, standarder, avtal men också fibernät och andra fysiska installationer. Spatial Data Infrastructure (SDI) är en infrastruktur för geografiska data och dess användare. SDI ska underlätta för användare att veta vilken geografiska data som finns och hur användare får tag på den samt hur datan får användas. Mer än 100 länder har i dagsläget någon strategi som underlag för hur geografiska data ska hanteras på nationell nivå. Liknande arbeten bedrivs även på internationell nivå genom bland annat initiativet Inspire[1]. I Sverige har en nationell geodatastrategi arbetats fram av Geodatarådet med syftet att skapa en väl fungerande infrastruktur för geografiska data. Geodatarådet består av 13 ledamöter från bland annat Lantmäteriet, Naturvårdsverket, Sjöfartsverket, Statistiska Centralbyrån, Trafikverket, Myndigheten för samhällsskydd och beredskap samt Sveriges Kommuner och Landsting. Enligt den nationella geodatastrategin ska det garanteras att geografiska data finns tillgänglig i de former som efterfrågas och att det ska finnas valmöjlighet mellan nationella och internationella standarder. Geografiska data ska även vara lättåtkomliga och enkla att använda. I dagsläget finns det många olika programvaror som analyserar och hanterar geografiska data. En del kommersiella programvaror såsom Esris programvara ArcGIS har blivit en inofficiell standard då användningen är så pass omfattande. Det blir allt mer populärt att använda programvaror baserade på öppen källkod då det är ett sätt att slippa betala dyra licenser för att använda kommersiella programvaror. Programvaror med öppen källkod avser programvaror som, beroende på typ av licens, i de flesta fall är gratis att tillgå och det är ofta möjligt att modifiera källkoden. Populära programvaror som baseras på öppen källkod är exempelvis QGIS, GeoServer och udig. Vikten av visualisering av geografiska data kan inte betonas nog. Stilsättning transformerar rådata till ett förklarande och analyserande verktyg som kan ligga till grund för beslutstagande. Att på ett noggrant sätt kunna visualisera geografiska data är ett grundläggande krav för professionell visualisering av kartor[2]. När visualiseringen av geografisk data i en programvara inte är automatisk utan måste utföras manuellt försvåras arbetet och möjligheterna att arbeta med programvarorna. I fallstudien i detta projekt studeras metoder att visualisera geografiska data i Tyréns kartportal. Tyréns är ett av landets ledande konsultföretag inom samhällsbyggnad och på dess avdelning för Geografisk Informationsteknik i Malmö har en kartportal utvecklats. Syftet är att kartportalen ska användas internt och förenkla processen för att hämta geografiska data från olika myndigheter. Genom utvecklandet av en kartportal som uppdateras för att innehålla aktuell information säkerställer Tyréns att korrekt geografiska data används i uppdrag och projekt.

18 2 introduktion 1.2 Problemformulering En digital karta kan lagras i olika format. Ett exempel på ett väl använt format är det leverantörsspecifika vektorformatet Shape från Esri. Till formatet hör en Layer File (LYR-fil) som definierar stilsättningen för geografiska data och är framtaget av Esri. I dagsläget levererar många myndigheter geografiska data i leverantörsspecifika format. Om datan ska visualiseras i ett program som baseras på öppen källkod är det inte säkert att datan kan stilsättas. Den öppna geografiska data som myndigheter i Sverige tillhandahåller levereras i många fall som Shape-filer med tillhörande LYR-filer vilket kan medföra problem. Problem uppstår när Shape-filer med tillhörande LYR-fil öppnas i något annat program än Esris programvaror. LYR-filer kan inte tolkas och därmed visualiseras inte den geografiska datan med någon specifik stil. Det finns ingen effektiv lösning att öppna dessa filer i program andra program än ArcMap utan stilsättningen måste skapas manuellt. Denna situation är inte tillfredsställande och det som borde eftersträvas är mer kompatibilitet för stilsättning av geografiska data mellan flera programvaror. Förutsättningarna för att arbeta i program med öppen källkod bör förbättras. Med en förenklad arbetsprocess är det troligare att programvaror baserade på öppen källkod används mer och med kunskaper om flera program blir det möjligt att välja det program som är mest lämpat för en viss uppgift. När en slutanvändare laddar ner data från myndigheter i Sverige går den ofta att arbeta med direkt i ArcMap. Om datan däremot används i något annat program kan inte alltid stilen visualiseras. Det här problemet hanteras oftast på två sätt. Antingen skapas stilsättningen manuellt i det program som datan ska visualiseras i genom att så väl det går härma visualiseringen i ArcMap. Det här är ett tidskrävande arbete att utföra. Den andra lösningen är att vara beroende av de leverantörer vars format myndigheterna levererar geografiska data i. Den huvudsakliga problemställningen i studien är att utreda vilka alternativ det finns för att hantera stilsättning av geografiska data. Utredningen ska kartlägga vilka lösningar som möjliggör användning av geografiska data i program baserade på öppen källkod samt hur väl lösningarna fungerar. 1.3 Syfte Det generella syftet är att hitta en metod för att hantera stilsättningen av geografiska data som levereras från nedladdningstjänster för att minska beroendet av kommersiella leverantörer vid val av programvara för visualisering av geografiska data. Mer specifikt är syftet att: 1. Kartlägga vilka format som finns för att hantera stilsättningen av geografiska data. 2. Kartlägga vilka lösningar som finns för att öka kompatibiliteten mellan olika format som hanterar stilsättning. 3. Utvärdera lösningar för stilsättning. 4. Ge förslag till framtida lösningar för stilsättning. Studien genomförs med hjälp av en fallstudie där Tyréns interna kartportal används men resultaten är generella.

19 1.4 metod Metod Genom en litteraturstudie ges en teoretiskt bakgrund till området. Litteraturstudien omfattar geografiska data samt hantering av dess stilsättning. Den internationella och nationella infrastrukturen för geografiska data kartläggs och hur myndigheter i Sverige jobbar med utveckling av stilsättning av geografiska data kartläggs också. Denna kartläggning genomförs bland annat genom intervjuer med sakkunniga inom området. Olika typer av programvaror och hur de hanterar stilsättning omfattas även av litteraturstudien. Informationen hämtas från akademiska böcker, artiklar och tekniska dokumentationer för format, programvaror och standarder. Nuvarande lösningar för stilsättning inventeras och utifrån dessa genomförs en fallstudie för att utreda möjligheterna att konvertera LYR-filer till andra format. Detta görs genom att ta fram en kravspecifikation för samtliga lösningar. Ett test genomförs för att testa dessa lösningar. Ett testområde väljs ut som innehåller geografiska objekt som är vanligt förekommande i myndigheters kartor för att kunna jämföra lösningarna. Testområdet innehåller tillräckligt med data för att kunna utvärdera kravspecifikationen. Utifrån kravspecifikationen utvärderas sedan samtliga lösningar. Slutligen diskuteras framtidsutsikerna för olika format och för de lösningar som konverterar LYR-filer. Ett lösningsförslag tas fram för hur stilsättning av geografiska data bäst hanteras i dagsläget. Förslag ges även för hur hantering stilsättning kan effektiviseras och förenklas i framtiden. 1.5 Avgränsning Den praktiska studien har endast analyserats med hänsyn till nedladdning av filformatet Shape och studien hanterar inte stilsättning i visualiseringstjänster utan endast i nedladdningstjänster. Ytterligare avgränsningar görs till att fallstudien inte omfattar avancerade tematiska kartor eftersom de myndigheter som levererar öppna geografiska data vanligtvis inte innehåller sådan information. De lösningar som utreds har hittats på internet och säger sig kunna konvertera stilsättning på olika sätt. En annan avgränsning är att placering av text inte studeras i fallstudien. Placering av text styrs av komplicerade algoritmer och det är inte ett rimligt krav att ställa att en lösning som konverterar stilsättning även ska hantera textplacering. 1.6 Disposition Kapitel 2 beskriver den teoretiska bakgrunden för geografiska data samt infrastrukturen för geografiska data. Infrastrukturen beskrivs både på en nationell och internationell nivå. Hantering av stilsättning av geografiska data beskrivs i kapitel 3. Kapitel 4 beskriver öppen källkod och de vanligaste licenserna för öppen källkod. GIS-relaterade kommersiella programvaror och programvaror som är baserade på öppen källkod redogörs det för även i det här kapitlet. Befintliga lösningar för stilsättning av geografiska data beskrivs i kapitel 5. Kapitel 6 innehåller intervjuer med sakkunniga. Kapitel 7 innehåller en fallstudie för konvertering av LYR-filer utifrån Tyréns kartportal. Fallstudien omfattar en generell kravspecifikation samt en kravspecifikation som är anpassad för de olika lösningarna, test av befintliga lösningar samt en redogörelse av resultatet. Kapitel 8 innehåller en diskussion om fallstudien samt en utvärdering utifrån den generella kravspecifikationen. Hur hanteringen av stilsättning fungerar för närvarande samt framtidsutsikter diskuteras också i kapitel 8. Avslutningsvis innehåller kapitel 9 slutsatser som redogör för hur syftet har uppnåtts.

20 2 Infrastruktur för geografiska data 2.1 Geografiska data Geografiska data är viktigt för flera olika aktörer i samhället och används inom bland annat samhällsplanering, krishantering, utbildning, transporter och logistik, klimat och miljö samt kultur och natur. Kommuner kan använda interaktiva karttjänster som gör det möjligt att samla information om kommunen. Karttjänsterna kan exempelvis användas till att rapportera in felaktigheter i väg- och cykelnätet, var papperskorgar behövs tömmas eller var gatulyktor har slutat att fungera. Geografiska data kan användas för att förenkla planerings- och bygglovsprocesser genom möjligheten att anpassa flera kommuners kartor till ett enhetligt kartmaterial. 3D-modeller kan användas av kommuner för att tidigt få en övergripande bild över hur olika exploateringsförslag kommer att påverka stadsbilden[3]. För att förenkla processer och verksamheter används geografiska data bland myndigheter och regioner såsom Sveriges Geologiska Undersökning (SGU) och Region Gotland. Med hjälp av höjddata och ortofoton kan SGU förbättra sina jordartskartor vilket bidrar till säkrare samhällsplanering. Region Gotland har tagit fram Naturvärdeskartan som samlar de handlingar som krävs för att göra en bedömning av skyddsvärdet vid exploatering. Tidigare har en del nödvändiga handlingar endast funnits i pappersformat och handläggare har fått söka information på olika ställen[3]. Med Naturvärdeskartan blir det enklare att hantera exploateringstrycket på Gotland och samtidigt ta hänsyn till skyddsvärden. Genom en välplanerad infrastruktur möjliggörs tillgång till geografiska data från olika aktörer. En infrastruktur för geografiska data gör det enklare att snabbt hitta rätt information vilket är viktigt för bland annat beredskap och förmågan att hantera kriser. Vid kriser är det viktigt att flera myndigheter som samverkar snabbt får fram rätt information om en olycksplats. Det är även viktigt att snabbt hitta rätt adress och transportvägar vid olika kriser. Att informationen är tillgänglig över kommun- och länsgränser är grundläggande för en väl fungerande beredskap i Sverige[4]. Genom en nationell infrastruktur i Sverige är det möjligt att detta uppfylls samt att säkerställa att samma stilsättning används för en viss typ av data. Att samma stilsättning används är av största vikt för att användare snabbt ska få en tydlig och överskådlig lägesbild. 2.2 Spatial Data Infrastructure - SDI SDI är ett sätt att göra data tillgängligt. Begreppet SDI började användas i början av 90-talet då behovet att dela geografiska data mellan olika användare uppdagades[1]. SDI definieras ofta som ett initiativ för att skapa en miljö som ska underlätta samarbete mellan olika intressenter för att enklare nå mål på politiska och administrativa nivåer[5]. Infrastrukturen har blivit en viktig komponent för att fastlägga hur geografiska data ska användas i länder, företag och organisationer som vill samordna geografiska data. Med SDI är tanken att data ska delas för att spara på de resurser som krävs när ny data erhålls. Intressenter från olika discipliner har olika uppfattningar av SDI vilket medför att många olika definitioner tagits fram av forskare och olika organisationer[5].

21 2.3 open geospatial consortium 5 Infrastruktur förknippas ofta med hårda komponenter såsom fibernät och fysiska installationer medan standarder, affärsmodeller, avtal och lagar ingår i den mjuka infrastrukturen. Båda komponenterna är även en viktig del för effektiv användning av geografiska data. Infrastrukturen brukar delas in i fem olika komponenter[1]: Institutionella ramverk så som lagstiftning och riktlinjer påverkar förutsättningarna för användning och hantering av geografiska data. Standarder, specifikationer och riktlinjer som effektiviserar produktionen och användningen av geografiska data. Den här komponenten underlättar att geografiska data från olika källor kombineras. Regler för grundläggande geografiska data som anger vem som har ansvar för insamling och uppdatering av grundläggande geografiska data, såsom fastigheter, adresser, vägar och riksintressen. Teknisk infrastruktur som effektiviserar samverkan inom produktion och uppdatering av geografiska data. Applikationer som förenklar processen att söka, beställa och hämta data ingår även här. Forskning och utbildning som bidrar till att öka kunskaper om geografiska data i samhället. 2.3 Open Geospatial Consortium Open Geospatial Consortium (OGC) är ett konsortium av företag, icke-statliga organisationer, universitet och forskningsorganisationer vars vision är att geografiska data ska vara tillgängliga för olika nätverk, applikationer och plattformar[6]. Syftet med OGC är stödja och verka för utvecklingen och användningen av standarder och tekniker inom området för geografiska data och relaterade informationstekniker. En stor del av den geografiska data som dagligen samlas in lagras i olika format och koordinatsystem. Samtidigt finns det ett växande behov för möjligheten att hantera, bearbeta och dela geografiska data. OGC hanterar en global sammanhållen process som resulterar i gränssnitt och standarder som möjliggör kompatibilitet hos och mellan geografiska datalagringar, tjänster och applikationer. Web Coverage Service (WCS), Web Feature Service (WFS), Web Map Service (WMS) (se avsnitt 3.1) och Web Map Tile Service (WMTS) är standarder för karttjänster som är utvecklade av OGC. WCS är en service som stödjer hämtning av geografiska data som coverages, det vill säga digital geografiska data som förändras över rum och tid[7]. WFS är en service som tillhandahåller möjligheten att få tillgång till och utföra transaktioner på geografiska objekt. Transaktionerna kan omfatta skapandet av objekt, ändringar, ersättningar och raderingar av objekt. WFS möjliggör även sökningar efter objekt samt en överblick av kapaciteten hos objekten[8]. WMTS är en standard för att betjäna digitala kartor genom att använda fördefinierade bilder. Servicen utannonserar de bilder som är tillgängliga genom en standardiserad deklaration i dokumentet ServiceMetadata som finns i alla OGC:s web services. Deklarationen definierar alla de bilder som är tillgängliga för varje lager[9]. 2.4 Inspire Infrastructure for Spatial Information in Europe (Inspire) är ett EU-direktiv som har till syfte att skapa gemensamma standarder för offentliga geografiska data[10]. Syftet är att förenkla möjligheterna att använda data om exempelvis befolkning, transportsystem och markanvändning för att effektivisera

22 6 infrastruktur för geografiska data samarbetet mellan nationer inom EU för tillämpningar inom miljöområdet. Genom Inspire ska utbytet av data mellan myndigheter effektiviseras. Inspire ska bidra till att politiska beslut angående miljön fattas över gränserna i EU. Direktivet antogs år 2007 och har som mål att vara fullt realiserat år Inspires vision är att sömlöst kunna kombinera geografiska data från olika medlemsländer inom EU. Direktivet innehåller föreskrifter för hur tillgång till geografiska data, genom följande tjänster, ska ske på ett enhetligt sätt[11]: Söktjänster: Krävs för att få information om vilka data och tjänster som är tillgängliga inom Sverige och övriga länder inom EU. I Sverige uppfylls det här av Geodataportalen. Visningstjänster: Krävs för att visualisera och granska innehållet i data.. Nedladdningstjänster: Krävs för att få tillgång till data och kunna bearbeta och analysera den, för mer information se avsnitt Omvandlingstjänster: Gör det möjligt att omvandla geografiska data så att den blir användbar utan återkommande manuella åtgärder. Förbindelsetjänster: Gör det möjligt att använda och komma i kontakt med andra informationshanterings- och e-handelstjänster. Inspire betonar vikten av kompatibilitet vid behandling av geografiska data. Kompatibilitet ska uppnås genom att samordna kravspecifikationer för geografiska data så att datan blir homogen och därmed lättare att dela mellan användare. Det här ska uppnås genom att följa framtagna internationella standarder för geografisk data. I dagsläget har stilsättningen inte varit i fokus i Inspire-projektet. De sök- och visningstjänster som direktivet omfattar ska vara kostnadsfria[11]. Det svenska genomförandet av Inspire regleras i Lag (SFS 2010:1767) om geografisk miljöinformation och Förordning (SFS 2010:1770) om geografisk miljöinformation. I 5 Lag (SFS 2010:1767) om geografisk miljöinformation regleras vilka myndigheter som har ett informationsansvar, vilket innebär att de ska medverka i det sammanhängande systemet för geografisk miljöinformation genom att hålla sådan information och informationshanteringstjänster tillgängliga för andra som medverkar i eller använder systemet. Enligt 6 Lag (SFS 2010:1767) om geografisk miljöinformation ska den som är informationsansvarig ta fram och tillhandahålla upplysningar i elektronisk form som beskriver den geografiska miljöinformation och de informationshanteringstjänster som hör samman med informationen. Metadata ska avse informationens och tjänsternas innehåll, uppkomst och aktualitet, hur det går att finna och använda dem samt hur de presenteras och fungerar, eller är avsedda att fungera, i det sammanhängande informationssystemet. Vilka myndigheter som har ett informationsansvar och för vilken information regleras i 3 kap 1-33 Förordning (SFS 2010:1770) om geografisk miljöinformation. Ansvaret för att samordna och stödja det nationella genomförandet av Inspire har tilldelats Lantmäteriet. Myndigheter, kommuner och enskilda organ som har ett informationsansvar redovisas i appendix A. För att få en överblick av alla krav, rekommendationer och vägledningar baserade på Inspire, har nationella riktlinjer och vägledningar tagits fram. Genomförande bestämmelser och Technical Guidance, som är en vägledning publicerad av EU-kommissionen, innehåller krav och rekommendationer för hur genomförandet av Inspire förverkligas och har bland annat fungerat som grund för de framtagna riktlinjerna[12]. I de fall där krav uppfattas som

23 2.4 inspire 7 otydliga innehåller riktlinjerna även en nationell tolkning av kraven. Det finns riktlinjer och vägledningar för visningstjänster, nedladdningstjänster och för tillhandahållande av harmoniserade datamängder Riktlinjer för nationellt genomförande av Inspires nedladdningstjänster Syftet med Riktlinjer för nationellt genomförande av Inspires nedladdningstjänster är att ge vägledning och rekommendationer på svenska och följaktligen fastställa riktlinjer i enlighet med Inspires krav för svenskt genomförandet av nedladdningstjänster[12]. Krav och rekommendationer för nedladdningstjänster som uppfyller Inspire framställs i följande dokument[12]: Inspiredirektivet: Ger en övergripande beskrivning av de krav som ska uppfyllas för att direktivet ska bedömas som uppfyllt. Genomförandebestämmelsen (Implementing Rules) för nättjänster: Innehåller en beskrivning av vilka krav från Inspire som ska uppfyllas. Technical Guidance for the implementation of Inspire Download Services (TG): Ger en mer detaljerad redogörelse av de operationer en nedladdningstjänst ska kunna utföra. TG innehåller även ett antal rekommendationer som bör följas vid genomförandet av exempelvis vilka standarder som kan användas. Dokumentet finns endast tillgängligt på engelska och när det uppdateras vid behov så uppdateras även de svenska riktlinjerna så att de överensstämmer med TG. När Inspire är fullt implementerat ska alla datamängder eller delar av datamängder som erbjuds stämma överens med Inspires krav på att Geography Markup Language (GML) enligt ISO 19136, det vill säga version GML 3.2.1, ska användas. Redan nu rekommenderas användning av GML version som format för leveranser[12]: En tjänst för fördefinierade datamängder kan använda GML version eller, om det inte är möjligt, version En tjänst för direkt åtkomst av datamängder använder ofta WFS som i sin tur använder GML Den här versionen är tillåten tills dess att en stabil version av WFS 2.0, som använder GML 3.2.1, är tillgänglig. Under den här övergångsperioden är det dock möjligt att datamängder levereras i befintlig struktur och i ett annat format än GML[12]. I övrigt tas inte format för stilsättning av geografiska data upp i rapporten Riktlinjer för nationellt genomförande av Inspires nedladdningstjänster Data National Framework Data National Framework (DNF) är en industriell standard skapad av Inspire för att integrera och distribuera bland annat geografiska data. Visionen för DNF är att möjliggöra och stödja enkel och tillförlitlig integration för bland annat geografiska data oberoende av vem som är ansvarig för dess underhåll och vart det genomförs. I sista hand har DNF potential att utvecklas till ett nätverk av information som kan integreras och användas med en uttalad säkerhet. Information för affärsverksamheter kan distribueras med vetskapen att alla användare med säkerhet vet att de refererar till samma lokalisering och objekt i verkligheten[13]. Det här är viktigt i många olika applikationer. DNF syftar till att bland annat maximera fördelarna då information som

24 8 infrastruktur för geografiska data är knuten till en geografisk plats integreras genom ramverket. Det erbjuder möjligheten att länka ett flertal informationskällor till en definitiv lokalisering genom unika identifierare. I Storbritannien används OS MasterMap Topography layer för att uppnå målen med DNF[13]. Hur Storbritannien arbetar med OS MasterMap Topography layer redovisas närmare i avsnitt Nationell infrastruktur för geografiska data I Sverige är det Lantmäteriet som har en samordningsroll för geografiska data och Geodatarådet som ger stöd till Lantmäteriet i samordningsrollen. Den nationella infrastrukturen är även en del, genom EU-direktivet Inspire, av den europeiska infrastrukturen för geografiska data. Organiseringen av infrastrukturen berör både producenter och användare av geografiska data. Syftet är att infrastrukturen ska förenkla möjligheten att hitta rätt typ av geografiska data och att nyttja den[14]. Den nationella infrastrukturen för geografiska data består av flera olika komponenter: en etablerad samverkan mellan organisationer, god kompetens, en portal, metadata, regelverk, standarder, tjänster och geografiska data. Figur 2.1 visar en modell över den nationella infrastrukturen. Portalen gör det möjligt att enkelt söka, hitta och visualisera geografiska data. Regelverket styr informationsförsörjningen och metadata redogör för innehåll, tillgänglighet, kvalitet samt standarder som beskrivet ett gemensamt arbetsätt[14]. För att kunna söka i geografiska databaser är metadata en viktig förutsättning. Ramverket omfattar inte vilken typ av geografiska data som får publiceras i portalen men innehållet måste bedömas ha ett allmänintresse[15]. Figur 2.1: Modell över nationell infrastruktur för geografiska data. Källa c Lantmäteriet[14]. Lantmäteriet arbetar även för att i större utsträckning göra kartor och geografiska data fritt tillgängliga och fria att använda, så kallad öppna geografiska data. I dagsläget är inte alla geografiska data från Lantmäteriet öppna. Regeringen har som mål att digitaliseringens utveckling ska öka och för det

25 2.5 nationell infrastruktur för geografiska data 9 är öppna geografiska data en förutsättning. Lantmäteriet definierar sina öppna geografiska data enligt följande[16]: Den är avgiftsfri och enkelt tillgänglig för alla som vill använda den. Den får användas och publiceras fritt utan avgifter och krångliga villkor. Den finns tillgänglig i maskinläsbart gränssnitt. För nuvarande finansieras Lantmäteriets geografiska data till ungefär 70 % av avgifter[17]. Användningen av geografiska data omges även av villkor som begränsar vidaredistribuering. Det här hindrar myndigheter, organisationer, företag och privatpersoner att på ett effektivt sätt använda Lantmäteriets information. Konsekvensen blir att fritt tillgänglig data av varierande, oftast sämre, kvalitet istället används. Geodatasamverkan, se avsnitt har medfört stora förbättringar för myndigheter men finansieringsmodellen som används är fortfarande ett hinder[17] Geodatarådet Geodatarådet består utav representanter från myndigheter samt organisationer och har till uppgift att rådgöra Lantmäteriet inom geografiska data och ska mer specifikt[18] medverka i framtagande av nationell geodatastrategi, se 2.5.2) behandla gemensamma frågor om geografiska data på nationell nivå utveckla den nationella och internationella infrastrukturen bland annat genom tillämpningen av standarder bidra till ökad samordning mellan myndigheter inom information och tillhandahållande av information bidra till samordning för utbyte och tillgång till geografiska data. Geodatarådet representeras för närvarande av följande myndigheter och organisationer[18]: Lantmäteriet Trafikverket Naturvårdsverket Sjöfartsverket Myndigheten för samhällsskydd och beredskap (MSB) Havs- och vattenmyndigheten Skogsstyrelsen Statistiska Centralbyrån Sveriges geologiska undersökning (SGU) Sveriges Meteorologiska och Hydrologiska Institut Sveriges Kommuner och Landsting (SKL) Sveriges lantbruksuniversitet Länsstyrelsen Värmland Linköpings kommun.

26 10 infrastruktur för geografiska data Nationell geodatastrategi Lantmäteriet har tillsammans med övriga myndigheter och organisationer i Geodatarådet, se avsnitt 2.5.1, tagit fram en nationell geodatastrategi. Fyra mål har satts upp för strategin för utvecklingen av geografiska data under perioden 2016 till 2020[19]: Geografiska data är öppna: De årliga avgiftsuttagen för geografiska data från Lantmäteriet, Sjöfartsverket, SCB och kommuner uppgår uppskattningsvis till 700 miljoner kronor. Dessa avgifter ska täcka kostnader för datainsamling, uppdatering, förvaltning och distribution av statliga och kommunala geografiska data. För att geografiska data avgiftsfritt ska kunna öppnas upp för offentlig och privat sektor krävs en alternativ finansiering av geografiska data. Geografiska data är användbara: För att geografiska data ska vara effektivt användbara ska de vara aktuella, fullständiga, av känd kvalitet samt enkla att använda. Det ska garanteras att geografiska data finnas tillgänglig i de former som efterfrågas, att det finns valmöjligheter mellan nationella och internationella standarder och att geografiska data inte förekommer i olika versioner. När flera aktörer arbetar med samma geografiska data är det viktigt att de har tillgång till samma gemensamma information. De offentliga producenterna av geografiska data bidrar till målet genom att säkerställa att offentliga geografiska data kan tillgängligöras enligt öppna internationella och nationella standarder. Geografiska data är tillgängliga: Geografiska data ska vara lättillgängliga och kända för allmänheten. Framtida arbetsflöden utnyttjar maskinläsbar, så kallad semantisk, data och kommer kräva nya arbetssätt och arbetsflöden vid hantering av geografiska data. Dessa arbetsflöden ska standardiseras med API:er så att användare kan implementera det i den egna verksamheten och underlätta digitaliseringen av sina processer. Samverkan är välutvecklad: Den nationella geodatastrategin är grunden för samverkan mellan olika producenter av geografiska data och användare. Formerna för samverkan ska utvecklas på ett sätt så att samordning stärks Geodatasamverkan Geodatasamverkan är en modell som möjliggör tillgång till geografiska data för offentlig användning. Modellen ger användaren genom ett avtal och en årsavgift, tillgång till ett samlat utbud av geografiska data. Kommuner, landsting, regioner och statliga myndigheter kan teckna avtal för användning av datan[20]. Geodatasamverkan ger tillgång till data från Lantmäteriet, SCB, SGU, SMHI och Sjöfartsverket. Den 30 juni 2016 överlämnade ledamöterna i Geodatarådet skrivelsen Sverige behöver öppna geodata till näringsdepartementet. Syftet med skrivelsen var att informera regeringen om behovet av en ny finansieringsmodell för Lantmäteriets geografiska data. Flertalet av Sveriges grannländer har tagit steget till öppna geografiska data och betraktar det som en framgång[17]. Geografiska data används i många e-tjänster, mobilapplikationer och i handläggningsstöd. De stora nyttorna i samhället skapas när geografiska data kan användas, delas och kombineras med data från andra källor och användas i beslutsunderlag[17]. ULI Geoforum har initierat forskningsstudien Samhällsekonomisk effekt av öppna geografiska data som genomförs vid Handelshögskolan i Stockholm

27 2.5 nationell infrastruktur för geografiska data 11 av Erik Lakomaa. Projektet finansieras av Vinnova och Lantmäteriet. Studien påvisar att en reform som ger öppna geografiska data från offentlig sektor är lönsam. En försiktig och konservativ beräkning i rapporten visar att det samhällsekonomiska överskottet är ungefär 200 miljoner kronor[21]. Lakomaa menar därmed att det med en stor säkerhet går att säga att tillgänggligörandet av geografiska data som öppna data vore en stor vinst för samhället. Studien tar även upp exempel på hur öppna geografiska data kan skapa indirekta värden genom[21]: minskat slöseri och lägre risk vid anläggningsarbeten besparingar inom entreprenadtjänster besparingar vid miljökonsekvensbeskrivningar och genom undvikande av miljöskador effektivisering av kommunal verksamhet förenklingar vid bygglovsprocesser och byggande Geodataportal För att underlätta utbytet av geografiska data används den nationella Geodataportalen som Lantmäteriet ansvarar för. Geodataportalen är en ingång till geografiska data och tjänster. I portalen finns det möjligheter att söka, visualisera och ladda ner data från flertalet olika källor vilket visas i figur 2.2. Geodataportalen innehåller i sig inte några tjänster eller data utan informerar om vilken typ av data som finns och vart den finns. Syftet med metadatan är att göra det enklare att söka och utvärdera data[22]. Producenter av geografiska data har i portalen möjligheten att tillgängliggöra och redogöra för sin data genom metadata. Det krävs inget avtal för att använda portalen utan den är tillgänglig för alla. Portalen är Sveriges koppling till Inspire geoportal, som är den europeiska geodataportalen. Figur 2.2: Den nationella geodataportalen. Källa: Lantmäteriet. Det finns ett tekniskt ramverk som anger de krav som finns för metadata och geodatatjänster som finns tillgängliga via Geodataportalen. Ramverket ska fungera som stöd och bakgrund för de tekniska förpliktelser som gäller vid deltagande i samverkan eller i infrastrukturen för geografiska data. De

28 12 infrastruktur för geografiska data krav som kommer från Inspires genomförandebestämmelser gällande metadata, sök-, omvandlings-, nedladdnings-, förbindelse- och visningstjänster anges i ramverket[15]. Ramverket innehåller förpliktelser för Lantmäteriet i egenskap av geodatasamordnare och ansvarig för förvaltningen av Geodataportalen samt för de myndigheter, kommuner och andra aktörer som publicerar metadata och har sina produkter tillgängliga vid Geodataportalen. En övervägande del av de krav som ställs på metadata och geografiska data finns tillgängliga på Geodatas hemsida eller i andra dokument som är tillgängliga på internet från källor som OGC, SIS och ISO. Det tekniska ramverket sammanfattar de krav som är beskrivna i andra dokument[15]. De krav som är specifika för den svenska infrastrukturen och som därmed inte är specificerade i andra dokument beskrivs i detalj i ramverket SIS/TK 323 Geodata Swedish Standards Institutes (SIS) är en ideell förening som arbetar med och samordnar de standardiseringar som genomförs i Sverige. Föreningen representerar också Sverige i den europeiska standardiseringsorganisationen CEN och i ISO som är en global standardiseringsorganisation[23] SIS/TK 323 är en kommitté inom SIS som samordnar behoven av standardisering av geografiska data och är knutpunkten för SIS:s olika kommittéer som arbetar med geografiska data[24]. SIS/TK 323 tar även fram tekniska rapporter som behandlar utvecklingen av en nationell geodatastrategi. Det är världsstandarden ISO som används för geografiska data och utgör grunden för det tekniska ramverk för geografiska data som används i Sverige. Att påverka utvecklingen av ISO standarden är en av kommitténs uppgifter[24]. SIS/TK 323 är även med och påverkar utvecklingen inom internationella standarder genom att medverka i den europeiska standardiseringsorganisationen CEN och den internationella motsvarigheten ISO. Genom att aktivt medverka i dessa organisationer kan SIS påverka standarderna så att de främjar svenska intressenter och fri rörlighet av geografiska data mellan länder. De kommittéer som är med i SIS/TK 323 Geodata är: TK 320 Väg- och järnvägsinformation TK 453 Vattensystem TK 570 Webbkartografi TK 538 Skoglig information TK 501 Fysisk planering TK 533 Byggnadsinformation TK 489 Metadata för geodata TK 466 Belägenhetsadresser SIS Forum för geodatatjänster. Stanli behandlade samordning och kvalitetssäkring av nationell standardisering för geografiska data fram till 2015 då projektet lades ner och ersattes av SIS/TK 323 Geodata[25]. Orsaken till nerläggningen var att styrningen inom standardisering av geografiska data skulle effektiviseras.

29 2.5 nationell infrastruktur för geografiska data Intressenter och användningsområde för öppna geografiska data Möjligheterna med öppna geografiska data är många och förväntas ha en stor inverkan på samhället. Många processer inom samhällsbyggnad kan effektiviseras om alla aktörer har samma lägesbild med enhetliga kartor, ortofoton och höjdmodeller. Bättre beslut kan fattas och administrationen kan förenklas med öppna geografiska data. Kultur och miljö kan få ett bättre skydd och klimat- och miljöhoten kan tydliggöras[17]. På grund av de kostnader som finns för användandet av geografiska data hindras myndigheter och företag att ta den hänsyn som behövs till kultur- och miljövärden i analyser och beslut. Bra krishantering är beroende av aktuella geografiska data som håller hög kvalitet. Flertalet aktörer inom blåljusområdet har varken rätt eller fullständig data vilket kan leda till olycksbådande konsekvenser[17]. Att räddningsfordon har korrekt information om adresser är grundläggande för bra krishantering. Det är viktigt att alla aktörer inom blåljusområdet har tillgång till enhetlig och aktuell data av högsta kvalitet. På grund av avgifterna för geografiska data är det vanligt att företag inte använder Lantmäteriets data. Många verksamheters processer skulle kunna effektiviseras med hjälp av öppna geografiska data då innovation stimuleras och steget till att skapa nya tjänster blir enklare[17]. Flera av de ledande länderna inom IT har öppna geografiska data vilket ger dem bättre förutsättningarna än vad svenska företag har. Öppna geografiska data behövs för att Sverige ska vara konkurrenskraftiga[17]. Jordbruksverket och Skogsstyrelsen uppger även att öppna geografiska data kan effektivisera jord- och skogsbruket i Sverige[17]. Jordbruksverket uppskattar att analyser kan bidra till att minskade utsläpp av fosfor till ett värde av 27 miljoner kronor[26] Leverantörer av öppna geografiska data Det finns myndigheter och organisationer som levererar öppna geografiska data. Några exempel är Lantmäteriet, Trafikverket, SGU och Jordbruksverket. Dessa kan sammanfattas med att de har ett informationsansvar i enlighet med Lag (SFS 2010:1767) om geografisk miljöinformation och Förordning (SFS 2010:1770) om geografisk miljöinformation (se avsnitt 2.4). För att exemplifiera hur en myndighet uppfyller kraven i Lag (SFS 2010:1767) om geografisk miljöinformation tas Trafikverket som exempel. På Trafikverkets hemsida finns en flik med tjänster som de erbjuder. Bland dessa finns Öppna data och här erbjuds dels öppna data, som är fria att använda, samt grunddata, som omfattas av avtal och licenser. Lastkajen är Trafikverkets applikation för att hämta väg- och järnvägsanknuten data. För att komma åt Lastkajen måste ett användarkonto skapas. Väl inloggad finns data tillgänglig i ett antal olika format, däribland GeoDB, MapInfo och Shape. Vid beställning av data måste sedan format, koordinatsystem, geografiskt område och urval av data specificeras. Därefter görs en beställning och en bekräftelse skickas till användarens mejl när datan är klar för leverans. Ett annat exempel på hur kraven i Lag (SFS 2010:1767) om geografisk miljöinformation uppfylls är Lantmäteriets Geodataplatsen som beskrivs som ett Hämta-själv-lager. Här kan de som har avtal inom geodatasamverkan hämta geografiska data. Geodataplatsen tillhandahåller GSD-Fastighetskartan i vektorformat som är möjlig att ladda ned i formaten Shape och MapInfo TAB[27].

30 14 infrastruktur för geografiska data För att använda Lantmäteriets nedladdnings- och direktåtkomsttjänster för geografisk information används en annan tjänst som hittas på Lantmäteriets hemsida. Direktåtkomsterna kräver att användaren skickar ett tjänsteanrop med sökbegrepp eller urvalsparametrar och erhåller då ett standardiserat svar som innehåller information om de geografiska objekttyperna som är tillgängliga. Lantmäteriets nedladdningstjänster tillhandahåller möjligheten att i ett system eller applikation ladda hem geografiska data via ett standardiserat gränssnitt[28]. Lantmäteriets geodatatjänst Geografisk Indelning Direkt ger tillgång till de geografiska indelningarna län, kommun, distrikt och jordregistersocken. Tjänsten är i grunden fri från avgifter men för tillgång till detaljerad geometri krävs en särskild behörighet[29]. För att hämta Lantmäteriets öppna geografiska data behövs ett användarkonto skapas. Den öppna datan levereras i Shape eller MapInfo TAB[16] Svensk Geoprocess Svensk Geoprocess är ett gemensamt initiativ från Lantmäteriet, Sveriges Kommuner och Landsting (SKL) och kommunerna. Ett regeringsbeslut från den 3 oktober 2013 anger att projektet Svensk Geoprocess till juni 2016 ska[30] ta fram nationella specifikationer och processer för nio utpekade teman inom geografiska data bidra till att alla kommuner har infört de enhetliga referenssystemen SWEREF 99 och RH De nio utpekade områdena som datautbytesmodeller ska tas fram för är flygbild/ortofoto, hydrografi, markanvändning/marktäcke, markdetaljer, laserdata/höjdmodell, väg/järnväg, byggnad, adress och stompunkter. Vid arbetet med att ta fram schema för datautbytemodeller har Svensk Geoprocess tagit hänsyn till OGC-standarder och däribland GML-standarden[31]. Syftet med Svensk Geoprocess är att möjliggöra leveranser av enhetliga geografiska data oberoende av administrativa gränser samt att bidra till både enklare och mer effektiv service från myndigheterna[30]. En konsekvens av initiativet är även att det banar väg för ökad användning av geografiska data genom den snabba tillgången till enhetliga geografiska data och referenssystem. Det arbete som genomfördes inom ramarna för projektet var att enhetliga specifikationer och samverkanprocesser togs fram samt att kommuner och myndigheter aktivt stöttades i arbetet med att införa nya referenssystem[30]. Samverkan Svensk Geoprocess är mottagarna av projektresultatet och har uppdraget att förvalta och fortsätta utveckla resultaten samt stödja och driva fram införande och användning av resultatet[30] Webbtjänsten Geodata Extraction Tool Geodata Extraction Tool (GET) är en fri webbtjänst för universitet och högskolor som tillhandahåller geografiska data från Lantmäteriet, Sjöfartsverket, SGU och SCB. Lantmäteriets data levereras i en zip-fil där en av mapparna har namnet arcgis och innehåller en LYR-fil som innehåller stilsättningen för datan. Genom GET ges också tillgång till Trafikverkets tjänst Lastkajen[32]. Webbtjänsten är möjlig med hjälp av finansiering genom Vetenskapsrådet som täcker licenskostnaderna som myndigheterna tar ut för användning av deras geografiska data. Det är Sveriges lantbruksuniversitet (SLU) som innehar värdskapet för GET och som har fått uppdraget från Vetenskapsrådet att utveckla och förvalta tjänsten[32]. Vetenskapsrådet har under 2017 fortsatt att ge driftsbidrag till GET[33].

31 2.6 projekt inom stilsättning av geografiska data Projekt inom stilsättning av geografiska data För nuvarande pågår arbeten för att standardisera användningen av digitala kartor för att möjliggöra kombinationen av data från olika källor[34]. Tidigare arbeten inom hanteringen av stilsättning av geografiska data har endast berört kartografi. Gamla Handbok till Mätningskungörelsen(HMK) - Kartografi berör kartografi för analoga kartor[35]. I dagsläget finns det inte något arbete om hur stilsättning av geografiska data ska hanteras. Den nationella geodatastrategin tar förvisso upp en del om detta men stilsättningen är än så länge inte prioriterad[19]. En del myndigheter har arbetat fram riktlinjer för webbkartografi för att säkerställa att data stilsätts på ett enhetligt sätt[36]. Riktlinjer för vilket lagringsformat som ska användas har dock inte tagits fram SIS/TK 570 Webbkartografi SIS/TK 570 Webbkartografi är en arbetsgrupp inom SIS vars arbete bland annat omfattar att[37] öka kunskapen i Sverige om webbkartografiska möjligheter hålla sig uppdaterade om internationellt arbete inom området sprida framtagna riktlinjer för webbkartografi och verka för att de används sprida termer och definitioner inom området med målet att de ska vara kända och användas arbeta med kartsymboler i webbkartor. Arbetsgruppen har gett ut rapporten Webbkarttjänster med av producenten definierade kartskikt som anger rekommendationer för att skapa karttjänster så att lager kan kombineras från flera karttjänster så att de blir så användbara som möjligt[37]. Rapporten riktar sig till producenter av webbkarttjänster och syftar till att standardisera kartlager i en karttjänst så att lager producerade av olika oberoende parter, exempelvis myndigheter, ska kunna kombineras med varandra och användas i nya sammanhang. När en konsument vill använda lager från en webbkarttjänst ska utgångspunkten vara att konsumenten ska klara sig på de lager som erbjuds. Därmed måste ett flertal lager erbjudas med olika utformningar. I figur 2.3 exemplifieras hur en användare kombinerar 4 olika lager för att göra en egen webbkarta[38]. Figur 2.3: Lager kombineras i en webbkarttjänst. Källa: SIS/TK 570[34].

32 16 infrastruktur för geografiska data I rapporten redovisas ett antal rekommendationer för att utforma en webbtjänst som ska kunna användas tillsammans med andra webbtjänster[34]: I webbkarttjänsten bör det vara möjligt att välja och kombinera olika lager så att användaren har möjlighet att göra läsbara och begripliga webbkartor. De som producerar webbkarttjänster bör samverka så att användning av samma färger, mönster och symboler undviks. Myndigheter som producerar geografiska data bör därför ta medvetna val av färger och symboler, publicera sina val och stämma av med varandra. Webbkarttjänster bör innehålla få samt sammanhörande objekttyper så att den som kombinerar kartskikt kan välja de lager som lämpar sig bäst. Mobilmaster ska exempelvis vara ett eget lager istället för att master av alla typer är i ett och samma lager. Flera alternativ för stilsättning av lager bör erbjudas. Exempelvis ska en bakgrundskarta erbjudas i flera olika varianter inom exempelvis transparens och detaljeringsgrad så att användaren kan välja det utseende som passar bäst för uppgiften. Samma möjligheter bör erbjudas för symboler, punktobjekt, linjeobjekt och polygonobjekt. För att en webbkarta ska visualiseras lika på olika karttjänster och inte ändras annat än vid olika zoomnivåer bör det finnas standarder som reglerar det här. På nationell nivå finns det dock inte någons standard som definierar zoomnivåer för webbkartor. Kartskikt i webbkarttjänster bör specificeras på ett sätt som underlättar arbetet med att välja och kombinera kartskikt. Rapporten ska ses i kontrast mot den planerade rapporten Webbkarttjänster med av användaren definierade kartskikt. Den här rapporten handlar om hur en webbkarttjänst bör utformas så att användaren av tjänsten själv kan anpassa kartografin efter egna behov och önskemål. Tanken är att tekniken som beskrivs i de här två rapporterna ska komplettera varandra. Medans rapporten Webbkarttjänster med av producenten definierade kartskikt är enklast att använda men med en del begränsningar ger istället rapporten Webbkarttjänster med av användaren definierade kartskikt en stor flexibilitet men med kravet på betydligt mer kunskap hos användaren. Båda rapporterna vänder sig till dem som erbjuder webbkarttjänsterna och incitamenten för att följa riktlinjerna är att webbkarttjänsterna kommer kunna användas tillsammans med andra webbkarttjänsterna och därmed användas i flera sammanhang och av fler användare[34] Riktlinjer för webbkartografi inom krishantering Rapporten Riktlinjer för webbkartografi inom krishantering innehåller övergripande riktlinjer för webbkartografi inom krisberedskap. Projektet är ett samarbete mellan Lantmäteriet, MSB och Försvaret. Det här projektet drivs parallellt med SIS/TK 570 som har en mer övergripande synsätt på standardiseringen av stilsättning medan detta projekt fokuserar på stilsättning i området krisberedskap[36]. Den här rapporten kommer även utgöra indata till projektet SIS/TK 570. Det rapporten främst tar upp är hur de krav som ställs på kartor för krishantering kan tillgodoses i ett tjänstebaserat system, vanligen ett system som använder en WMS-tjänst. Det är främst regler för hur kartografin ska utformas som diskuteras i rapporten och inte i vilka format stilsättningen bör hanteras. Inom området för beredskap och hantering av kriser är förekomsten av aktuella och relevanta geografiska data av största vikt. Genom den digitalisering som har skett under de senaste decennierna har tillgången till geografiska

33 2.6 projekt inom stilsättning av geografiska data 17 data ökat väsentligt. Användare kan nu kopplas upp direkt mot relevant information istället för att begära en kopia av informationen. När data från flera olika leverantörer numera kan samordnas krävs regler och bestämmelser för hur datan ska visualiseras. Tidigare har det inte funnits någon samordnad kartografi för producenterna men utvecklingen kräver numera det. Det måste vara möjligt att snabbt och enkelt skapa en lättförståelig och korrekt lägesbild. Avsaknaden av en samordnad stilsättning innebär problem vid samordning av data från flera olika källor. Målet med rapporten som har arbetats fram är att den framtagna manér- och symbolsättningen ska bli standard inom de aktuella områdena[36]. Förhoppningarna är att de framtagna riktlinjerna ska gälla för både nationella behov men även i samarbete med grannländer Geografisk information - Modell för avbildning av geografiska data Geografisk information - Modell för avbildning av geografiska data (ISO 19117:2012) specificerar ett konceptuellt schema som är en modell för avbildning av geografiska data[39]. Modellen bygger på att det för varje objekttyp ska finnas en symboliseringsfunktion som anger regler för hur objektet kan symboliseras. Modellen innehåller principer för hur symboliseringsfunktioner definieras, hur symboler beskrivs och hur symboliseringsfunktionerna kan styras av objektens data och även andra funktioner såsom skalan. Schemat är baserat på Unified Modeling Language (UML) och inte EXtensible Markup Language (XML). Det här konceptuella schemat kan användas i designen av system för framställning av geografiska data. Modellen tillåter att beskrivningen av geografiska data kan separeras från beskrivningen av hur geografiska data presenteras vilket tillåter att data framställs på ett oberoende sätt[39]. Modellen tillämpas av Styled Layer Descriptor (SLD) och Symbology Encoding (SE), se avsnitt HMK-Kartografi Lantmäteriet har som tidigare nämnt ett nationellt samordningsansvar för geografiska data och ger även stöd i mät- och kartfrågor genom HMK- Kartografi som innehåller stöd för bland annat laserdata, höjddata, ortofoto, stommätning, terrester laserskanning och geodetisk infrastruktur. HMK-Kartografi är en del av den gamla HMK-serien och behandlar i huvudsak kartografiska aspekter för de storskaliga kartor som omfattas av dåvarande Mätningskungörelsens regler. Handboken innehåller kartografiska grundregler såsom hur färgsättning bör utföras, hur teckenförklaringen bör se ut och hur kartans manér bör utformas. Den befintliga handboken för kartografi saknar hur geografiska data ska visualiseras digitalt och utan skalberoende[35]. För dessa frågor hänvisar Lantmäteriet till arbetet SIS/TK 570 Webbkartografi Stilsättning inom QGIS Sverige QGIS Sverige är en förening vars syfte är att främja utveckling och användning av programmet QGIS i Sverige. Det internationella QGIS-projektet stöds av QGIS Sverige som även bevakar andra GIS-relaterade program och verktyg som baseras på öppen källkod. Föreningen driver ett utvecklingsprojekt där stilsättning för Lantmäteriets kartverk tas fram i form av QMLfiler[40] och delas på GitHub. Projektet på GitHub gäller under MIT-licensen

34 18 infrastruktur för geografiska data som är en copy free-licens som ger användaren rätt att nyttja, kopiera, sprida och ändra programvaran SOSI Samordnet Opplegg for Stedfestet Informasjon (SOSI) började utvecklas i mitten av 80-talet av Norska miljödepartementet och Kartverket. Detta blev ett första steg i att standardisera ett format för geografiska data. Under denna tidpunkt fanns inga liknande internationella standarder. Sedan dess har SOSI-formatet varit det mest använda i Norge[41]. Idag sker ingen mer utveckling av SOSI utan GML, se avsnitt 2.9.3, är sedan 2016 det format som är obligatoriskt att använda vid publicering av nya datamängder. Offentlig verksamhet ska i princip inte leverera data i format som är specifika för en viss leverantör[41]. Detta anses hämma effektiv konkurrens då det är till fördel för vissa leverantörer. När ett leverantörsspecifikt format används ska detta vara ett komplement till de obligatoriska formaten (SOSI-formatet och GML) och användas om användarna är i behov av det och om transformation till detta format inte är resurskrävande. Inom SOSI finns även nationella standarder för utbyte av geografiska data. Standarden innehåller standardiserade definitioner för geometri och topologi, datakvalitet, koordinatsystem, attribut och metadata. En del av SOSI beskriver ramverk för SOSI:s generella objektkatalog, metadata, kataloginformation och indirekta referenser[42]. SOSI baseras på den internationella kommittén ISO/TC 211 Geographic information/geomatics OS MasterMap Topography layer Ordnance Survey (OS) är Storbritanniens nationella kartverk. De producerar digitala geografiska data, ruttplanering på webben och delar service och applikationer i mobiler, bland många andra platsbaserade produkter[43]. OS MasterMap Topography layer är den mest detaljerade och exakta visualiseringen av Storbritanniens landskap. Allt från vägar, byggnader, marktyper och träd finns lagrat i kartans databas[44]. Generellt levereras datan från OS i formaten GML (se avsnitt 2.9.3) eller Shape (se avsnitt 2.9.1) och ibland i formaten MapInfo TAB eller som raster. OS erbjuder stilsättning i tre olika format: QML för QGIS, LYR-fil för Esri ArcGIS och enligt hemsidan SLD för GeoServer och andra webbapplikationer (även om det är formatet SE som faktiskt används för stillsättning, se avsnitt 3.3), som beskrivs i avsnitt 3. QML kan använda tillsammans med data i både GML och Shape. LYR är endast tillgänglig för data i formatet Shape då ArcGIS inte stödjer GML. SE är tillgängligt för databaser som är baserade på GML eller Shape[45]. Stilarna är tillgängliga på organisationens sida på GitHub. 2.7 Oskari Oskari är ett verktyg för att visualisera, dela och analysera geografiska eller statistiska data från spridda datakällor, som exempelvis nationella SDI:er[46]. Med verktyget kan man göra egna kartor och WMS:er och det är utvecklat med Java och JavaScript av National Land Survey of Finland (NLF) och den webbaserade visningstjänsten är till fullo utvecklad genom öppen källkod. Med Oskari är det möjligt att skapa en koppling till datakällor som är standardiserade genom OGC. Det är även möjligt att skapa statistisk information för att skapa tematiska kartor, lägga till egna data samt publicera integrerade kartor med tematisk information och analys av den geografiska datan. Målet med Oskari är att göra det enklare att utveckla karttjänster

35 2.8 cartocss 19 online och i mobiler. Verktyget stödjer lager i form utav bland annat WMS, WMTS och WFS. Oskari används av ett flertal organisationer och myndigheter för att tillgängliggöra geografiska data. Exempel på dessa är Arctic Council som har publicerat Arctic SDI Geoportal i samarbete med ingående medlemsländer. Islands och Finlands har nationella geodataportaler som är utvecklade genom Oskari. 2.8 CartoCSS CartoCSS är ett verktyg från Mapnik som framställer stilmallar för stilsättning av geografiska data och är utvecklat av MapBox. I likhet med att designa webbsidor med CSS används liknande teknik för att stilsätta kartor. CartoCSS är utvecklat i JavaScript och speciellt framtaget för att symbolisera kartsymboler så som punkter, linjer och polygoner. Mapnik är en samling av verktyg för framställning av kartor som är baserat på öppen källkod. Programmet går under licensen LGPL. CartoCSS används bland annat av Tilemill som är mjukvaran som används för att designa OpenStreetMap[47]. 2.9 Datalagring Geografiska data kan lagras i vektor- eller rasterformat. I ett vektorformat lagras datan som punkter, linjer eller polygoner med x- och y-koordinater i ett koordinatsystem. Fördelarna med vektorformat är att det är enkelt att knyta attribut till enskilda objekt, topologiska relationer kan identifieras mellan objekt och objekten kan ha en hög geometrisk precision[1]. Minnesutnyttjandet är även effektivt eftersom eventuella tomrum mellan objekten inte lagras. I ett rasterformat lagras datan i ett rutnät. Den yta som ska representeras delas upp i ett antal rutor, så kallade celler. Ett numeriskt värde som motsvarar den yta som ska representeras tilldelas varje cell. Raster används vanligen för att lagra flyg- och satellitbilder eller variabler som har en kontinuerlig utbredning, exempelvis markanvändning. Attributen i raster beskrivs vanligen av värdena i cellerna. En svaghet är att varje nytt attribut måste lagras i ett nytt rasterskikt om det inte är möjligt att knyta cellerna till attributtabeller genom ett ID-nummer. När raster används är det viktigt att knyta rastret till ett geodetiskt referenssystem[1]. En nackdel med raster är att cellerna är de minsta enheterna och därmed kan inte delar av en cell beskrivas. Det finns ingen formell standard för lagring av geografiska data i hybrida lagringssystem där geografiska data lagras i ett filsystem och attributdata i en relationsdatabas. Många GIS-program har egna filformat som är optimerade för användning inom programvaran. De flesta GIS-programvaror stödjer däremot användning av andra filformat som är standardiserade. Två informella standarder är Shape och MapInfo TAB[1]. Bristen på en formell standard innebär ofta praktiska problem vid användningen av GISprogram Shape Shape är ett filformat utvecklat av Esri och är ett populärt format för att lagra och visualisera geografiska data. Shape-formatet lagrar olika objekts läge, geometrier i form utav vektordata och attribut som beskriver objektet. Formatet lagrar icke-topologiska geometrier vilket gör att de har fördelen att de har snabbare visualisering samt editering än topologiska format. De objekt som stöds är punkter, linjer och polygoner. En Shape-fil innehåller

36 20 infrastruktur för geografiska data en typ av objekt så byggnader och vägar ska alltså inte blandas i samma fil[48]. Shape-filer innehåller ofta stora mängder geografiska objekt och kan öppnas i ArcMap men även importeras av andra GIS-programvaror som exempelvis QGIS, MapInfo Professional och GeoServer. Formatet brukar benämnas som en Shape-fil vilket är missvisande då formatet Shape består av flera filer. En Shape-fil måste innehålla en main-fil, en index-fil och en dbase-fil[48]. Main-filen, i formatet SHP, består av en rad för varje objekt. Dessa rader innehåller en lista av punkter som beskriver det aktuella objektets geometri. Index-filen, i formatet SHX, innehåller index för geometrierna. dbase-filen, i formatet DBF, innehåller attributen för geometrierna. Varje rad med attribut har en en-till-en relation med den associerade raden med det geografiska objektet. I avsnitt 3.8 redogörs det för hur formatet hanterar stilsättning MapInfo TAB Formatet MapInfo TAB är en informell standard som är baserad på hybridmodellen för lagring av geografiska data. Precis som för Shape-formatet används en fil för att lagring av geografisk data och en fil för lagring av attributdata. Filen som lagrar geografiska data är av formatet MAP medans filen som lagrar attributdata är av formatet DAT[1] GML GML är en dialekt av XML som används för lagring och distribuering av geografiska data. Formatet innehåller både geometrin och objektets egenskaper. Formatet är en officiell standard: ISO 19136:2007[49]. Språket är ett öppet format för distribution av geografiska data på webben. Punkter, linjer och polygoner kan beskrivas i GML[49]. GML har flera olika fördelar gentemot tidigare standarder för geografiska data. En av fördelarna med att använda textformat är enkelheten och transparensen som formatet medför. Text är enkelt att inspektera och att ändra. Genom att använda XML blir texten även enkel att kontrollera. En annan fördel med att GML baseras på XML är att det är enkelt att integrera GML med annan icke-spatial data som kan vara baserat på XML, men även andra språk. Eftersom GML baseras på XML som är en allmänt vedertagen standard finns det även en mängd kommersiella och även gratis verktyg för att hantera formatet[50]. GML baseras på en abstrakt modell som består av geografiska objekt. I grund och botten innehåller ett geografiskt objekt endast en lista av egenskaper och geometrier. Egenskaper består av ofta använda attribut såsom namn, typ och beskrivning. Geometrier utgörs av geometriska typer såsom punkter, linjer, kurvor och polygoner. GML kan hantera komplicerade objekt som kan bestå av flera olika geometriska typer[50]. Ett objekt kan även bestå av flera andra objekt. Tanken med GML är att separera innehåll och presentation för geografiska data, precis som XML separerar innehåll och presentation på webben. Det egentliga syftet med GML är inte att använda det för att skapa kartor och GML har begränsad funktionalitet för att hantera stilsättning. För att skapa kartor med hjälp av GML är ett sätt att använda verktyg som tolkar GML. Det här strider dock mot synsättet att GML är en standard som separerar innehåll och presentation. För att GML ska kunna användas i en karta måste elementen i GML stilsättas till ett format som kan tolkas i en grafisk representation i en webbläsare[50]. Potentiella format för stilsättning är exempelvis Scalable Vector Graphics (SVG), som beskrivs i avsnitt 3.9. Ett

37 2.9 datalagring 21 verktyg som stilsätter kartor behövs då användas för att lokalisera element i koden och tolka dem genom att använda särskilda grafiska stilar[50]. Figur 2.4: Geografiska objekt lagras i GML. I figur 2.4 används en FeatureCollection som bas i GML och är en kollektion av objekt. Till FeatureCollection hör en avgränsning som utgör gränserna för uppsättningens kollektion av objekt, en kollektion av egenskaper som tillämpas på FeatureCollection och en valbar lista av Spatial Reference System Definitions[50]. En FeatureCollection kan även innehålla andra FeatureCollections så länge som avgränsningen är större än de nästlade avgränsningarna. Även CityGML är baserat på XML. Det är en öppen datastruktur för lagring och utbyte av virtuella 3D-modeller av städer[51]. Syftet med CityGML är att komma fram till en allmän definition av de grundläggande enheterna, attributen och relationerna för 3D-modeller av städer KML Keyhole Markup Language (KML) är ett filformat baserat på XML och används för geografisk visualisering i en Earth browser, som till exempel Google Earth. KML använder, precis som XML, en struktur som är baserad på taggar med nästlade element och attribut. Taggarna måste förekomma i samma ordning som de är listade i referensen för KML[52]. Version KML 2.2 utnyttjar vissa geometriska element såsom punkter, linjer, linear ring och polygoner från GML 2.1.2[53]. Formatet kan användas för att precisera platser och addera bildöverlagringar [54]. I Google Earth används KML för att precisera geografiska koordinater som kallas för placemarks. Den enklaste typen av placemarks är en punkt med tillhörande beskrivande text. Med Google Earths gränssnitt är det möjligt att skapa geografiska objekt med tillhörande beskrivningar, polygoner, placemarks samt andra attribut[52]. KML kan även användas för att definiera stilsättning för olika objekt ge-

38 22 infrastruktur för geografiska data nom att elementen kml:abstractfeaturegroup innehåller elementen kml:style eller kml:stylemap. Med dessa element stilsätts endast objekten de används i[53] GeoPackage GeoPackage är ett öppet och standardiserat format utvecklat av OGC. Det är ett kompakt format för att överföra geografiska data, portabelt, självbeskrivande samt oberoende av plattform. Formatet kan lagra rasterdata, vektordata samt utvidgningar genom att spara dessa i en SQLite databas[55]. En SQLite databas är en databas sparad inom en lokal fil och behöver alltså inte en egen server för att fungera[56]. GeoPackage är en databas sparad i en lokal fil och GeoPackage Encoding Standard styr utformningen. Standarden definierar schemat för GeoPackage och dess definitioner för tabeller, integritet, begränsningar i formatet och innehållet. Det nödvändiga innehållet och det innehållet som stödjs av formatet definieras även i GeoPackage Encoding Standard[55] GeoJSON GeoJSON är ett geografiskt format för utbyte av data som är baserat på JavaScript Object Notation (JSON). Formatet definierar flera olika objekt av typen JSON och på vilket sätt de kan kombineras för att representera geografiska objekt och deras egenskaper samt geografiska omfattning. Formatet kan användas för all typ av data som på något sätt är bunden till en geografisk plats, oavsett om den har en fysisk utbredning eller inte. GeoJSON omfattar de sju geometriska typerna som definieras i OGC Simple Features Implementation Specification for SQL (SFSQL): 0-dimensional Point, 1-dimensional curve LineString, 2-dimensional surface Polygon, MultiPoint, MultiLineString, MultiPolygon och GeometryCollection[57]. Ett objekt i GeoJSON innehåller ett geometriobjekt och tillhörande egenskaper.

39 3 Hantering av stilsättning Stilsättning av geografiska data är av största vikt för att en karta ska vara läsbar och kunna användas. Färg, storlek på objekt, placering och typsnitt är några parametrar som ingår i en kartas stilsättning. Kartans ändamål är grundläggande för valet av innehåll. Även skala, utförande och produktionssätt har stor betydelse. Informationsmängden för en karta bör vara utformad så den ger god läsbarhet[35]. För dagens digitala kartor kan informationsmängden variera beroende på skalintervall. Det finns många olika sätt att visualisera geografiska data på och även många format för hantering av stilsättning. En del format är anpassade efter den programvara de är skapade för vilket medför att de inte är kompatibla med andra programvaror. Formaten för stilsättning är även beroende av vilka format som används för distributionen av datan. Det finns många olika parametrar att ta hänsyn till vid val av stilsättning samt format för dess hantering och lagring. 3.1 Visningstjänst för geografiska data En visningstjänst är en tjänst som gör det möjligt att visualisera, navigera, zooma, panorera och överlagra geografiska data samt tillhandahålla information i form av metadata. För att generera en karta innehållandes geografiska data används standarden WMS inom Inspire. WMS är utvecklat av OGC och är en internationell standard som beskriver geografiska data i en digitaliserad karta[58]. Den genererade kartan innehåller ingen data utan är generellt av ett bildformat som exempelvis PNG, GIF och JPEG eller i vektorformat som exempelvis SVG. WMS definierar de obligatoriska operationerna GetMap och GetCapabilities samt den valbara operationen GetFeatureInfo. GetMap är en operation som returnerar en karta i raster- eller vektorformat. GetCapabilities är en operation som returnerar en XML-fil som beskriver den data som är tillgänglig på servern. GetFeatureInfo är en operation som ger klienten tillgång till mer information om de geografiska objekten i kartan som returnerades av operationen GetMap[58]. Arbetsflödet för dessa operationerna visas i figur 3.1. Figur 3.1: WMS funktionalitet.

40 24 hantering av stilsättning 3.2 Cascading Style Sheet Cascading Style Sheets (CSS) beskriver hur HTML-element visualiseras på en skärm eller ett annat informationsmedel. Flera webbsidor kan samtidigt kontrolleras av CSS. Typsnitt, textfärg, textstorlek, bakgrundsbilder, placering av textstycken, bilder och menyer är bara några av de attribut som CSS kan styra. CSS kan användas på tre olika sätt: i text, internt och externt. Det är effektivt att skapa externa CSS-filer som kan länkas in till flera webbsidor. Figur 3.2 visar hur en CSS-fil som har intern stilsättning kan vara uppbyggd. Hur attributen bakgrundsfärg, placering av textstycken, typsnitt och textfärg kan definieras med hjälp av CSS visas också i figur 3.2. CSS kan användas för att göra enkla, statiska webbkartor[59]. Figur 3.2 visar hur CSS kan användas för att stilsätta HTML-element och följande stilar har använts: 1. En intern stilmall används för att stilsätta paragraferna p och p1. 2. För att skapa en specifik stilsättning till ett HTML-element kan ett ID anges. 3. För att skapa en specifik stilsättning till en klass av HTML-element kan en klass anges. Figur 3.3 visar resultatet av CSS-koden i figur 3.2. Figur 3.2: Exempel på CSS-kod.

41 3.3 styled layer descriptor och symbology encoding 25 Figur 3.3: Resultatet av CSS-koden i figur Styled Layer Descriptor och Symbology Encoding SLD är ett standardiserat språk för att styra utseendet på kartor som hanteras i WMS-tjänster[2]. OGC har tagit fram standarden som är en förlängning av WMS-standarden. Syftet är att SLD ska uppfylla det behov som användare och programvaror har av att kunna kontrollera visualiseringen av geografiska data[60]. SE är en dialekt av XML som används för stilsättning av Feature data och Coverage data. Rotelementen i SE är därmed alltid FeatureTypeStyle eller CoverageStyle och de innehåller all information för att stilsätta data. SE är oberoende av vilket gränssnitt som används och kan därmed användas för flera olika tjänster som stilsätter geografiska data[61]. Under 2007 delade OGC upp den tidigare specifikationen av SLD till två nya specifikationer: SLD och SE, med syftet att möjliggöra användningen av de delar som inte är specifika för WMS-tjänster i andra tjänster. De delar som inte är specifika för WMS-tjänster är efter uppdelningen specificerade i SE. Uppdelningen innebär att SLD endast innehåller beskrivningar för kommunikationen med WMS-tjänster om hur data ska stilsättas. Förlängningen med SLD medför att användardefinierade färgsättning och symbolisering av geografiska data är möjlig i WMS-tjänster[62]. Med anledning av uppdelningen av SE och SLD är det korrekt att använda SE när syftet är att benämna stilsättningen genom XML-språket. Därmed kommer SE fortsättningsvis i den här rapporten användas för att benämna stilsättningen och SLD används för kommunikationen med WMS-tjänster. Specifikationen för SE innehåller, efter uppdelningen, de faktiska beskrivningarna för hur stilsättning ska utföras. Efter uppdelningen definierar specifikationen för SE XML-språket, som både klienten och servern kan läsa. Genom SLD kan SE appliceras på lager i WMS-tjänster. SE kan användas för att beskriva stilsättning i system som inte är kopplade till någon form av karttjänst på webben. SE kan med andra ord användas även i datorprogram som exempelvis QGIS och udig som beskrivs i avsnitt och 4.1.2[62]. Editering av stilen kan ske direkt i XML-filen eller genom den programvara som den används i om den har verktyg för det. I QGIS kan en SE-fil skapas genom att stilsätta den geografiska datan och exportera stilen som SE. I Geo- Server kan en SE-fil läsas in från en extern källa eller skapas och därefter valideras Styled Layer Descriptor SLD agerar som länken mellan WMS-lager och stilsättningen som definieras i SE (se figur 3.4), vilket görs genom SLD:s operationer som kan användas

42 26 hantering av stilsättning i WMS-tjänster. PutStyle är en operation som gör att användaren kan exportera SLD-filen till en geodataleverantörs server. Det här gör att andra användare får tillgång till stilmallen. GetStyle är i motsats en operation som laddar ner en stilmall även om den sällan förekommer i WMS-tjänster[2]. SLD består bland annat av regler som definierar vilka objekt som ska visualiseras på ett definierat sätt. Regler kan använda alla filter som är definierade enligt OGC. För att data i en WMS-tjänst ska kunna stilsättas beroende på dess attributs värde krävs kännedom om datans attribut. Genom SLD:s operation DescribeLayer returnerar de objekttyperna som förekommer i lagret. Operationerna DescribeFeatureType och DescribeCoverageType kan därefter användas för att tillhandahålla information om attributen. Figur 3.4: Användning av SLD och SE. Den aktuella WMS-specifikationen stödjer möjligheten för användaren att ange enkla stilsättningar genom att tillhandahålla förinställda stilar för varje lager med data. WMS-tjänsten kan ange namn för olika stilar men inte hur de kommer att visualiseras på kartan. Stilsättning genom WMS kan endast ske genom att definiera ett specifikt lager och en stil som är publicerad av WMS-tjänsten[2]. Användaren kan därmed inte definiera egna stilregler. Det här medför begränsningar i visualiseringen som hindrar användningen av datans hela kapacitet. För att kunna hantera användardefinierade stilregler krävs ett språk som både klienten och servern kan förstå Komponenter i SLD och SE En SLD-fil är definierad som en sekvens av stilsatta lager och figur 3.5 visar schemat för rotelementet SLD. Schemat för SLD i figur 3.5 innehåller följande element[2]: Figur 3.5: Schema för SLD. Källa: OGC[2].

43 3.3 styled layer descriptor och symbology encoding Name möjliggör att det aktuella objektet kan refereras till. Elementet används för de flesta objekt som definieras av SLD och SE. 2. Description ger en beskrivning av objektet. Tanken är att informationen i elementet ska kunna extraheras och användas som sökbar metadata i katalogsystem. 3. Stilsättningen i SLD kan ske genom namngiven eller användardefinierad stilmall. NamedLayer används för namngivna stilmallar. Åtkomst till NamedLayers kan fås direkt från en OGC Web Server genom att ange ett välkänt namn för lagret. 4. Med elementet UserLayer kan stilsatta lager vara användardefinierade. För UserLayer måste elementen innehålla identifiering av objekt som ska användas. Alla objekt som ska användas antas komma från en WFS eller WCS. De två typerna av stilsatta lager kan användas i samma SLD-fil och ordnas efter den ordning de ska visualiseras i på kartan. 5. UseSLDLibrary tillhandahåller möjligheten att använda externa SLDfiler. Figur 3.6: Exempel på stilsättning i SE. Figur 3.6 är ett exempel på stilsättning i SE och innehåller följande element[61]: 1. Name används i de flesta objekt som definieras av SE och möjliggör att objekten kan refereras till. Namnen måste vara unika i den miljön de är definierade i. 2. Genom att använda användardefinierade stilar, UserStyle, kan stilen skapas i ett externt system och distribueras i ett kompatibelt format. Även UserStyle har de valbara elementen Name och Description som är välbehövliga för att kunna identifiera regeln. UserStyle har även ett element, isdefault, som bestämmer om stilen är den förvalda stilen för ett lager. isdefault är av typen boolean som använder sig av 1 för sant och 0 för falskt. 3. Rotelementet FeatureTypeStyle definierar stilsättningen som ska användas för ett objekt. Även i FeatureTypeStyle är elementen Name och Description valbara. I dagsläget har inte Name en tydlig användning även om

44 28 hantering av stilsättning det är tänkbart att det kommer användas som en referens till en stil i ett bibliotek för FeatureTypeStyle. Syftet med elementen Description, Title och Abstract är att tillhandahålla information för användarna. CoverageStyle används för att definiera stilsättningen som ska appliceras på Coverage data och kan precis som FeatureTypeStyle innehålla elementen Name, Description, Title och Abstract. 4. Regler används i SE för att gruppera instruktioner efter objektens egenskaper. Även i regler möjliggör elementet Name att referenser till regeln kan göras externt. Definitionerna av regler placeras i en Feature- TypeStyle eller CoverageStyle. Den första regeln är den som plottas först och därmed ligger som bakgrund till resterande data. 5. Elementet Description ger även här en beskrivning av objektet och tanken är att informationen i Description ska kunna extraheras och användas som sökbar metadata i katalogsystem, precis som för objekt som definieras i SLD. 6. Elementen MinScaleDenominator och MaxScaleDenominator definierar de skalintervall som en regel kan appliceras för. Värdena för regeln anges relativt till en standardiserad pixelstorlek. Värdet betyder en skala på 1: Den minimala skalan är inkluderande och den maximala skalan är exkluderande. Båda elementen är valbara så avsaknaden av en gräns betyder att regeln gäller till en skala av 0 eller till oändligheten. 7. Inneslutna i reglerna finns Symbolizers som grupperar villkor för stilsättningen av objekten. Symbolizers beskriver hur ett objekt ska visualiseras i en karta. Form, färg och transparens kan bestämmas med hjälp av Symbolizers. Linjer, polygoner, punkter, text och raster går att definiera med Symbolizers. 8. Fill är ett element som är inneslutet i en Symbolizers och som specificerar hur geometrin ska färgläggas. Den finns två olika typer, enfärgad eller GraphicFill. 9. SvgParameter kan användas för bland annat fill, fill-opacity, stroke, strokeopacity, stroke-width, stroke-linjoin och stroke-lincap. Den valda parametern ges av name i SvgParameter. 10. Stroke är ett element som är inneslutet i en Symbolizers och är ett valfritt element. Avsaknaden av stroke betyder att ingen kantlinje kommer att stilsättas. Figur 3.7: Schema för elementet FeatureTypStyle. Källa: OGC[61]. För att förklara andra viktiga element för FeatureTypeStyle används figur 3.7[61]: 1. För att identifiera vilken typ av objekt som ska stilsättas används FeatureTypeName. Elementet är endast valbart om typen är känd i sammanhanget eller om stilen ska användas för olika typer genom att använda SemanticTypeIdentifier.

45 3.4 användningsområde för sld och se Elementet SemanticTypeIdentifier är under prövning och tanken är att det ska användas för att identifiera vilka typer som stilen är lämplig att stilsätta. Syntaxen är odefinierad men strängarna generic:polygon, generic:line, generic:point, generic:text, generic:raster, generic:any är reserverade till att indikera att stilen kan användas till objekt med motsvarande geometriska typer. 3. För att referera till externa dokument används elementet OnlineResource. Den vanligaste användningen av det här elementet är att använda xlink:type och Xlinf:href för att referera till en länk. I regler kan Feature Filtering användas för att välja ut de objekt som ska stilsättas på ett bestämt sätt. Feature Filtering möjliggör ett urval av objekt i regler som ska kontrolleras av bestämda villkor för attributen[61]. Syntaxen för elementet Filter är definierade i specifikationen för Filter Encoding (se avsnitt 3.6) och möjliggör både filtrering på attribut och geografisk placering. 3.4 Användningsområde för SLD och SE SLD och SE är formella standarder inom området geografiska data och har därmed ett tydligt incitament för att de bör användas. Standarder kan dock upplevas som krångliga då deras specifikationer vanligtvis är teoretiska och tekniska vilket gör det svårt att tillgodogöra sig innehållet[63]. SLD och SE är standarder som ökar interoperabiliteten och är att föredra vid gemensamma projekt som för exempelvis krishantering och byggprojekt då flera olika parter har behov av att arbeta med samma geografiska data. SLD möjliggör styrning av utseendet på kartor i WMS-tjänster och det är många programvaror som kan läsa WMS:er. QGIS och ArcMap är bland de största programvarorna som kan hantera WMS-tjänster. I QGIS går det att både läsa in data som stilsätts med SE samt exportera stilsättning som har skapats i programmet som en SE-fil. I GeoServer går det också att läsa in SE-filer som innehåller stilsättning uttryckt i SE. Det går även att skapa SE-filer genom att kopiera befintliga stilar och därefter redigera filen. Det finns en viss skillnad mellan användningen av SLD i Geo- Server och QGIS. Vissa stilar som skapas i QGIS ser inte likadana ut när de används i GeoServer vilket redogörs för i avsnitt Begränsningar i SLD och SE SE har stora möjligheter för stilsättning av vektor- och rasterdata och är i en del tycke, den viktigaste standarden från OGC för WMS-tjänsters kartografi[64]. Standarden har dock även en del begränsningar. Det har skrivits ett antal artiklar om begränsningar i SLD och SE och vilka förbättringar som kan göras. En begränsning med SLD är att det inte går att visualisera geografiska data i realtid på webben. Det här är en funktion som har en stor efterfrågan i dagens samhälle, inte minst för avdelningar som arbetar med miljöfrågor[65]. En annan begränsning med SLD är att när kartor automatiskt genereras med WMS blir inte visualiseringen optimal. Det här beror på skalreduktion. Iosifescu Enescu med flera har utvecklat en utvidgning av SLD som specificerar kartografiska regler i en WMS-genererad karta[64]. Resultatet av utvidgningen blev en karta som stilmässigt kan mäta sig med en atlaskarta. Att skapa tematiska kartor med hjälp av SE medför också en del begränsningar. I dagsläget går det bra att skapa grundläggande tematiska kartor som koropletkartor och kartor som använder proportionella symboler som

46 30 hantering av stilsättning är fördefinierade som exempelvis cirklar, rektanglar och kors. Dietze and Zipf har utvecklat en förlängning av SE, Thematic Symbology Encoding (TSE), som vidgar möjligheterna att använda tematiska kartor i SE[66]. SE har även en del begränsningar för skapandet av kartogram och därmed har en förlänging utvecklats för att möjliggöra skapandet av tematiska kartor och specifikt av kartogram[67]. Det finns för nuvarande inga möjligheter att definiera komplexa och konstnärliga stilar för kartografiska data. Konstnärliga stilar kan vara vägar som ritas med penseldrag eller texturer som efterliknar målningar med akvarellfärg. En förlängning av SE har skapats som innehåller verktyg för att kunna bestämma och kontrollera tekniken för framställning av geografiska data och på så sätt kan personliga kartor skapas[65]. 3.6 Filter Encoding FE är en standard som beskriver ett system av neutral syntax som kan kombinera flera egenskaper i ett objekts attribut för att erhålla en delmängd. Med hjälp av uttryck är det möjligt att visualisera data baserat på skalintervall och därmed filtrera bort oönskad data. FE möjliggör regelbaserad stilsättning, vilket innebär att ett objekt symboliseras utefter ett eller flera attributs värde[68]. Genom frågeuttryck kan data erhållas vars attributvärde är lika med, är större eller mindre än eller inom ett annat objekts attributvärde. Även topologiska relationer kan uttryckas genom exempelvis uttrycken korsar, ligger inom eller vidrör ett annat geografiskt objekt[68]. Funktionaliteten kan jämföras med SQL-språkets WHERE -uttryck. Två uttryck kan kombineras med varandra genom logiska operationer där exempelvis villkoret OCH betyder att båda uttrycken ska vara sant om hela uttrycket ska vara sant och villkoret ELLER betyder att endast ett av uttrycken måste vara sant för att hela uttrycket ska vara sant. FE möjliggör att regelbaserad stilsättning, som är vanligt i Lantmäteriets och andra myndigheters kartor, kan användas. När stilsättningen beror på objektens attribut används regelbaserad stilsättning. Ett exempel är Jordbruksverkets lager Äng- och betesmark som ska stilsättas med hänsyn till attributet markklass. För att utföra stilsättningen så att lagrets objekt kan stilsättas beroende av vilken typ av markklass det tillhör så används regelbaserad stilsättning. Reglerna byggs upp med hjälp av SQL-uttryck. För att kunna stilsätta geografiska objekt efter värden på attribut är regelbaserad stilsättning ett måste. Regelbaserad stilsättning gör det även möjligt att skapa stilsättning som beror på flera attribut[68]. 3.7 Projektfiler Stilsättning i ArcMap och QGIS kan sparas integrerat i projektfiler. Dessa projektfiler skiljer sig åt och hanterar även stilsättningen olika. I projektfilen specificeras i vilken ordning datan ska presenteras, sökväg till källdata och hur lagren ska stilsättas. En projektfil kan delas med andra användare. Om projektfilen används på en ny enhet där datakällan inte finns på samma plats måste användaren definiera en sökväg för alla datakällor så att projektfilen kan hitta dessa. I ArcMap lagras ett projekt i en MXD-fil som är uttryckt i ett språk som är definierat av Esri och som inte är läsbart i en texteditor. Därmed finns det begränsade kunskaper om hur MXD-filer byggs upp. I QGIS lagras ett pro-

47 3.8 programspecifika format för stilsättning 31 jekt i en QGS-fil. En QGS-fil är uppbyggd med XML vilket gör det möjligt att editera projektfilen i en texteditor eller en specifik XML-editor. 3.8 Programspecifika format för stilsättning En LYR-fil används för att stilsätta geografiska data i Esris programvaror. Den lagrar en sökväg till källdatan och definierar dess stilsättning[69]. En LYR-fil innehåller ingen data om attribut och geometri utan beskriver endast hur data ska visualiseras. LYR-filer bygger inte på ett läsbart språk och kan inte öppnas i en texteditor för granskning eller editering. QML är ett format för att lagra stilsättning i QGIS. Formatet är XML-baserat och kan endast läsas av QGIS. QML är inte standardiserat likt SE och kan därmed hantera mer avancerad stilsättning av geografiska data[70]. Nackdelen med att det inte är standardiserat är att portabiliteten inte är lika bra som för SE. Är det av prioritet att stilsättningen ska kunna användas i andra programvaror bör stilsättningen hanteras i formatet SE. 3.9 Scalable Vector Graphics SVG är en specifikation för att definiera tvådimensionell data i XML. SVG distribuerar tre typer av data: vektordata, raster och text. Specifikationen är en öppen standard som är utvecklad av World Wide Web Consortium (W3C). W3C är ett internationellt samfund där medlemsorganisationer, personal och allmänheten arbetar tillsammans för att utveckla standarder för webben. Organisationens syfte är att utveckla webbens fulla potential. Exempel på andra standarder som är utvecklade av W3C är HTML, CSS (se avsnitt 3.2) och XML[71]. En SVG-bild definieras i en XML och kan därför editeras i textredigerare[72]. SVG förlorar inte kvalitet vid zoomning eller storleksändring. Alla element och attribut i SVG-filer kan vara animerade. Eftersom SVG är en W3C standard kan den integreras med andra standarder från W3C såsom Document Object Model (DOM) och EXtensible Stylesheet Language (XSL). DOM är ett gränssnitt som är plattforms- och språkoberoende och som möjliggör för programspråk att dynamiskt läsa och uppdatera innehållet, strukturen och formateringen för ett dokument[73]. XSL är ett språk för stilsättning för XML[74]. Ett exempel på SVG visas i figur 3.8 och resulterar i en gul cirkel med blå linjefyllning och en blå rektangel med grön linjefyllning som visas i figur 3.9. Figur 3.8: SVG-kod som resulterar i en cirkel och en rektangel. Fördelar med att använda SVG framför andra bildformat såsom JPEG och GIF är att[72] SVG-filer kan skapas och editeras i textredigerare SVG är skalbara SVG kan vara sökbara, indexerade, scriptade och komprimerade

48 32 hantering av stilsättning Figur 3.9: Resultat av SVG-koden i figur 3.8. SVG är zoombara SVG är en öppen standard SVG är rena XML-filer Funktionalitet SVG har en funktionalitet som gör formatet lämpligt till att hantera geografiska data. SVG simulerar painters algorithm som i huvudsak betyder att överlappande områden målas över eller, med hänsyn till transparens, skuggar det underliggande lagret[75]. De objekt som är överst i SVG-filen är det objekt som först återges. Objekten som följer återges därefter tills alla objekt har framställts. Enskilda objekt kan samlas i en grupp för framställning. SVG använder ett kartesiskt koordinatsystem med utgångspunkt lokaliserade i det övre vänstra hörnet. Det här medför att när SVG används i kartor måste y-axeln inverteras. Det här kan lösas genom att antingen addera ett minustecken framför y-värdet eller så skapas transformationen med hjälp av en matrisoperation där operationerna översätt, skala, rotation och klippning utförs[75]. För att visualisera en framställning måste även en avgränsning, så kallad viewbox definieras. Avgränsningen kan definieras i SVG-filen eller modifieras på ett interaktivt sätt, genom att zooma eller panorera utan inverkan av användaren. Exempelvis kan boxar över områden indikera var det är möjligt att zooma in för en mer detaljerad bild av området[75]. Även en interaktiv text, exempelvis Zooma in över Malmö kan användas för att zooma in eller ut i ett område. CSS (se avsnitt 3.2) kan användas för stilsättning av objekt i SVG. För stora projekt som innehåller många objekt är det effektivt att använda CSS. Med hjälp av CSS blir det enklare att administrera och modifiera objekts attribut såsom färger, fyllningar, linjefärger, positioner och textstorlek. Alla objekt som har blivit tilldelade en CSS-definition, ändras automatiskt när definitionen av CSS-filen ändras. En fördel med SVG är den fullständiga kompatibiliteten med CSS[75]. Samma format som appliceras i HTML-filer kan också appliceras på SVG-element. CSS-filerna kan lagras i externa filer

49 3.10 sld-prototyp 33 och med hjälp av dem kan hela projekt kontrolleras centralt. Grundläggande geometriska objekt i SVG är: rektanglar, cirklar, linjer, polylinjer, polygoner, ellipser och path-objekt. Det viktigaste elementet är path som även är mest flexibelt[75]. Objektet möjliggör att öppna eller stängda linjer och polygoner, som innehåller en lista med koordinater, skapas. SVG genererar även text och parametrar såsom teckensnitt, storlek, bredd och position som används i Desktop Publishing (DTP) och även inom kartografi, är tillgängliga i SVG. Externa typsnitt kan användas i SVG-filer. Precis som för HTML4, som är en förlängning av HTML, är färgvärden definierade i hexadecimaler[75]. Alla typer av fyllningar, linjer och text kan vara transparenta. Grundläggande interaktionsfunktioner för en SVG-vy är bland annat zoomning, panorering, retur till orginalvyn. Hyperlänkar kan användas för att referera till andra filer eller till andra element inom SVG-dokumentet. I SVG finns det tre olika kategorier av event till förfogande: mouse events, tangentbordsevent och event som ändrar tillståndet för element. Alla event kan kombineras med varandra vilket medför stora möjligheter[75]. Hantering av event är detsamma som i HTML4. I kartapplikationer kan SVG användas för att[75] släcka och tända lager och objekt modifiera grafiska attribut lysa upp objekt när musen är över ett visst objekt interaktivt förflytta, ändra skala, och rotera element digitalisera och möjligöra att spara data på servern för framtida editering och lagring SLD-prototyp Figur 3.10 beskriver modellen som är utgångpunkt för de riktlinjer som är framtagna för tjänsteproducenter som vill erbjuda webbkarttjänster som gör det möjligt för applikationsutvecklare att påverka stilsättningen. Anropen GetCapabilities, DescribeLayers och DescribeFeatureType ersätts med ett exempel på en kodad stilmall, här kallad en SLD-prototyp. Prototypen innehåller all den information som annars skulle ha funnits i svaren från de uppräknade anropen.

50 34 hantering av stilsättning Figur 3.10: Utvecklaren utgår från en SLD-fil som innehåller den information som behövs. Källa: SIS/TK 570[38]. Rapporten Utkast 0.2 Webbkart SLD är ett utkast av den kommande rapporten Webbkarttjänster med av användaren definierade kartskikt från TK570 (se avsnitt 2.6.1) och innehåller bland annat riktlinjer för de tjänsteproducenter som vill erbjuda webbkarttjänster som möjliggör att en applikationsutvecklare kan påverka den kartografiska utformningen genom kodade stilmallar. En SLD-prototyp ska specificera, genom sitt innehåll, de möjligheter och begränsningar som en webbkarttjänst erbjuder en applikationsutvecklare som vill kunna definiera kartografin själv. Webbkarttjänsten baseras på WMS och måste vara kompatibel med SLD, det vill säga erbjuda möjligheten att använda kodade stilmallar. SLD-prototypen ska som tidigare nämnt ersätta det mesta av informationen som ges av anropen GetCapabilities, Describe- Layers, DescribeFeatureType, DescribeCoverage[38]. Informationen ska istället anges direkt eller indirekt, genom att referera andra källor. Prototypen kan ha en begränsad funktion men ska kunna användas som den är utan att servern protesterar. SIS/TK 570 tar upp ett par exempel för de riktlinjer som har definierats för att visa på hur tjänsteproducenter kan underlätta hanteringen av stilmallar för användarna. Alla symboliska namn som kan behövas samt dess innebörd ska anges, direkt eller indirekt, i SLD-prototypen. SLD-prototypen bör med hjälp av XML-kommentarer ange symboliska namns innebörd men också förklaringar, instruktioner och annan dokumentation som riktar sig mot applikationsutvecklaren. Exempel på hur symboliska namn anges med hjälp av <Name>, <PropertyName> och <Literal> bör anges i SLD-prototypen. Tanken är att en applikationsutvecklare ska kunna kopiera SLD-prototypernas element och genom att byta ut symboliska namn och urvalskriterier, göra egna anpassningar av kartan. En annan viktig komponent i prototypen är att den bör beskriva bestämmelser för stavning och kodning av symboliska namn och värden som finns i externa källor. Det kan exempelvis behövas regler för hur blanksteg används eller att särskilda tecken såsom åäö ska ersättas. Även hur numeriska värden och datum ska anges och kodas ska anges i prototypen. UTF-8 bör användas för teckenkodning i prototypen[38].

51 4 Programvaror 4.1 Öppen källkod Öppen källkod avser program som distribueras under licenser som medför att programmen är tillgänglig att läsa, använda, redigera och distribuera vidare, beroende av typ av licens. Öppen källkod möjliggör en utvecklingsmetod för mjukvara som utnyttjar styrkan i distribuerade expertgranskningar och transparenta processer. Fördelarna med öppen källkod är bättre kvalité och pålitlighet, större flexibilitet, lägre kostnader och ett mindre beroende av kommersiella produkter[76]. Open Source Initiative (OSI) är en ideell stiftelse vars vision är att sprida kunskap om, och vikten av, öppen källkod. Stiftelsen har tagit fram Open Source Definition (OSD) som definierar vad som är öppen källkod. Enligt definitionen innebär öppen källkod i korta drag att programvarulicensen för en mjukvara tillåter att källkoden är tillgänglig att läsa och använda[76]. Programvarulicensen tillåter även att källkoden modifieras och distribueras vidare. Det medför att utvecklare kan återanvända och vidareutveckla källkod i egna mjukvaror utan att vara skyldig att betala licensavgifter eller någon annan avgift till källkodens ägare. Modifieringar och härledda arbeten från källkoden måste tillåtas vara distribuerat under samma villkor som licensen för den öppna källkodens mjukvara. Källkoden ska inte heller bara vara tillämplig för specifika system utan för alla som programmet distribueras till. Öppen källkod har även bestämmelser angående att diskriminering av personer eller grupper inte får förekomma. Licensen för mjukvara med öppen källkod får inte heller motverka att källkoden används inom ett specifikt område, som exempelvis i en viss verksamhet[76]. Utvecklingen av mjukvara som är baserad på öppen källkod har under de senaste 15 åren tagit fart. Mjukvara som baseras på öppen källkod och som kan hittas på en dator sträcker sig från ordbehandlare, webbläsare och vetenskapliga applikationer[77] Licenser Det finns flera olika licenser för öppen källkod. Sammanfattningsvis tillåter alla licenserna att källkoden får användas, modifieras och distribueras. För att en mjukvara ska anses vara öppen källkod ska den överensstämma med OSD och godkännas av OSI[76]. För att en licens ska godkännas av OSI ska den uppfylla Open Source Initiative s license review process[78]. Målet med OSI:s License Review Process är att säkerställa att licenser och mjukvaror som definierar sig som öppen källkod också överensstämmer med existerande normer och förväntningar för öppen källkod. Genom att alla licenser går igenom en granskningsprocess som ska vara grundlig, transparent och genomföras inom en rimlig tid ska målet uppfyllas. Syftet med granskningsprocessen är att motverka licenser som saknar mening och innehåll samt är kopior av andra licenser. Ett annat syfte är att identifiera lämpliga kategorier till License Proliferation Category[79]. Licenserna som är godkända av OSI är uppdelade i licenser som är populära och vedertagna eller har omfattande användargrupper har speciella syften

52 36 programvaror är redundanta med andra populära licenser inte är återvinningsbara har ersatts med nyare versioner har dragits tillbaka inte passar in i någon annan kategori. Licenserna har varierande villkor och kan därmed delas upp i olika typer[80]. En vanlig typ av licens är copyleft som tillåter att källkod vidaredistribueras men som kräver att samma licens används som för den ursprungliga koden. Copyleft säkerställer att den ursprungliga källkodens egenskaper bevaras i alla vidareutvecklade källkoder. De flesta licenserna för öppen källkod är av den här typen. GNU License (GNU GPL) är ett exempel på en licens av typen copyleft och används av till exempel QGIS. När mjukvara ges ut med licenser som inte är av typen copyleft medför det att mjukvaran kan användas i program som distribueras under andra licenser, inklusive licenser som inte är för öppen källkod. Dessa licenser är av mer tillåtande karaktär. De här licenserna går under beteckningen non-copyleft och har minimala restriktioner och är tillåtande för hur källkod tillåts användas, modifieras och vidaredistribueras[81]. Skillnaden är att licenserna tillåter att källkod som har utvecklats från den ursprungliga källkoden blir patentskyddad. Licensen kräver endast ett omnämnande av ägaren till källkoden i samband med sin egen kod. Ett exempel på licenser som är av typen non-copyleft är Berkley Software Distribution (BSD). MIT är annan licens som blir allt mer populär och liknar BSD[81]. Eclipse Public License (EPL) är en licens av den här typen som är populär att använda. Licensen Lesser General Public License (LGPL) är ett mellanting mellan GPL och BSD. LGPL är inte lika strikt som GPL då det under vissa förutsättningar går bra att länka till kod som är under LGPL utan att källkoden behöver lyda under LGPL-licens. LGPL används främst för programbibliotek Öppen källkod i GIS Utvecklingen av öppen källkod i GIS har en, i termer av mjukvarans historia, lång tradition. Den första programvaran för GIS i öppen källkod, Map Overlay and Statistical Systems (MOSS), lanserades 1978 och går fortfarande att ladda ner. Open Source Geospatial Foundation (OSGeo) är en ideell organisation som verkar för globalt införande av öppen geografisk teknologi. Organisationen tillhandahåller finansiellt, organisatoriskt och juridiskt stöd till samfund för öppen geografisk teknik[82]. Organisationen tillhandahåller möjligheten för medlemmar att bidra med kod och andra resurser samt med säkerheten att bidragen kommer bevaras för allmänna nyttor. OSGeo:s projekt är gratis att tillhandahålla och använder sig av licenser som är certifierade av OSI. GRASS GIS, gvsig, Marble och QGIS är datorprogram som är projekt från OSGeo. GRASS GIS utvecklades av US Army under tidigt 80-tal och används mycket av universitet och för forskning. GeoServer, MapServer och OpenLayers är exempel på OSGeo projekt inom webbkartografi. Även Post- GIS är ett projekt från OSGeo[82][77]. gvsig är troligtvis det projekt som har fått störst finansiellt stöd och resurser för utveckling. Regional Council for Infrastructures and Transportation (CIT) i Valencia har grundat projektet med syftet att kunna ersätta mjukvara med liknande funktioner som Esris ArcView för kommuner och myndigheter. Bakgrunden till projektet var att regeringen i landet planerade att byta alla system till att vara baserade på Linux[77].

53 4.1 öppen källkod 37 udig är ett program baserat på Eclipse som utvecklades av Refractions Research Inc. Det Kanada-baserade företaget har också utvecklat den geografiska utvidgningen PostGIS till databasen PostgreSQL. Det initiala syftet med udig var att editera vektordata men efter en sammanslagning med JGrass hanterar programmet även analyser av raster[77]. Ett viktigt mål med udig är att utveckla en mjukvara som erbjuder möjligheten att visualisera och editera direkt i databasen och genom en webbläsare. Programmet är distribuerat under licenserna EPL och 3-Clause BSD[77]. udig är en mindre användarvänlig programvara då den bara kan hantera en stilsättning per lager. Om ett linjeobjekt exempelvis består av en gul och en röd linje kan är det inte möjligt att hantera dessa i udigs editor. Karttjänstservers som är baserade på öppen källkod är GeoServer som beskrivs närmare i avsnitt 4.1.4, MapGuide Open Source och MapServer. Map- Server är en plattform för publicering av geografiska data och interaktiva kartapplikationer genom webbläsare. Exempel på spatiala databassystem som är baserade på öppen källkod är PostGIS, SpatiaLite och TerraLib. PostGIS är en spatial förlängning av databasen PostgreSQL som också den är baserad på öppen källkod. OpenLayers och GeoBase är två ramverk för mjukvaruutveckling som också baseras på öppen källkod. OpenLayers är ett bibliotek som tillhandahåller lager med geografiska data QGIS QGIS är en av de största programvarorna inom GIS som är baserat på öppen källkod och stöds av OsGeo. QGIS är en programvara som inte kräver någon avgift och är därmed tillgänglig för såväl professionella användare, studenter samt människor som har ett intresse av geografiska data, analyser, kartframställning eller liknande. Programvaran lanserades för första gången i juli 2002 och är sedan 2007 ett av OSGeo:s officiella projekt. QGIS stödjer flera olika format för vektor, raster och databaser. Likt ArcMap möjliggör QGIS visualisering, hantering, editering och analys av geografisk information. Till skillnad från ArcMap krävs ingen licensavgift eftersom programmet är licenserat under GNU GPL[83]. QGIS kan användas i Windows, Linux, Mac OS X och även i Android som en betaversion. De format som QGIS stödjer är DXF, Shape, raster, Personal Geodatabases, MapInfo och PostGIS. Personal Geodatabasesär en Microsoft Access databas som kan lagra, fråga och hantera både geografiska och icke geografiska data. QGIS kan även kopplas upp mot externa tjänster som WMS och WFS. QGIS möjliggör integrering med andra GIS-program som är baserade på öppen källkod. PostGIS, GRASS GIS och MapServer är exempel på populära GIS-program som QGIS kan integrera med. Insticksprogram som är skrivna i Python eller C++ kan användas för att utöka QGIS användningsområden. I QGIS kan stilsättningen av data exporteras både som SE-fil och som QMLfil som likt SE också är baserat på XML. Skillnaden mellan de två formaten är att QML är specifikt kopplat till QGIS och kan därmed bara läsas av QGIS. Fördelen är att avancerade stilsättningar kan hanteras av QML. Om stilsättningen istället ska användas med andra programvaror måste stilsättning sparas med det mer generella formatet SE. Fördelen är att SE erbjuder god interoperabilitet men med nackdelen att avancerade stilsättningar inte alltid går att spara[70].

54 38 programvaror GeoServer GeoServer är en server baserad på öppen källkod som gör det möjligt att granska, editera och distribuera geografiska data. GeoServer är baserad på Java och har utvecklats med hjälp av GeoTools. Genom att implementera WMS-standarden har användaren möjligheten att visualisera och editera geografiska data. Användaren kan i GeoServer skapa och dela kartor med andra användare[84]. OpenLayers som är ett bibliotek för att visualisera geografiska data i en webbläsare och som tillhandahåller verktyg för att skapa applikationer som innehåller geografiska data är även integrerat i GeoServer. GeoServer är distribuerat under licensen GNU GPL och är gratis att använda. Det är även möjligt att med GeoServer visualisera data genom flera olika kart-applikationer såsom Google Maps, Google Earth, Yahoo Maps och Microsoft Virtual Earth[84]. GeoServer tillhandahåller även ett antal utvidgningar av SLD 1.0 som är specifika för olika leverantörer. Utvidgningarna är inte portabla till andra applikationer men de gör stilsättningen mer användbar och koncis vilket bidrar till visuellt bättre kartor i GeoServer[85]. 4.2 Kommersiella programvaror ArcMap ArcMap är en programvara utvecklad av Esri för att kunna visualisera och analysera geografisk information[86]. Esri har utvecklat GIS-produkter sedan 1980 och 1999 släpptes ArcMap 8 vilket var en sammanslagning av flera olika mjukvaror som Esri tidigare hade separat. För att kunna använda ArcMap ska en licensavgift erläggas. Stilsättningen i ArcMap lagras i LYR-filer, det vill säga, Esris egna format för hantering av stilsättning. Genom användandet av LYR-filer finns det ingen interoperabilitet för stilsättningen mellan ArcMap och andra programvaror.

55 5 Lösningar för stilsättning Det finns flera olika lösningar för konvertering av stilsättning av geografiska data. En stor del av lösningarna grundar sig på Esris programvaror eftersom data ofta är stilsatt med Esris format LYR. Det finns lösningar som uppger att de konverterar LYR-filer till SLD-filer och MXD-filer till QGS-filer. Syftet med dessa verktyg är att de ska fungera som en brygga mellan Esris programvaror och andra programvaror. Gemensamt är dock att de kräver användning av ArcMap och därmed tillhörande licens. Den lösning som ofta används för att kunna visualisera data, som endast är stilsatt genom LYR-filer, korrekt är att skapa en manuell stilsättning genom den programvara som datan ska visualiseras i. 5.1 Konvertering av LYR-fil Det finns ett flertal lösningar som uppges kunna konvertera LYR-filer till SEfiler eller andra format. Tre lösningar av den här typen har hittats genom diverse forum på internet som diskuterar GIS och mer specifikt konvertering av LYR-filer. Även en lösning som uppges kunna konvertera MXD-filer till QGS-filer anses också vara en lösning på problematiken att det inte finns någon interoperabilitet mellan ArcMap och andra GIS-programvaror. Programvarorna som säger sig kunna konvertera till SLD-filer konverterar egentligen stilsättningen till SE, se avsnitt 3.3. SE kommer fortsättningsvis användas för att benämna stilsättningen men i vissa arbetsflöden används SLD eftersom det är programvarornas benämningar på stilsättningen och verktygen GeoCat Bridge GeoCat Bridge är en programvara som gör det möjligt att exportera stilar från ArcGIS-programvaror till SE-filer. Programmet anser sig vara en förlängning av Esri ArcGIS Desktop och förenklar processen för att publicera geografiska data på internet, exempelvis GeoServer eller PostGIS. GeoCat Bridge gör det möjligt att publicera datan direkt på GeoServer och då skickas SE-filer direkt till servern. Det är även möjligt att publicera SE-filen lokalt genom att ange en sökväg där filen ska skapas[87]. GeoCat Bridge är ett kommersiellt program med tillhörande licensavgift. Följande arbetsflöde används för GeoCat Bridge: 1. Programvaran laddas ner från GeoCats hemsida och installeras. 2. Verktyget läggs till i verktygsfältet i ArcMap. 3. När verktyget körs är det möjligt att välja vilka lager och vilken data i lagret som ska publiceras. 4. Datan publiceras på GeoServer eller MapServer. SE-filer och Shapefiler för den publicerade datan kan sparas lokalt enligt en definierad sökväg. 5. SE- och Shape-filerna kan därefter användas i andra programvaror såsom QGIS.

56 40 lösningar för stilsättning Arc2Earth Arc2Earth är en plattform som är designad för användare av ArcMap som vill ha en förbindelse mellan ArcGIS Desktop och andra GIS-program[88]. Plattformen tillhandahåller verktyget Arc2Earth SLD Exporter som exporterar stilsättningen i ArcMap. Arc2Earth stödjer konvertering till ett flertal format, däribland SE, KML och GeoJson. De symboler som inte kan stilsättas genom SE skapar Arc2Earth en egen representation av. För användning av den här plattformen erläggs en årlig kostnad. Följande arbetsflöde används för Arc2Earth: Programvaran laddas ner från Arc2Earths hemsida och installeras. Verktyget läggs till i verktygsfältet i ArcMap. Välj Export och sedan Style and Symbols och SLD. Välj vilka lager som ska exporteras samt var filerna ska sparas ArcGIS-map to SLD Converter I ArcMap finns verktyget ArcGIS-map to SLD Converter som exporterar stilsättning och tillhörande information såsom lagernamn och klasser till SE. Verktyget analyserar projektet i ArcMap med hänsyn till stilsättningen och skapar en SE-fil[89]. Användaren behöver inte fylla i några inställningar för verktyget utan programmet räknar själv ut alla inställningar som krävs för att exportera stilsättningen. Platsen där SE-filen ska lagras specificeras och därefter skapas SE-filen som speglar stilsättningen av det aktuella projektet. SE-filen kan därefter användas i andra sammanhang, som exempelvis för en WMS-tjänst. Verktyget ArcGIS-map to SLD Converter stödjer klassificeringstyper såsom objekt kategorier: unika värden, unika värden: många fält kvantiteter: graderade färger. Punkt-, linje- och ytobjekt stöds av programmet. Följande attribut är implementerade i verktyget för punkter: storlek, färg och rotationsvinkel för linjer: färg och storlek för polygoner: fyllningsfärg, kantfärg och kantstorlek. Verktyget kan användas för projekt som är baserade på data från ArcSDE, Personal Geodatabases och Shape-filer. ArcSDE är en teknik från Esri för access och hantering av geografiska data inom relationsdatabaser MXD2QGS MXD2QGS är ett skript som gör om ett projekt i ArcMap, en MXD-fil, till en QGS-fil, det vill säga en projektfil i QGIS. Skriptet är ett ArcToolBox som är utvecklat av Allan Maungu. Det är gratis att ladda ner men det kräver att ArcMap finns installerat eftersom det är ett insticksprogram i ArcMap[90]. Det här medför ett beroende av licenser från Esri. Programmet underlättar i viss mån användningen av programvaror baserade på öppen källkod eftersom skriptet skapar en brygga mellan ArcMap och QGIS och kan därmed göra beroendet av Esris programvaror mindre. Från QGIS är det därefter möjligt att exportera stilsättning till SE-filer.

57 5.2 användning av befintliga stilsättningar Användning av befintliga stilsättningar Att använda redan existerande stilsättning sammanfattas som Användning av befintliga stilsättningar. Lösningen går dels ut på att använda befintliga stilsättningar som finns tillgängliga på internet för att ladda ner och använda och dels genom att använda befintliga stilsättningar på är insticksprogrammet QGIS Resource Sharing som möjliggör att stilsättning enkelt kan delas mellan olika användare Befintliga stilar QGIS Sverige, se avsnitt 2.6.5, har skapat QML-filer för data i Fastighetskartan, Översiktskartan och Terrängkartan och en QGS-fil för Sverigekartan. Filerna är tillgängliga på deras sida på GitHub med en tillhörande MITlicens. Ett sätt att arbeta är att använda de redan fördefinierade stilarna som erbjuds på GitHub och manuellt utöka med de lager som eventuellt inte har en definierad stilsättning. Det här är en lösning som grundas på manuellt arbete och som bygger på att data stilsätts grundligt och noggrant en gång för att därefter kunna återanvändas. På GitHub finns det en del stilsättningar av Lantmäteriets kartprodukter tillgängliga för nedladdning i formaten QML. Klas Karlsson driver bloggen Geosupportsystem och delar med sig av stilsättningar av Terrängkartan i formatet QML på GitHub. Även en användare på GitHub, Chaoz, har delat med sig av stilsättning av Terrängkartan i formatet QML. Samtliga av dessa stilar verkar efterlikna kartor i tryckt format Resource Sharing Resource Sharing är ett insticksprogram för QGIS som är skapad under Google Summer of Code initierat av organisationen OSGeo. Google Summer of Code är ett projekt där studenter under en sommar får chansen att koda och utveckla öppen källkod. År 2016 utvecklade Akbar Gumbira tillsammans med mentorerna Alessandra Passitti och Anita Graser ett insticksprogram till QGIS som möjliggör för användare av QGIS att dela resurser som symboler, QMLfiler och skript med andra användare av QGIS[91]. En användare som vill dela en resurs lägger upp den på exempelvis GitHub. För att installera Resource Sharing används QGIS Plugin Manager genom att välja Install Plugins... i Plugin menu och därefter söka på QGIS Resources sharing och klicka på Install. Instruktioner för hur verktyget installeras finns tillgängligt på Akbar Gumbiras sida på GitHub. När Resource Sharing är installerat är verktyget tillgängligt i menyn Insticksprogram - Resource Sharing[92]. I verktyget Resource Sharing är det möjligt att bläddra mellan data som är tillgängliga från databaser som är registrerade under Settings, se figur 5.1. Den data som ska användas behöver installeras, vilket enkelt görs i verktyget. För QML-filer visas sökvägen för filerna efter installationen.

58 42 lösningar för stilsättning Figur 5.1: Verktyget Resource Sharing i QGIS. Källa: c QGIS. För att lägga till egna databaser i verktyget krävs en korrekt struktur bland datan i GitHub vilket förklaras i dokumentationen för insticksprogrammet[91]. Filen i databasen som innehåller metadata måste även följa en fördefinierad struktur. För att göra en databas tillgänglig som förinställd databas för alla användare av Resource Sharing krävs det att den är godkänd av administratörerna av verktyget. 5.3 QGS-fil En projektfil för QGIS kan skapas genom att manuellt stilsätta datan i QGIS. Det här är lösningen som beskrivs i avsnitt 7.2 i fallstudien och är den befintliga hanteringen av stilsättning på Tyréns.

59 6 Intervjuer Syftet med intervjuerna är att få en inblick i hur Lantmäteriet och andra organisationer hanterar stilsättning av geografiska data. Ett mål är att klargöra problematiken kring hanteringen av stilsättning. Vilka för- och nackdelar det finns med de olika formaten som hanterar stilsättning är en annan frågeställning som tas upp i intervjuerna. Ett annat mål med intervjuerna är att få en uppfattning om hur framtiden kan komma att se ut. 6.1 Sara Stefansson, Produktchef Lantmäteriet En intervju hölls den 21 februari 2017 med Sara Stefansson, produktchef på Lantmäteriet. Intervjun kan sammanfattas med att Lantmäteriet i många år har levererat geografiska data i vektorformaten Shape och MapInfo TAB där Shape med tiden blivit ett standardformat. Sara säger att de är medvetna om att det är ett problem att det inte finns något format för stilsättning som passar alla programvaror och att de inte har hittat någon form av standardlösning heller. Sara Stefansson berättar att Lantmäteriet i många har levererat vektordata i formaten Shape och MapInfo TAB då Shape har blivit en vedertagen standard. I takt med att programvaror baserade på öppen källkod har blivit allt mer vanligt har också förfrågningar om vi inte ska leverera data i något annat format ökat. Vi är medvetna om problematiken men har än så länge inte haft möjligheten att utveckla något mer, säger Sara Stefansson. På frågan om det skulle vara ett stort arbete att erbjuda även andra format för stilsättning svarar Sara Stefansson att desto fler format, desto större arbete. Vidare berättar Sara Stefansson att Lantmäteriet har ett projekt där de tittar på olika frågor relaterade till kartor. De är medvetna om problemet och att användare efterfrågar modernare format. Sara Stefansson berättar att önskan är att hitta någon standardlösning som är programoberoende men de flesta formaten för stilsättning är ofta knutna till den programvara de används i. Lantmäteriet har även haft diskussioner om SLD men det har varit svårt att återge den kartografi som Lantmäteriet använder. Lantmäteriet är väldigt noga med att den data som ges ut håller en hög kvalitet. I dagsläget är ingen rapport på gång inom stilsättning. Sedan måste en avvägning om hur viktigt det är att erhålla en stilsättning som stämmer helt och hållet överens med andra stilsättningar av Lantmäteriets kartor eller om det räcker med att skapa stilsättningar som har ungefär samma stilsättning och ger en läsbar karta, berättar Sara Stefansson. Angående det informationsansvar enligt Inspire som Lantmäteriet har så handlar det rent konkret om att en infrastruktur ska byggas för de informationsmängderna. Lantmäteriet ska ha någon typ av nedladdningstjänst och en visningstjänst som följer de framtagna specifikationerna och genomförandebestämmelserna. Det är därmed ganska uppstyrt kring hur de tjänsterna ska fungera och vad de ska innehålla. Vidare berättar Sara Stefansson att de är informerade om det arbete QGIS Sverige utför med stilsättning av Lantmäteriets kartprodukter. Det är ett tidskrävande arbete och det hade varit bra om det görs centralt.

60 44 intervjuer 6.2 Anders Skog, Projektledare SIS Den 9 mars 2017 hölls en intervju med Anders Skog som arbetar på SIS. Intervjun handlade om den kommande rapporten Webbkarttjänster med av användaren definierade kartskikt som SIS/TK 570 planerar att ge ut under året. Under intervjun gavs tillgång till ett utkast av rapporten. Rapporten ska ses i kontrast mot den tidigare av SIS/TK 570 utgivna rapporten Webbkarttjänster med av producenten definierade kartskikt. Rapporterna handlar i stora drag om hur webbkarttjänster bör konstrueras beroende på om användaren eller producenten definierar kartskikten. I rapporten definieras en tjänst som en paketerad service eller lösning som erbjuds för att tillgodose ett behov och därmed ska en webbkarttjänst erbjudas och kunna användas direkt enligt erbjudandet. Den som använder tjänsten ska inte påverka vad den ska erbjuda. En stilmall definieras här som en samling av regler som styr symbolisering hos ett kartskikt. Den här stilmallen ska skiljas från kodade stilmallar som anges med XML-elementet UserStyle i en SLD-fil[38]. I den här rapporten är SLD enabled WMS den typ av server som är utgångspunkten. Gränssnittet för servern omfattar både hur kartografin anpassas och hur tjänsten kan användas. En applikationsutvecklare kan anpassa kartografin genom att redigera XML-kod. Det här kan upplevas som en tröskel för att använda tekniken. Den huvudsakliga idén i riktlinjerna är därmed att tjänsteproducenten ska utveckla så pass väldokumenterade exempel, så kallade SLD-prototyper, att den här tröskeln sänks[38]. Anders Skog berättar att grundproblemet när det gäller webbkartografi är att det finns flera producenter av data som ska användas i samma karta. Den här datan ska kunna sättas ihop i kartor och utgångspunkten är att kunna kombinera data. Det som inte är önskvärt är till exempel att bilderna krockar med varandra och att vissa ytor är heltäckande och därmed täcker över annan data. Anders Skog berättar därefter om de olika arbetsmetoder som finns för kartografisk samverkan och kommande redogörelse är en sammanfattning av vad intervjun handlade om. Det finns olika sätt för kartografisk samverkan och figur 6.1 visar en enkel modell som ligger till grund för att beskriva olika lösningar. Utgångspunkten är att en producent tillhandahåller eller skapar geografiska data(1) och tjänster(2) som är tillgängliga för en utvecklare att använda i en webbkarta(3). Genom den här lösningen får användaren(4) tillgång till ändamålsenliga kartor. Det som visas i den här och följande lösningar är hur data, tjänster och webbkartor produceras och används. Det som inte visualiseras är hur producenterna får reda på vilka behov och krav användarna har. Antagande görs att behovet kommuniceras genom dialog, kravinsamling och kravspecifikation. Hur producenterna och utvecklaren kommunicerar beskrivs inte heller men i princip görs det genom att utvecklaren beskriver sitt behov eller att producenterna erbjuder det som finns och användaren väljer av det befintliga utbudet[38].

61 6.2 anders skog, projektledare sis 45 Figur 6.1: Enkel lösning. Källa: SIS/TK 570[38]. En frågeställning i rapporten är Hur får man tag i kartskikt som går att kombinera. Anders Skog berättar att det finns flera olika sätt att arbeta med såsom att komma överens med producenterna och beställa de kartskikt som behövs. En förklaring av den här lösingen visas i figur 6.2. Utvecklarna behöver då beskriva användarens behov och därefter konstruerar producenten tjänsten utifrån kraven. Det här är en vanlig metod men den kräver att användaren i ett tidigt skede påverkar tjänsten. Långa ledtider samt att utvecklaren kanske inte har möjligheter att påverka producenten är nackdelar med metoden[38]. Figur 6.2: Kommer överens med producenterna och beställer kartskikt. Källa: SIS/TK 570[38]. Ett annan metod visas i figur 6.3 och bygger på att inte använda WMStjänster utan att använda nedladdningstjänster och utforma stilsättningen på egen hand[38]. Det här är givetvis en tidskrävande lösning men med fördelen att kartan kan anpassas efter exakta krav. Det här arbetssättet är förhållandevis vanligt och liknar till viss del det arbetssättet som Tyréns vill komma ifrån. Problemet med den här lösningen är att alla medarbetare inte har de tekniska kunskaperna som krävs och därmed är det enklare och

62 46 intervjuer mer bekvämt att använda data som har använts i tidigare projekt men som kanske inte längre är korrekt. Figur 6.3: Hämta all data och göra hela arbetet själv. Källa: SIS/TK 570[38]. Figur 6.4 visar en bra lösning där de bästa av alternativa kartskikt som erbjuds används. Anders berättar att idéen med rapporten är att för en producent är det inte svårt att erbjuda alternativa stilsättningar för samma objekttyp. Rapporten Webbkarttjänster med av producenten definierade kartskikt handlar om att riktlinjer för hur de här varianterna ska väljas så att de blir så flexibla som möjligt för utvecklaren. Nackdelen med lösningen är att det är helt upp till producenterna att erbjuda kartskikt och därmed kan det saknas utformningar som en viss användare kan behöva. Den här lösningen används inte så ofta även om det generellt är en bra lösning. Figur 6.4: Bra lösning är att använda de bästa av de alternativa kartskikt som erbjuds. Källa: SIS/TK 570[38]. En flexibel lösning visas i figur 6.5 och avser de fall som tas upp i den här rapporten, Webbkarttjänster med av användaren producerade kartskikt. Genom det här arbetssättet är det möjligt att själv styra utformningen av kartskikten med hjälp av stilmallar. I den här lösningen används SE för att tala

63 6.2 anders skog, projektledare sis 47 om för servern hur en viss objekttyp ska stilsättas. Nackdelarna är att den här lösningen inte alltid finns implementerat hos tjänsteleverantörerna eller producenterna samt att användningen av SE medför vissa begränsningar, se avsnitt 3.4. I den här lösningen blir applikationsutvecklarens roll att genom kodning välja kartografi. Det här är ett arbetssätt som kan kännas främmande för en del som arbetar som utvecklare. Figur 6.5: Flexibel lösning. Källa: SIS/TK 570[38]. Figur 6.6 beskriver den modell som är utgångspunkten för rapportens riktlinjer. Anropen GetCapabilities, DescribeLayer och DescribeFeatureType ersätts med ett exempel på en kodad stilmall som kallas för SLD-prototyp. All den information som skulle ha funnits i svaren på anropen finns istället i prototypen. Riktlinjerna vänder sig till de tjänsteproducenter som vill erbjuda möjligheten för applikationsutvecklare att påverka kartografin genom kodade stilmallar. Figur 6.6: SLD-prototyp. Källa: SIS/TK 570[38]. Tanken är att SLD-prototypen framför allt ska ta upp namn på geodataskikt, variabler och värden och inte alla de möjligheter som är dokumenterade i SE-, FE-, SVG- eller CSS-standarden. SLD-prototypen bör ange alla de sym-

64 48 intervjuer boliska namn som kan behövas och innebörden av dem. Symboliska namn är de som används för att referera data och som kan vara mer eller mindre kryptiska och därmed är det nödvändigt att klargöra innebörden direkt i XML-kommentarer i SLD-prototypen eller genom hänvisning till andra källor. Syftet med SLD-prototypen är att en applikationsutvecklare ska kunna använda prototypens element och bara göra egna anpassningar genom att byta ut symboliska namn och värden som anger urvalskriterier och kartografi.

65 7 Fallstudie En fallstudie genomförs som syftar till att utreda hur väl de framtagna lösningarna bidrar till att öka kompatibiliteten mellan olika format som hanterar stilsättning. Tyréns har inom många olika avdelningar ett behov av att visualisera och analysera geografiska data. Val av program för dessa uppgifter är delvis en fråga om personligt tycke och smak men det finns flera fördelar med möjligheten att använda mer än ett program. Genom möjligheten att använda flera likvärdiga program och med likvärdiga arbetsflöden kan varje medarbetare välja det program som passar bäst för den aktuella uppgiften. Genom en ökad kompatibilitet mellan olika format ökar möjligheterna att använda flera programvaror. Syftet med fallstudien är att hitta en lösning som uppfyller de behov som Tyréns medarbetare har av att använda andra programvaror än ArcMap. I avsnitt 7.1 presenteras Tyréns kartportal och i avsnitt 7.2 redogörs det för hur hantering av stilsättning utförs i dagsläget. En framtagen kravspecifikation presenteras i avsnitt 7.3. De geografiska objekten som ingår i fallstudien presenteras i avsnitt 7.4 och följs upp i avsnitt 7.5 med redogörelse av hur datan har valts ut. I avsnitt 7.6 presenteras sedan samtliga metoder som används i fallstudien. Hänvisningar kommer ske i respektive metod till ett av flödena (1-5) i figur 7.1. Den tekniska kravspecifikationen utvärderas i avsnitt 7.7 till 7.9. Den generella kravspecifikationen utvärderas i avsnitt 8.1. LYR-fil 2 MXD-fil Befintlig stilsättning QML-fil 1 Arc2Earth, GeoCat, ArcGIS-map to SLD Converter 2 SE MXD2QGS 4 3 QGS-projektfil 5 QML-fil Visualisering i ArcMap Visualisering i udig Visualisering i QGIS Kravspecifikation 1 2 Utvärdering Figur 7.1: Flödesschema för fallstudien. Flöde nummer 1 i figur 7.1 beskriver hur MXD-filer visualiseras i ArcMap. Eftersom ArcMap direkt kan läsa av MXD-filer behövs ingen konvertering. Flöde nummer 2 redogör för hur MXD-filer konverteras i lösningarna Arc- 2Earth, GeoCat Bridge och ArcGIS-map to SLD Converter till SE-filer som sedan visualiseras i udig och QGIS. Flöde nummer 3 visar hur en MXD-fil konverteras till en QGS-fil i lösningen MXD2QGS. Flöde nummer 4 beskriver manuell konvertering från MXD-fil till QGS-fil. Flöde nummer 5 beskriver användningen av befintliga stilar samt den komplettering av stilar som krävs. Samtliga flöden resulterar i en utvärdering efter kravspecifikationen.

66 50 fallstudie 7.1 Tyréns kartportal Via Tyréns intranät finns tillgång till Tyréns egenutvecklade kartportal. Syftet med kartportalen är att medarbetare ska kunna ladda ner öppna geografiska data från en källa istället för att besöka varje myndighets hemsida. Kartportalen säkerställer även att data är korrekt och uppdaterad. Ett exempel på hur processen ser ut visas i figur 7.2. Processen för att få tillgång till data sker i tre steg: 1. Användaren markerar aktuellt område för hämtning av geografiska data. Det här görs genom att rita in området på kartan. 2. Användaren väljer vilka typer av kartprodukter som ska levereras samt vilket koordinatsystem och format datan ska levereras i. 3. Det sista användaren gör är att trycka på Beställ data. En zip-fil laddas ned med beställd data. När zip-filen extraheras erhålls en mappstruktur med en mapp för varje vald kartprodukt. Mapparna innehåller filer som beskriver objektens geometri och attribut. Om det finns metadata och information om stilsättning för en kartprodukt sparas det i en separat mapp. Figur 7.2: Tyréns kartportal. Källa: c Tyréns. 7.2 Befintlig hantering av stilsättning För att medarbetare på Tyréns ska kunna visualisera datan i andra program än ArcMap måste stilsättningen skapas manuellt. Detta flöde presenteras som nummer 5 i figur 7.1. Användaren i bilden symboliserar det manuella arbete som krävs för att konvertera LYR-filen till QML-filer eller en QGSfil. För att inte varje medarbetare som hämtar data från kartportalen ska behöva stilsätta datan har Tyréns GIS-avdelning valt att skapa stilsättningen

67 7.3 kravspecifikation 51 centralt. Genom att stilsätta datan en gång och sedan leverera den i varje nedladdning från kartportalen kringgås problemet med att varje medarbetare ska skapa stilsättning för den nedladdade datan. Arbetsflödet för stilsättning går till enligt följande: 1. Ett arbetsflöde skapas i FME för att ladda ner ett objekt av varje lager som är tillgängligt i kartportalen. 2. LYR-filer hämtas från leverantörerna. 3. En ny MXD-fil skapas i ArcMap. 4. Data från arbetsflödet i FME och tillhörande LYR-filer öppnas i ArcMap. 5. En ny QGS-fil skapas i QGIS. 6. Stilsättningen i QGIS hanteras manuellt. Genom att kontrollera stilsättningen i ArcMap skapas en liknande stilsättning i QGIS. Det finns en funktion i QGIS, Plocka färg, som gör det enkelt att använda exakt samma färg som i ArcMap. När lager symboliseras med någon form av mönster blir dock stilsättningen svårare att hantera. I dessa fall gäller det att efterlikna stilsättningen så bra som möjligt. Det här kräver lite mer bearbetning men resultatet blir i de flesta fall bra. 7. I de fall stilsättning beror på attribut används regelbaserad stil som utformas efter de regler som används i ArcMap. Först kontrolleras om Definition Query har använts för lagret. Sedermera kontrolleras vilket attribut som har använts för symboliseringen samt vilka värden för attributen som ska stilsättas på ett visst sätt. Den här informationen slås samman och används i den regelbaserade stilen i QGIS. 8. En stor del av stilsättningen i QGIS består av att ordna lager i korrekt ordning. För att det ska bli så enkelt som möjligt för medarbetarna att använda både ArcMap och QGIS ska lagerstrukturen vara densamma. Det här innebär att grupper med lager måste skapas i QGIS och namnges i enlighet med lagerstrukturen i ArcMap. 9. Strukturen och stilsättningen sparas i projektfilerna och sökvägarna till datan sätts till relativa så att de lager som ska stilsättas hittas i samma mapp som projektfilen. På så sätt kan projektfilen skickas med oavsett vilken beställning som görs från Kartportalen och användas för de lager som har valts ut. 10. Slutprodukten för stilsättningen blir MXD- och QGS-filer som används i leveranserna från kartportalen. På så sätt kan den manuellt skapade stilsättningen användas i alla leveranser från kartportalen. 7.3 Kravspecifikation Kravspecifikationen syftar till att specificera hur en konvertering hanterar stilsättning och arbetsflöde. Vid framtagning av kravspecifikationen har tillgängliga data på Tyréns kartportal studerats och hänsyn har tagits till nedladdningsstatistik, se figur 7.3 i avsnitt 7.5. Att utreda hur väl lösningarna visualiserar tematiska kartor som exempelvis kartogram är inte relevant eftersom den typen av data inte används lika ofta som topografiska kartor som exempelvis jordartskartor eller berggrundskartor. Fallstudien kommer att innehålla objekt med och utan regelbaserad stilsättning, se avsnitt 3.6. Anledningen till det här är att en stor del av myndigheternas data stilsätts med regelbaserad stilsättning och därmed är det viktigt att testa hur väl lösningarna hanterar den här typen av stilsättning.

68 52 fallstudie Samtliga lösningar ska utvärderas efter en generell kravspecifikation vars syfte är att utreda hur väl det fungerar att arbeta med de olika lösningarna. En specifik kravspecifikation har tagits fram för varje lösning då de kräver olika mycket manuellt arbete. Högre krav ställs därmed på de lösningar som innefattar stort manuellt arbete Generell kravspecifikation Alla lösningar ska utvärderas efter följande önskvärda krav: 1. Arbetsflödet ska vara enkelt. 2. Uppdateringsrutinerna ska vara enkla. 3. Lösningen ska inte kräva orimligt mycket resurser i förhållande till nyttan. 4. Resultatet ska vara likvärdig med stilsättningen i ArcMap. 5. Lösningen ska ha goda framtidsutsikter gällande det format som resultatet erhålls i. Den generella kravspecifikationen utreds i kapitel Kravspecifikation för Konvertering av LYR-fil För att lösningen Konvertering av LYR-fil ska anses uppfylla kravspecifikationen har följande krav tagits fram. Följande krav är absoluta: 1. Punkters storlek ska bibehållas efter konverteringen. 2. Streckade linjer ska bibehållas efter konverteringen. 3. Linjer som består av två eller flera symboler ska vara likvärdiga efter konverteringen. 4. Hexadecimala färgkoder ska vara samma efter konverteringen. 5. Yttäckande mönster ska efter konvertering ha likvärdiga mönster. 6. Symboler ska efter konvertering vara likvärdiga. 7. Illustrativa symboler ska efter konvertering fortfarande vara illustrativa. Följande krav är önskvärda: 1. Hela kartan kan stilsättas samtidigt istället för att varje lager stilsätts var för sig. 2. Lösningen ska konvertera stilsättningen på en rimlig tid. Dels ska programmets exekveringstid tas i beaktning samt hur lång tid det manuella arbetsflödet tar. Kravspecifikationen för konvertering utreds i avsnitt till avsnitt

69 7.4 geografiska objekt i test Kravspecifikation för Användning av befintliga stilsättningar För att lösningen Användning av befintliga stilsättningar ska anses uppfylla kravspecifikationen har följande krav tagits fram. Följande krav är önskvärda: 1. En hel kartprodukt ska vara stilsatt. Alternativet är att det tydligt framgår vilken data som är stilsatt. 2. Stilsättningen ska ha någon form av kvalitetskontroll där det framgår vem som har kontrollerat stilsättningen. 3. Tillgång till stilsättningen ska vara enkel. Kravspecifikationen för Användning av befintliga stilsättningar utreds i avsnitt Kravspecifikation för QGS-fil Lösningen QGS-fil har hårdare krav på stilsättningen eftersom den skapas manuellt. För att lösningen ska anses uppfylla kravspecifikationen har följande krav tagits fram. Följande krav är absoluta: 1. Det ska vara möjligt att skapa en stilsättning som är likvärdig med stilsättningen i ArcMap. 2. Verktygen för stilsättningen ska vara enkla att använda. Kravspecifikationen för QGS-fil utreds i avsnitt Geografiska objekt i test Följande objekt ska användas för att utreda hur väl de olika lösningarna fungerar. Objekten är definierade enligt HMK -Kartografi och är objekt som ofta används i kartor över Sverige[35]. 1. Heldragen linje: Heldragna linjer används vanligen som avgränsning av olika ytor samt för objekt med linjär utsträckning som exempelvis vägar och ledningar ovanför mark. Gränsers hierarkiska förhållande visas genom skillnad i bredd på linjen. 2. Streckad linje: Streckad linje är en väl använd stilsättning för kartor. Det används främst för olika typer av fastighetsgränser och administrativa gränser. Streckade linjer används även för planerad eller framtida markanvändning samt för objekts som är placerade under det avbildade planet. För objekt ovanför det avbildade planet används streckprickad linje. Gränsers hierarkiska förhållande visas genom skillnad i förhållandet strecklängd och mellanliggande avbrott. 3. Ytsymboler: För beteckning av ytors egenskaper kan särskilda ytsymboler användas. Rekommendationen i HMK-Kartografi är att valet av ytsymboler bör ske i enlighet med den tradition som har utvecklats i den storskaliga kartografin. Egenskaper som kan visualiseras med ytsymboler är skog, odlad mark, sankmark, berg i dagen, fornlämningar och kyrkogård. En variant är att använda bokstäver för att beteckna en ytas egenskaper. Bokstäver används ofta för att beteckna områden såsom sjöar, servitut, natur- och byggnadsminnen och parkeringsplatser. Även traktnamn och namn på fastigheter kan betraktas som ytsymboler. Det är viktigt att den underliggande informationen inte försvinner under kartans ytmanér.

70 54 fallstudie 4. Ytavgränsningar: Även avgränsningarna av ytorna utgör en del av visualiseringen. Heldragna, streckade eller prickade linjer kan användas för kartredovisningen. Visualiseringen har en hierarki genom att tydliga avgränsningar mellan till exempel skog och vägbana redovisas med heldragna linjer. Mer diffusa avgränsningar som områden med fornlämningar, berg i dagen, kärr och mossar, ängs- och hagmark visualiseras med prickade linjer. Fastigheter avgränsas vanligen med streckade och kombinationer av streckprickade linjer. Korta streck används för att markera anläggningar under mark. 5. Yttäckande mönster och färgtoner: Ett alternativ till ytsymboler är yttäckande mönster för att redovisa ett område. DE kan vara av punktraster med olika täthet eller linjeraster i olika variationer. När både samband och differentiering av kartinnehållet eftersträvas i storskaliga kartor kan färg användas. Bebyggelse som är av olika typer kan även använda färg för att särskiljas. 6. Symboler: För att förtydliga eller systematisera vissa objekt bör symboler användas. Symboler kan inordna sig i en visuell hierarki beroende på hierarkin mellan de objekt som symboliseras. Symboler är inte skalenliga. Det finns två principer för utformning av symboler, enkla och illustrativa symboler. Enkla symboler kräver en förklaring för förståelsen medans illustrativa symboler i sig är förklarande genom sin utformning. 7. Ytsymboler: För yttäckande information som exempelvis vegetation eller markanvändning bör ytsymboler användas. 8. Punktsymboler: Punktsymboler används vid representation av punktvisa objekt som egentligen kan definieras med ett koordinatpar. 9. Linje som består av två eller flera symboler: Järnvägsspår och liknande linjer symboliseras ofta med hjälp av olika kombinationer av symboler. Ett exempel kan vara en streckad linje med kryss över linjerna. Det här är vanliga stilsättningar för kartor men de beskrivs inte i HMK-Kartografi. Valet har gjorts att ändå ta med denna typ av symbolisering i fallstudien då den är en stor del av stilsättningen av geografiska data. 7.5 Data i studien Enligt den totala nedladdningsstatistiken för Tyréns kartportal utgör Lantmäteriets och SGU:s kartprodukter nästan hälften av alla nedladdningar, se figur 7.3. För att fallstudien ska efterlikna ett verkligt arbetesflöde så mycket som möjligt har geografiska objekt från de här kartprodukterna använts i fallstudien. Det geografiska område som data har hämtats från är Malmö. Den data som ska användas i testen har valts ut för att täcka alla geografiska objekt enligt den lista som presenteras i avsnitt 7.4. Objekt har valts ut som är representativa för dessa objekt och de redovisas i appendix B.

71 7.6 metod 55 Figur 7.3: Produktpopularitet för Tyréns kartportal. Data erhållen den 24 februari Källa: c Tyréns. Vid lösningen Användning av befintliga stilsättningar kan det inte alltid garanteras att stilsättning av alla objekt samt kartprodukter finns att tillgå. Därmed kommer data i dessa test vara annorlunda jämfört med de andra lösningarna. För att studien av befintlig stilsättning ska vara relevant har valet gjorts att studera den stilsättning som finns att tillgå. QGIS Sverige har samlat stilsättning i ett utvecklingsprojekt på GitHub. QGIS Sverige har skapat QML-filer för data i Fastighetskartan, Översiktskartan och Terrängkartan. Stilsättning av Sverigekartan är tillgänglig som QGS-fil. På GitHub finns det en del stilsättningar av Lantmäteriets kartprodukter tillgängliga för nedladdning i formaten QML. Befintlig stilsättningar har även för Översiktskartan på GitHub och kommer därför också med i studien. 7.6 Metod Lösningarna som ska testas har delats upp i olika grupper. De lösningar som konverterar LYR- eller MXD-filer testas efter en generell metod i avsnitt Användning av befintliga stilsättningar testas efter en annan metod som förklaras i avsnitt QGS-fil testas efter en metod som förklaras i avsnitt Det program som lösningarna kommer att testas med är QGIS och udig då det är programvaror som är vanligt förekommande och inte kräver en licensavgift vilket gör de tillgänglig för många användare. Om en lösning resulterar i en SE-fil kommer resultatet av lösningen granskas i SE-editorn udig samt i QGIS medan lösningarna som resulterar i QGS- eller QML-filer endast granskas i QGIS. Anledningen till att resultatet presenteras i QGIS och udig är att QGIS inte kan skilja på om en stilsättning i en SE-fil är definierad i pixlar eller millimeter. SE-filer definierar storlekar i pixlar medan QGIS läser in storleken i millimeter. Detta innebär att tjockleken för exempelvis en linje blir nästan 4 gånger så stor som samma linje i ArcMap. Problemet kan enkelt lösas genom att för varje objekttyp definiera storleken som pixlar. Dock blir det väldigt tidskrävande om ett lager består av många objekttyper. Då det här är en tidskrävande redigering som bör tas i beaktning för lösningen har vi valt att presentera resultatet utan manuell redigering i QGIS. udig används också för att kunna göra en korrekt bedömning av konverteringarna till SE.

72 56 fallstudie Konvertering av LYR-fil De befintliga lösningar som ska testas utifrån kravspecifikationen i avsnitt är: GeoCat Bridge Arc2Earth ArcGIS-map to SLD Converter MXD2QGS. Dessa lösningar har valts ut för att de är tillgängliga för nedladdning eller köp via internet. Det är möjligt att det finns andra lösningar som uppfyller kravspecifikationen, men som inte har hittats på internet. De lösningar som testas i studien har alla diskuterats i forum och på liknande plattformar som diskuterar konvertering av LYR-filer. Arc2Earth, GeoCat Bridge och ArcGIS-map to SLD Converter är lösningar som omvandlar LYR-filer till SE-filer. Flödet för dessa konverteringar är nummer 2 i figur 7.1. MXD2QGS är en lösning som konverterar en MXD-fil till en QGS-fil och arbetsflödet är nummer 3 i figur 7.1. Lösningarna testas enligt följande metod: 1. Data visualiseras i ArcMap med LYR-filer. 2. Konvertering av LYR-filer till SE-filer eller MXD-fil till QGS-fil genomförs. 3. Data med tillhörande ny stilsättning visualiseras i QGIS och/eller udig. 4. Stilsättningarna jämförs. 5. Lösning utvärderas i enlighet med kravspecifikationen i avsnitt Användning av befintliga stilsättningar De befintliga stilsättningar som har valts ut är de som har funnits på internet. Det är möjligt att det finns andra befintliga stilsättningar som uppfyller kravspecifikationen men dessa har vi inte lyckats hitta. Användning av befintliga stilsättningar visas som nummer 5 i 7.1 och testas enligt följande metod: 1. Kartlägg vilken data som är stilsatt. 2. Den befintliga stilsättningen laddas ner från källan. 3. Datan med den befintliga stilsättningen visualiseras i QGIS. 4. Den data som är stilsatta genom befintliga stilsättningar visualiseras i ArcMap med befintliga LYR-filer. 5. Stilsättningarna jämförs. 6. Lösning utvärderas i enlighet med kravspecifikationen i Resource Sharing testas som hjälpmedel i kombination med Användning av befintliga stilsättningar genom följande metod: 1. Via QGIS Plugin Resource Sharing erhålls stilsättning för den aktuella datan. 2. Stilsättningen installeras.

73 7.7 resultat för konvertering av lyr-fil QML-filerna importeras till datan. 4. De lager som saknar offentlig stilsättning stilsätts och läggs upp på QGIS-plugin: Resource Sharing. 5. Data visualiseras i QGIS. 6. Data visualiseras i ArcMap med LYR-filer. 7. Stilsättningarna jämförs. 8. Lösning utvärderas i enlighet med kravspecifikation i QGS-fil Metoden för att testa lösningen QGS-fil är arbetsflödet som beskrivs i avsnitt 7.2. Projektfilen visualiseras i QGIS och jämförs därefter med motsvarande stilsättning i ArcMap. 7.7 Resultat för konvertering av LYR-fil Resultatet av lösningarna GeoCat Bridge och Arc2Earth redovisas i appendix C och lösningen MXD2QGS redovisas i appendix E. Figurerna som resultatet refererar till är namngivna efter vilken underrubrik de redovisas i och varje underrubrik innehåller sex figurer. Den första figuren visualiserar myndigheternas data i ArcMap och de andra figurerna visar datan efter konverteringen genom GeoCat Bridge genom GeoServer, GeoCat Bridge presenterat i QGIS, GeoCat Bridge presenterat i udig, Arc2Earth presenterat i QGIS och Arc2Earth presenterat i udig. Lagerna redovisas även i tabellform i appendix D GeoCat Bridge Möjligheten att i ett dialogfönster välja vilka lager som ska konverteras till SE gör programmet effektivt att använda. Det underlättar att inte behöva markera alla lager i ArcMap som ska konverteras då det kan störa det nuvarande arbetet i ArcMap. Vilka attribut i lagren som ska konverteras går också att välja i dialogfönstret. Genom konverteringen från LYR-fil till SE-fil uppfylls det önskvärda kravet på att hela kartan kan konverteras samtidigt. Resultatet av konverteringen är en Shape-fil och en SE-fil för varje lager som sparas i den sökväg som har angivits. Datan publiceras om så önskas även på GeoServer. En WMS-anslutning krävs mellan QGIS och GeoServer för att kunna visualisera data från GeoServer i QGIS. För att visualisera alla lager i QGIS krävs manuell redigering. Alla lager måste importeras till ett projekt i QGIS och därefter måste stilsättningen läsas in i form utav de SE-filer som följde med vid konverteringen av datan. Resultatet av SE-filerna granskas i QGIS samt udig och resultatet diskuteras i följande avsnitt. Punkter med enkel stilsättning Punkter med enkel stilsättning visas i figur C.1.a och får efter konvertering korrekt färg och storlek (se figur C.1.c och C.1.d). Tabell D.1 bekräftar även att konverteringen blivit rätt. När punktobjekten visas som WMS, se figur C.1.b, blir punkterna identiska med originalpunkterna. Symbol för järnväg Symbol för järnväg visas i figur C.2.a och består av två olika lager, dels en cirkel och dels bokstaven J i teckensnitt Arial. Resultatet av konverteringen

74 58 fallstudie visas i figur C.2.c och C.2.d. udig och QGIS visar alltså olika resultat för samma SE-fil. udig visar en korrekt stilsättning medan QGIS visar bokstaven J som Simple marker (se tabell D.2). När punktobjekten visas som WMS, se figur C.2.b, blir symbolerna identiska med originalpunkterna. Bebyggelsesymboler Bebyggelsesymboler visas i figur C.3.a och resultatet varierar beroende på vilken programvara SE-filen visualiseras i. I QGIS blir resultatet enligt figur C.3.c och i udig enligt figur C.3.d. Resultatet i QGIS visar att symbolerna fått rätt färg men fel font-stil medan resultatet i udig stämmer med originalsymbolerna. I tabell D.2 redovisas att font-stilen visas som Simple marker i QGIS. När resultatet visas som WMS visualiseras ingen data. Begränsningslinjer för markslag Begränsningslinjer för markslag visas i figur C.4.a och resultatet för konverteringen visas i figur C.4.c och C.4.d. Stilsättning efter konvertering visar sig stämma överens i stora drag men med skillnaden att begränsningslinjerna är svagare efteråt. Tabell D.4 visar att konverteringen blivit rätt, och därmed beror skillnaden på hur QGIS och udig presnetera SE-filen. Resulterande konvertering presenterad som WMS visas i figur C.4.b och linjeobjekten blir lika breda som när begränsningslinjer visas i ArcMap. Administrativa gränser Konverteringen av lagret Administrativa gränser visar sig fungera väl. Administrativa gränser före konvertering visas i figur C.5.a och i figur C.5.c och C.5.d visas resultatet efter konverteringen i QGIS respektive udig. Tabell D.5 visar även att bredden för linjerna samt mönster för kommungräns konverterats till rätt värden. När lagret visualiseras som WMS i figur C.5.b blir resultatet likt originallagret. Kraftledningar Figur C.6.c och C.6.d visar att Kraftledningar blir korrekt symboliserade efter konverteringen förutom att de vertikala strecken inte är vinklade likt originallagret (figur C.6.a). Som tabell D.6 visar blir Hash Line Symbol i QGIS symboliserat som en bred Simple Line med ett mönster för hur ofta de vertikala strecken ska förekomma. Samma gäller när lagret visualiseras som WMS i figur C.6.b. Vägar Figur C.7.c och C.7.d visar att rätt färger och mönster konverteras för Vägar. Tabell D.7 visar uppbyggnad av objekt L7 i tabell B.2. Samtliga objekt har fått samma storlek som i originallagret som visas i figur C.7.a. När lagret presenteras som WMS, se figur C.7.b, blir linjeobjekten rätt figursatta men dock tunnare än originallagret. Högexplaterad kust Konvertering av Högexploaterad kust (figur C.8.a) visas i figur C.8.c och C.8.d. Konverteringen resulterar i två helt olika lager då QGIS inte läser av SEfilen korrekt medan udig visar en korrekt stilsättning. Som visas i figur C.8.c kan QGIS varken generera markörlinjen eller den linjefyllda polygonen. När lagret presenteras som WMS blir resultatet enligt figur C.8.b. Det tomma lagret beror på LYR-filens sätt att presentera cirklar. Cirklarna presenteras som ESRI Default Marker som är en fontstil som GeoServer inte kan komma åt och därmed inte visualiserar. I SE-filen är det möjligt att ange att objekten ska vara av typen circle och då får datan rätt symbol.

75 7.7 resultat för konvertering av lyr-fil 59 Naturvård Det som skiljer Naturvård (figur C.9.a) från Högexploaterad kust, är att det inte består av en markörlinje. Resultatet av konvertering för detta lager visas i figur C.9.c och C.9.d och tydliggör skillnader i hur QGIS och udig hanterar SE-filen. När lagret istället visas som WMS (figur C.9.b) får det en korrekt stilsättning. Bebyggd mark I figur C.10.a visas hur Bebyggd mark visualiseras i ArcMap. Samtliga objekt består av enkla polygoner utom Fritidsbebyggelse, objekt Y1 i tabell B.4. Detta lager består av två linjefyllda polygoner vinklade 90 grader mot varandra (se tabell D.10) så att ett rutnät bildas. Resultat för konvertering visas i figur C.10.c och C.10.d. QGIS har svårigheter att visualisera den genererade SE-filen (se tabell D.10) medan udig presenterar ett resultat som är likt originallagret. När lagret presenteras som WMS efterliknar konverteringen originallagret, se figur C.10.b. Jordart, grundlager I konverteringen för Jordart, grundlager har alla objekt utom Moränlera eller lerig morän (objekt Y6 i tabell B.5) konverterats, se figur C.11.c och C.11.d. Objektet Moränlera eller lerig morän består i ArcMap av två lager uppdelat i en bakgrundsfärg i form utav Simple Fill samt ett bildobjekt Picture fill symbol (se tabell D.11). I den resulterade SE-filen blir bakgrundsfärgen korrekt överförd medan Picture Fill Symbol blir till en Simple Fill färgsatt i vitt. SE-filen har helt enkelt resulterat i två lager med Simple Fill där den vita polygonfyllningen överlagrar den andra och är därmed det enda som syns på kartan. Liknande problem stöts på när lagret presenteras som WMS. I den SE-fil som genererats på GeoServer har även där Picture Fill Symbol övergått till Simple Fill. Moränlera eller lerig morän består nu av två Simple Fill som överlagrar varandra. Sammanfattning av resultatet för GeoCat Bridge För att återkoppla till kravspecifikationen i avsnitt listas här vilka krav som är uppfyllda: 1. Punkters storlek ska bibehållas efter konverteringen. Uppfyllt 2. Streckade linjer ska bibehållas efter konverteringen. Uppfyllt 3. Linjer som består av två eller flera symboler ska vara likvärdiga efter konverteringen. Uppfyllt 4. Hexadecimala färgkoder ska vara samma efter konverteringen. Uppfyllt 5. Yttäckande mönster ska efter konvertering ha likvärdiga mönster. Delvis uppfyllt 6. Symboler ska efter konvertering vara likvärdiga. Uppfyllt 7. Illustrativa symboler ska efter konvertering fortfarande vara illustrativa. Uppfyllt Resultat WMS:

76 60 fallstudie 1. Punkters storlek ska bibehållas efter konverteringen. Uppfyllt 2. Streckade linjer ska bibehållas efter konverteringen. Uppfyllt 3. Linjer som består av två eller flera symboler ska vara likvärdiga efter konverteringen. Uppfyllt 4. Hexadecimala färgkoder ska vara samma efter konverteringen. Uppfyllt 5. Yttäckande mönster ska efter konvertering ha likvärdiga mönster. Delvis uppfyllt 6. Symboler ska efter konvertering vara likvärdiga. Uppfyllt 7. Illustrativa symboler ska efter konvertering fortfarande vara illustrativa. Inte uppfyllt Då lösningen nästan uppfyller alla de absoluta kraven blir den manuella redigeringen inte så tidskrävande. Därmed uppfyller GeoCat Bridge det önskvärda kravet att konverteringen ska utföras på en rimlig tid eftersom exekveringstiden inte heller var för lång. En jämförelse med Arc2Erth kan göras i G Arc2Earth Appendix C visar objekten före konvertering i ArcMap och efter konverteringen då stilsättningen visualiseras i QGIS eller udig. Figurerna som resultatet refererar till är namngivna efter vilken underrubrik de redovisas i. När Arc2Earth används öppnas en dialogruta och användaren kan välja ut de lager som ska exporteras. Lösningen uppfyller det önskvärda kravet att hela kartan kan stilsättas samtidigt. Resultatet av konverteringen är en SE-fil för varje valt lager som sparas i den sökväg som har angetts i dialogfönstret. Tillsammans med SE-filerna exporteras även PNG-filer för att komplettera de stilar som är svåra att visualisera i SE. Alla lager måste importeras i ett projekt och sedan måste en stil läsas in i form utav de SE-filer som följde med vid konverteringen av datan. För att kunna visualisera all data i QGIS korrekt måste manuellt arbete utföras. Punkter med enkel stilsättning Punkter med enkel stilsättning visas i figur C.1.a och får efter konvertering korrekt färg men fel storlek (se figur C.1.e och C.1.f). Tabell D.1 bekräftar även att konverteringen med Arc2Earth genererar fel storlek. I SE-filen som genereras av Arc2Earth har elementet size värdet 4, precis som i ArcMap. Symbol för järnväg Symbol för järnväg består av två olika lager, dels en cirkel och dels bokstaven J i teckensnitt Arial (se figur C.2.a). Resultatet av konverteringen visas i figur C.2.e och C.2.f. QGIS kan inte kan läsa av SE-filen och genererar därför ingen stilsättning medan udig får en korrekt stilsättning. Som tabell D.2 visar ger visualisering i QGIS och udig olika resultat. I QGIS renderas inga symboler alls medan udig visas symbolerna som External Graphic genom att definiera sökvägen till korrekt PNG-fil som Arc2Earth har skapat vid konverteringen.

77 7.7 resultat för konvertering av lyr-fil 61 Bebyggelsesymboler Som figur C.3.e och C.3.f visar resulterar konverteringen med Arc2Earth inte i något resultat för Bebyggelsesymboler. Begränsningslinjer för markslag Resultatet för konverteringen visas i figur C.4.e samt C.4.f. Enligt tabell D.4 attributvärdet för size korrekt konverterat men presentationen i QGIS och udig är svagare efteråt. Administrativa gränser I figur C.5.e och C.5.f visas resultatet efter konverteringen i QGIS respektive udig. Jämför med originallagret (figur C.5.a) fungerar bra och tabell D.5 visar även att breddens för linjerna samt mönster för Administrativa gränser konverteras till rätt värden. Kraftledningar Figur C.6.e och C.6.f visar att Kraftledningar blir korrekt symboliserade efter konverteringen förutom att de vertikala strecken inte är vinklade likt originallagret (figur C.6.a). Som tabell D.6 visar blir Hash Line Symbol i QGIS symboliserat som en bred Simple Line med ett mönster för hur ofta de vertikala strecken ska förekomma. Vägar I figur C.7.a visas hur Vägar visualiseras i ArcMap. Figur C.7.e och C.7.f visar att rätt färger och mönster konverteras för Vägar. Tabell D.7 visar uppbyggnad av objekt L7 i tabell B.2. Attributen för detta objekt som består av två lager har blivit korrekt konverterade. Högexploaterad kust Konvertering av Högexploaterad kust (figur C.8.a) visas i figur C.8.e och C.8.f. Lagrets uppbyggnad kan utläsas i tabell D.8 och visar att Arc2Earth varken lyckats extrahera markörlinjen eller den linjefyllda polygonen. Naturvård Konverteringen av Naturvård (figur C.9.a) visas i figur C.9.e och C.9.f och blir inte korrekt symboliserad. I QGIS presenteras Naturvård som en enkel polygon med enkel fyllning och enkel kantlinje (se tabell D.9). Bebyggd mark I figur C.10.a visas hur Bebyggd mark visualiseras i ArcMap. I detta lager består samtliga objekt av enkla polygoner utom Fritidsbebyggelse, objekt Y1 i tabell B.4. Detta lager består av två linjefyllda polygoner vinklade 90 grader mot varandra (se tabell D.10) så att ett rutnät bildas. Resultat för konvertering med Arc2Earth visas i figur C.10.e och C.10.f. QGIS har svårigheter att visualisera den genererade SE-filen (se tabell D.10) medan udig presenterar ett resultat där bredden mellan linjer är är större än för originalobjeket. Jordart, grundlager I konverteringen för Jordart, grundlager, se figur C.11.a, har alla objekt utom Moränlera eller lerig morän (objekt Y6 i tabell B.5) blivit korrekt symboliserade, se figur C.11.e och C.11.f. Objektet Moränlera eller lerig morän består i ArcMap av ett bildobjekt (Picture fill symbol). SE-filen har Picture Fill Symbol blivit till två Simple Fill färgsatt i vitt. SE-filen har helt enkelt resulterat i två lager med Simple Fill.

78 62 fallstudie Sammanfattning För att återkoppla till kravspecifikationen i avsnitt listas här vilka krav som är uppfyllda: 1. Punkters storlek ska bibehållas efter konverteringen. Delvis uppfyllt 2. Streckade linjer ska bibehållas efter konverteringen. Uppfyllt 3. Linjer som består av två eller flera symboler ska vara likvärdiga efter konverteringen. Uppfyllt 4. Hexadecimala färgkoder ska vara samma efter konverteringen. Uppfyllt 5. Yttäckande mönster ska efter konvertering ha likvärdiga mönster. Inte uppfyllt 6. Symboler ska efter konvertering vara likvärdiga. Inte uppfyllt 7. Illustrativa symboler ska efter konvertering fortfarande vara illustrativa. Uppfyllt Konvertering med Arc2Earth ger ett mycket varierat resultat. Exempelvis får Punkter med enkel stilsättning fel storlek medan Symbol för järnväg och Bebyggelsesymboler får korrekt stilsättning. Vidare blev alla linjeobjekt korrekt symboliserade utom symbol L4 (tabell B.2). Konverteringen av polygoner resulterade i få lager. Då lösningen inte uppfyller alla absoluta krav blir den manuella redigeringen omfattande. Det önskvärda kravet på att lösningen konverterar stilsättningen på en rimlig tid uppfylls därmed inte, även om exekveringstiden var rimlig. En jämförelse med GeoCat kan göras i G ArcGIS-map to SLD Converter Programvaran är enkel att installera men går inte att starta. Den senaste versionen av programvaran är från den 24:e augusti Medlemmar i diverse forum är av åsikten att programvaran endast fungerar för ArcMap 10.0 och inte senare versioner såsom , vilken är den version som används i fallstudien. Programvaran kommer därmed inte utvärderas vidare då någon lösning på problemet inte har hittats MXD2QGS MXD2QGS är enkelt att installera och resultatet är ett verktyg som adderas i verktygsfältet ArcToolBox i ArcMap. För att konvertera en MXD-fil till en QGS-fil körs verktyget och en sökväg samt ett namn bestäms för den nya filen. De lager som är markerade i ArcMap är de som konverteras till en QGS-fil vilket medför att lösningen uppfyller kravet på att en hel karta ska kunna stilsättas samtidigt. Programvaran uppfyller även det önskvärda kravet att konverteringen ska vara enkel att utföra. I det medföljande dokumentet vid installationen, Readme.txt, fastslås att på grund av begränsningarna i ArcGIS kommer lagersymboliseringar inte kunna konverteras. När verktyget används körs ett Python-skript som först inte fungerar för vår data. För att köra skriptet får ingen sökväg till datan innehålla åäö. När skriptet väl fungerar konverteras samtliga data som innehåller åäö till andra symboler vilket är ett problem för svenska myndigheters och kommuners data. Efter konverteringen stämmer namnen på datan inte längre

79 7.8 resultat för användning av befintliga stilsättningar 63 överens med de ursprungliga namnen på datan. Konverteringen medför att alla regelbaserade stilsättningar måste editeras eftersom de inte längre stämmer överens med attributdatan. Det här problemet borde kunna lösas med att ange korrekta teckenkoder i skriptet. På så sätt hade den regelbaserade stilsättningen fungerat och lösningen hade inte krävt lika mycket manuell redigering. Att lösa problemet med teckenkoderna var dock inte rimligt inom den fastställda tidsramen för denna studie. Ett annat problem är att moduler som används i Python-skriptet inte längre är kompatibla med senare versioner. För att MXD2QGS skulle fungera krävdes förändringar av skriptet vilket var tidskrävande. Konverteringen resulterar i en QGS-fil som innehåller Shape-filerna samt stilsättning i QML-filer. Figur E.1.a redovisar resultatet av lösningen. MXD2- QGS klarar inte av att konvertera någon stilsättning utan alla typer av objekt får samma egenskaper. Därmed måste en tidskrävande manuell redigering utföras vilket medför att det önskvärda kravet på att lösningen konverterar stilsättningen på en rimlig tid, inte uppfylls. Det MXD2QGS egentligen har gjort är att den har skapat en QGS-fil som innehåller de Shape-filer som fanns i MXD-filen. Den lagerstruktur som är uppbyggd i ArcMap konverteras inte heller så lösningen underlättar inte arbetet med stilsättning alls. Sammanfattning I den här lösningen måste alla lager stilsättas eftersom inga objekt har blivit stilsatta. Det här är ett tidskrävande arbete som för större datamängder som innehåller någon form av avancerad stilsättning inte är motiverat. Det finns säkerligen utvecklingspotential i skriptet MXD2QGS men det är inget som hinner utredas i fallstudien. Eftersom lösningen inte har konverterat någon stilsättning alls uppfylls inga av de absoluta kraven i kravspecfikationen i avsnitt Det önskvärda kravet att hela kartan ska stilsättas samtidigt uppfylls därmed inte heller. Att lösningen ska exekveras på en rimlig tid kan inte heller anses vara uppfyllt då ingen stilsättning konverterades. 7.8 Resultat för Användning av befintliga stilsättningar Resultatet av lösningen Användning av befintliga stilsättningar redovisas i appendix F.1. Figurerna som resultatet refererar till är namngivna efter vilken underrubrik de redovisas i. I varje underrubrik visas Lantmäteriets data i ArcMap och datan efter användning av den befintliga stilsättningen, presenterat i QGIS. QGIS Sveriges stilsättning av Terrängkartan visualiseras i F.1.b. Hur Terrängkartan visualiseras i ArcMap med stilsättning skapad av Lantmäteriet visas i figur F.1.a. Stilsättningen är inte komplett då alla objekt inte är stilsatta. Vid granskning av de stilsatta objekten står det även klart att de färger som används i Lantmäteriets stilsättning av Terrängkartan inte används i QGIS Sveriges stilsättning av Terrängkartan. Anledningen till det här anges inte. Det som är oklart är om det här är något som planeras att redigeras eller om organisationen har valt att publicera stilsättningar som inte efterliknar Lantmäteriets kartor. QGIS Sverige anger att en WMTS för Terrängkartan som är tillgänglig på Lantmäteriets hemsida har använts som grund för stilsättningen QGIS Sveriges stilsättning av Översiktskartan visas i figur F.1.d och stilsättning av Översiktskartan visualiserad i ArcMap visas i figur F.1.c. All data i Översiktskartan är inte stilsatt i formatet QML. Även här blir arbetet med den befintliga stilsättningen skapad av QGIS Sverige relativt tidskrävande då alla lager måste granskas för att se vilken data som är stilsatt. Enligt filen README.md på GitHub passar stilsättningen av Översiktskartan bäst för

80 64 fallstudie skalor större än 1: De objekt som QGIS Sverige har stilsatt har inte samma stilsättning som Lantmäteriet och anledningen till det här är okänd. Resource Sharing var enkelt att installera och det finns sedan tillgängligt genom QGIS gränssnitt. När Resource Sharing är installerat är det möjligt att söka bland de stilsättningar som är tillgängliga och använda för datan i QGIS. För lösningen krävs det att stilsättningen som ska delas, laddas upp som QML-filer på GitHub. Därefter ska korrekt struktur på datan erhållas och en korrekt fil innehållandes metadata. Det här går relativt snabbt att skapa och behövs bara göras en gång. Arbetsflödet för verktyget Resource Sharing är enkelt för en användare som har någon form av vana av att arbeta i QGIS vilket medför att ett önskvärt krav är uppfyllt för lösningen. En fördel med verktyget är att det är enkelt att dela stilsättningar med andra användare. För att stilsättningen ska hålla tillräckligt bra kvalitet är det viktigt att det finns någon form av kontroll över vilken data som delas med andra användare Sammanfattning Sammanfattningsvis har de befintliga stilsättningarna som valts ut för fallstudien inte uppfyllt kravet att en hel kartprodukt ska vara stilsatt eller att det tydligt framgår vilken data som är stilsatt. Det framgår inte om det finns någon kvalitetskontroll av stilsättningarna. Tillgång till stilsättningen erhålls via GitHub och för en användare med någon form av GIS-kunskap är det enkelt att få tillgång till filerna. Sammanfattningsvis uppfylls inte alla önskvärda kraven för lösningen. Har stilarna skapats en gång är Resource Sharing ett bra sätt att lagra stilsättningen och det är enkelt att uppdatera datan. GitHub och Resource Sharing är även lämpligt för att lagra och hantera stilsättningar för olika organisationer. GitHub ger en bra struktur för datan och kan vara en bättre lagringsform än en lokal filstruktur. 7.9 Resultat för QGS-fil I avsnitt 7.2 beskrivs hur stilsättning av geografiska data hanteras av Tyréns. De lager som ska stilsättas öppnas i en QGS-fil där datan sedan sedan stilsätts manuellt. Beroende på antalet ingående objekt i lagret samt hur komplexa stilarna, tar det olika lång tid att skapa en stilsättning för dessa lager. Men generellt sett är den manuella hanteringen tidskrävande om inga färdiga stilar finns att tillgå på internet. En betydande fördel med att manuellt skapa stilsättningen är dock att det är enkelt i QGIS att skapa avancerade stilsättningar och även regelbaserad stilsättning och ett absolut krav uppfylls därmed. När en karta är stilsatt kan den enkelt och effektivt delas med andra användare med hjälp av QGS-filen. För att säkerställa att QGS-filen ska innehålla aktuell data krävs någon form av uppdateringsrutin. Stilsättningen i QGIS blir likt den stilsättning som Lantmäteriet har tagit fram för ArcMap och det andra absoluta kravet uppfylls därmed också.

81 8 Diskussion Fallstudien har illustrerat de problem som finns för hantering av stilsättning av geografiska data. I avsnitt 8.1 diskuteras först de olika lösningarna som har testats i fallstudien och därefter diskuteras dagens hantering av stilsättning i avsnitt 8.2. Hur utvecklingen ser ut diskuteras i avsnitt 8.3 där bland annat lösningsförslag tas fram för hur stilsättning bäst hanteras i organisationer. 8.1 Utvärdering av lösningar Lösningarna utvärderas i detta avsnitt efter den generella kravspecifikationen i avsnitt och därefter diskuteras hur de olika lösningarna bäst integreras i organisationer samt hur deras framtidsutsikter ser ut GeoCat Bridge Sammanfattningsvis är GeoCat Bridge en bra lösning även om den kräver en del resurser. Resultatet av konverteringen är bra och det är bara ett objekt (Y6 tabell B.5) som konverteras fel. Detta är heller inte så konstigt eftersom bilden som polygonen har som bakgrund endast finns definierad i ArcMap. För att få en fungerande lösning krävs lite manuell redigering. GeoCat Bridge har ett väl designat gränssnitt och arbetsflödet upplevs som enkelt för en person som har någon form av vana av att arbeta i ArcMap och någon programvara som utför editering av SE-filer. Det är möjligt att endast en person använder lösningen och därefter delar stilsättningarna med andra och att lösningen körs centralt i organisationen så att den färdiga stilsättningen delas med resten av organisationen. För att stilsättningen ska hålla hög kvalitet krävs en uppdateringsrutin. Den ansvarige måste vid uppdateringar av stilsättningen antingen ändra stilsättningen manuellt eller åter köra lösningen och utföra det manuella arbetet som lösningen kräver. Resultatet levereras i form utav SE-filer och om SE är ett format med goda framtidsutsikter diskuteras i avsnitt 8.2. GeoCat Bridge är beroende av att även ArcMap används då lösningen bygger på att få köras som insticksprogram i programvaran. Är syftet att organisationen ska kunna använda fler programvaror än ArcMap för att få en större flexibilitet är det här ingen nackdel. Är syftet dock att hitta en lösning som gör att programvaror baserade på öppen källkod används istället så uppfyller inte den här lösningen det syftet. Organisationen som planerar att använda GeoCat Bridge måste ta ställning till om nyttan överväger licenskostnaden. Flexibiliteten minskar även när en karta presenteras som WMS. Det är nämligen komplicerat att förändra lagrets presentation. För att exempelvis i QGIS ändra färg på ett lager måste det utföras i GeoServer istället för direkt i QGIS. Det är inte heller möjligt att tända och släcka objekttyper. Vill man exempelvis att objekttypen motorväg ska släckas finns det inte möjlighet att göra det här utan en ny stil måste skapas i GeoServer. En sista nackdel med WMS är att det inte är möjligt att göra spatiala analyser på datan. Att använda WMS är en bra lösning om data bara ska visualiseras men det fungerar inte för uppgifter där geografiska data ska analyseras, redigeras eller adderas.

82 66 diskussion Arc2Earth Sammanfattningsvis kräver Arc2Earth för mycket resurser i förhållande till den nytta som lösningen ger. Lösningen resulterar inte i en stilsättning som är likvärdig med stilsättningen före konverteringen och den kräver för mycket manuell redigering för att ensamt vara en hållbar lösning. Att använda programvaran Arc2Earth är smidigt och det är enkelt att förstå arbetsflödet. Arc2Earth är enkelt att använda då det endast krävs en knapptryckning för att exportera lager till SE vilket var ett önskvärt krav för lösningen, se avsnitt Stilsättningarna konverteras till SE-filer och det är möjligt att endast en person i organisationen använder programmen och därefter delar stilsättningen som exempelvis en färdig QGIS-fil. Det är möjligt att köra den här lösningen centralt i en organisation vilket är effektivt och skapar störst nytta. För att den konverterade stilsättningen ska hålla en tillräckligt hög kvalitet och vara jämförbar med före konverteringen krävs manuell redigering. Ansvarig för konverteringen måste även se till att stilsättningen uppdateras när det krävs. Leverans från Arc2Earth är möjlig i ett flertal olika format men för att uppnå syftet med fallstudien ska resultatet levereras i form utav SE-filer. Om SE är ett format med goda framtidsutsikter diskuteras i avsnitt 8.2. För att använda den här lösningen krävs minst en licens till programvaran. En avvägning behöver göras om stilsättningen blir så pass bra att det är värt att betala en licens istället för att skapa stilsättningen helt själv. Precis som GeoCat Bridge är Arc2Earth beroende av att ArcMap används och är även här syftet att hitta en lösning som gör att programvaror baserade på öppen källkod används istället så uppfyller inte den här lösningen det syftet heller MXD2QGS Konverteringen med MXD2QGS resulterade i att samtliga lager fick fel stilsättning. Lösningen kan inte konvertera att datan är sparad i olika lagergrupper och den regelbaserade stilsättningen konverteras inte heller. Det är därmed inte värt att använda lösningen som grund för att bygga vidare på en manuell stilsättning. Lösningen kan sammanfattas med att den kopierar de Shape-filerna som används i MXD-filen till en QGS-fil och resultatet är följaktligen inte tillräckligt bra för att kunna användas som stilsättning. Då MXD2QGS inte fungerar när sökvägarna till datan innehåller åäö upplevs arbetsflödet som komplicerat. Det är inte en hållbar lösning att hela tiden behöva ändra sökvägarna till datan och framför allt inte att alla medarbetare i en organisation ska behöva göra det. I dagsläget kräver lösningen orimligt mycket resurser i förhållande till nyttan den ger. MXD2QGS är ett skript som är möjligt att utveckla men då krävs mycket kunskaper dels om Python men också om hur MXD- och QGS-filer är uppbyggda. Som skriptet är utvecklat just nu är det inte en hållbar lösning då det inte verkar som om det uppdateras i takt med att nya versioner av de berörda programvarorna och standarderna släpps. Sammanfattningsvis uppfyller inte lösningen tillräckligt många av de generella, önskvärda kraven Användning av befintliga stilsättningar För lösningen Användning av befintliga stilsättningar beror resultatet på vilken data som är stilsatt och dess kvalité. I fallstudien var inte alla lager för en karta stilsatta vilket är en nackdel för den här typen av lösning. Syftet med att använda befintliga stilsättningar är att de ska vara färdiga att använda

83 8.1 utvärdering av lösningar 67 och vara av god kvalitet. Uppfylls inte de här två grundläggande kraven kan det i många fall vara en bättre lösning att manuellt skapa stilsättningen om ett arbete ska utföras som motiverar de resurser som krävs. De befintliga stilsättningarna som har testats i fallstudien håller inte tillräckligt hög kvalitet för att de ska anses vara jämförbara med stilsättningen före konverteringen. Användning av befintliga stilsättningar är en lösning som lämpar sig bäst för användare som har vana av att arbeta med stilsättning av geografiska data. Att förstå hur befintliga stilar kan laddas ner som SE- eller QML-filer är inte så enkelt för medarbetare som endast sporadiskt använder geografiska informationssystem i sitt arbete. För att medarbetare ska kunna arbeta efter den här modellen krävs det att det finns ett tydligt arbetsflöde att följa. Ett bättre sätt att arbeta efter den här metoden är att en medarbetare som arbetar med GIS inom en organisation laddar ner och när det behövs, uppdaterar befintliga stilsättningar och skapar en projektfil som är tillgängliga för medarbetarna. Det stora problemet med att använda befintliga stilsättningar är att kvalitén inte går att säkerställa fullt ut. Det finns nämligen ingen kvalitetssäkring då dessa stilar läggs upp på frivillig basis. Lösningen med befintliga stilsättningar bygger på att en annan part uppdaterar datan korrekt samt kontrollerar att datan håller tillräckligt hög kvalitet. Alternativet är att kontrollera om stilsättningen är aktuell vilket är tidskrävande. Initiativ måste tas av organisationer för att systematisera uppdatering och kvalitetssäkring av stilsättning. En sådan organisation är exempelvis QGIS Sverige. Dock finns det begränsat med resurser att lägga på att uppdatera stilsättningar. Med hjälpmedlet Resource Sharing blir hanteringen av befintliga stilar enklare. Det är enkelt att använda för användare som har vana av att använda QGIS eller liknande programvaror. Hjälpmedlet möjliggör ett enkelt tillvägagångssätt för att dela befintliga stilsättningar. Resource Sharing kräver att minst en person i organisationen har vana av att arbeta i GitHub så att stilsättningarna kan delas korrekt. Lösningen kan köras centralt i en organisationen och därefter kan slutanvändare ta del av stilsättningen. För de användare som sedan ska hämta stilsättningar från Resource Sharing är det ett enkelt arbetsflöde att följa. Genom att använda Resource Sharing blir en lösning med Användning av befintliga stilar mer hållbar då det möjliggör att fler användare enklare har tillgång till färdiga stilsättningar. En förbättring som kan göras är att de användare som delar med sig av befintliga stilar, beskriver på GitHub i filen README.md vilka lager som är stilsatta samt om de har kvalitetskontrollerats. Även metadata såsom när stilsättningen skapades och när den har uppdaterats är information som skulle vara värdefull för användare. Lösningen i sig uppfyller de önskvärda krav som anges i avsnitt om Resource Sharing används och om stilsättningen som distribueras är likvärdig med myndigheternas data i ArcMap före konverteringen QGS-fil Fördelarna med att skapa egna projektfiler i QGIS är att det ger kontroll över datan och vilken kvalitet den har. Nackdelarna är att det krävs omfattande resurser för att skapa projektfilen samt att se till att den är uppdaterad. Ingen av de andra lösningarna kommer i närheten av samma kvalitet som uppnås av att skapa en QGS-fil. Är det främsta och viktigaste syftet att hitta en lösning som efterliknar kartprodukters visualisering så bra som möjligt är det här den bästa lösningen. Det arbetet som är tidskrävande med att skapa en QGS-fil är dels att stilsätta objekten med rätt grafiska former såsom polygonfyllningar, streckade linjer, ytmönster och så vidare. Den andra de-

84 68 diskussion len som är tidskrävande är att dela upp objekten i regelbaserad stil som beror på objektens attribut. Det finns bra verktyg i QGIS för att skapa regelbaserade stilsättningar vilket gör arbetsflödet enkelt och ett önskvärt krav uppfylls därmed, se avsnitt Symboliseringen av objekt är enkel att skapa och resultatet blir likt stilsättningen i ArcMap. Om en organisation väljer att arbeta på det här sättet kan det vara bra att arbeta fram uppdateringsrutiner. Det måste finnas en rutin där stilsättningen i ArcMap ses över för att säkerställa att uppdateringar av stilsättningen även sker i QGIS. Lösningen är hållbar då den inte förlitar sig på en annan part än de som ska använda lösningen. För att använda lösningen krävs det att minst en individ har kunskaper om hur stilsättningsverktygen i QGIS fungerar. QGIS har ett gränssnitt som är enkelt att förstå så det borde inte vara ett hinder för användningen av egna projektfiler. Fördelar med lösningen är även att den enkelt kan delas inom en organisation och att det är enkelt att för andra användare att nyttja den. Det mest effektiva sättet är att skapa QGS-filen så centralt som möjligt. Tidsåtgången för att skapa stilsättningen manuellt i en QGS-fil ska vägas mot licenskostnaden för att använda en programvara som konverterar LYRfiler till SE-filer. Att Tyréns har börjat med att leverera projektfiler för både ArcMap och QGIS genom kartportalen är ett stort steg i rätt riktning. Genom att leverera flera projektfiler sparas mycket tid för medarbetare och de ges möjligheter att enklare arbeta i olika programvaror. Sammanfattningsvis uppfyller lösningen alla de önskvärda kraven som ingår i den generella kravspecifikationen Sammanfattning av fallstudien Efter att samtliga lösningar har testats tydliggörs det vilka brister det finns för kompatibilitet för stilsättning av geografiska data. Efter kartläggningen av lösningarna som konverterar LYR-filer till SE-filer står det klart att GeoCat Bridge är ett fullgott verktyg för detta ändamål men bristerna ligger i hur QGIS läser av SE-filer, se avsnitt 7.6. Resultatet av Arc2Earth är sämre än resultatet av GeoCat Bridge och ska en lösning användas som konverterar LYR-filer rekommenderas att GeoCat Bridge används. Båda de här programmen distribueras under licenser som inkluderar en avgift. Den här avgiften bör ställas i relation till den tid det tar, och därmed kostnad, för att manuellt konvertera stilsättning från ArcMap till SE- eller QML-filer. Fallstudien fastslår att det är svårt att konstruera lösningar som klarar av att både stilsätta objekt korrekt samt konstruera den regelbaserade stilen men det finns möjligheter att integrera de olika lösningarna med varandra. Om en lösning klarar av att konstruera den regelbaserade stilsättningen är det en bra grund till att fortsätta stilsättningen av objekten. Lösningarna som konverterar LYR-filer till SE-filer kan utgöra grunden för att skapa egna projektfiler. Även om konvertering inte alltid blir helt rätt kan stora tidvinster göras bara genom att den regelbaserade stilsättningen blir korrekt. De här lösningarna kan även kombineras med att de färdiga stilsättningarna, efter viss manuell redigering, delas genom Resource Sharing. Följande arbetsflöde har tagits fram som förslag på hur en organisation mest effektivt kan skapa stilsättningar för presentation av data i andra programvaror än ArcMap. Arbetsflöde för konvertering av stilsättning: 1. Sök efter befintliga stilsättningar på internet eller på Resource Sharing. Om stilsättning är bristfällig, korrigera manuellt. 2. Om befintlig stilsättning inte finns tillgänglig; jämför licenskostnad för GeoCat Bridge med kostnad för att stilsätta datan manuellt.

85 8.2 nuvarande hantering av stilsättning av geografiska data Nuvarande hantering av stilsättning av geografiska data De myndigheter som har ett informationsansvar beskrivs i avsnitt 2.4 och i dagsläget tillhandahåller de flesta myndigheter geografiska data genom någon tjänst på respektive hemsida. I avsnitt redogörs hur geografiska data från Trafikverket hämtas. Lantmäteriet som också har ett informationsansvar har ett annat tillvägagångssätt för att uppfylla sitt informationsansvar, som också beskrivs i avsnitt Processen för att hämta data från de olika myndigheter med informationsansvar skiljer sig åt och om data behöver hämtas från många olika myndigheter blir det en tidskrävande uppgift. Det var inte heller helt enkelt att hitta rätt på Trafikverkets och Lantmäteriets hemsidor. För att den nationella geodatastrategin ska vara uppfylld ska de fyra målen, se avsnitt 2.5.2, uppfyllas. Målet att geografiska data ska vara användbara innehåller bland annat krav på att geografiska data ska vara tillgänglig i de former som efterfrågas, att det finns valmöjligheter mellan nationella och internationella standarder och att de är enkla att använda. Idag levererar de flesta myndigheter och kommuner geografiska data i formatet Shape och i vissa fall även MapInfo TAB. Shape är ingen standard enligt OGC men den har en så pass stor spridning att den används som en informell standard. Det finns en problematik med att de flesta myndigheter i dagsläget endast levererar stilsättning i LYR-filer då det medför att Esris programvaror måste användas om inte ett relativt stort manuellt arbete ska behöva göras. Det här går inte ihop med den nationella geodatastrategin som menar på att geografiska data bland annat ska vara enkla att använda. En relevant fråga att ställa är om inte andra format såsom QML borde anses vara former som efterfrågas då programvaror baserade på öppen källkod inom GIS blir allt mer populära och vanliga att använda. Att kombinera en öppen standard som SE med avancerad stilsättning verkar medföra en del problem. SE är en standard som är enkel att förstå, granska och editera. Det här är viktiga egenskaper för att en standard ska vara användbar och ha en bred spridning inom olika områden och kunna användas av många personer. Det finns flera olika förlängningar av SE som olika utvecklare har tagit fram för att kunna använda mer avancerade stilsättningar. Det finns en viss motsägelse mellan att en standard är enkel att förstå samt att den kan hantera avancerade stilsättningar. Desto mer avancerad en standard blir desto svårare blir den att förstå. En relevant fråga att ställa är hur standardiserad en standard kan vara som även ska kunna hantera avancerade stilsättningar. Med flera utvidgningar av SE försvinner en stor del av kompatibiliteten då olika programvaror har egna utvidgningar som inte är läsbara av andra programvaror. Fallstudien visar på att det finns stora skillnader bland programvaror med avseende på vilka SE-filer de kan läsa. Ett format som är standardiserat av OGC bör visualiseras liknande oavsett vilken programvara den öppnas i. I fallstudien används några av de vanligaste programvarorna för visualisering av SE-filer nämligen QGIS, GeoServer och udig. Som fallstudien visar visualiserar dessa programvaror en SE-fil olika i många fall. Detta tyder på en stor brist i formatet. Det här medför problem då programvarorna inte är kompatibla för stilsättning. Det är för vissa programvaror, exempelvis udig, otydligt vilken version av SE som går att importera och exportera. Desto mer avancerad specifikationen av SE blir desto svårare blir den även att granska och redigera för användarna. Det här bör finnas med i åtanke när myndigheter och organisationer väljer format för stilsättning av geografiska data.

86 70 diskussion I intervjun berättar Sara Stefansson att Lantmäteriet i dagsläget inte har några planer på att leverera stilsättning i något annat format än LYR även om de undersöker vad det finns för alternativ (se avsnitt 6.1). Sara Stefansson berättar även att Lantmäteriet givetvis behöver hålla en hög kvalitet på den data de släpper men hon berättar även att resonemang förs om att stilsättning i SE inte behöver vara exakt likadan som nuvarande stilsättning i LYR-format. Därmed skulle kartor med stilsättning skapad efter ArcMaps bibliotek av stilar, även kunna stilsättas med SE. 8.3 Framtida utveckling Det finns många områden inom stilsättning av geografiska data som behöver utvecklas och förhoppningsvis kommer att göra det inom de närmsta åren. Det finns standarder för format inom stilsättning men det finns inget formellt format som har fått ett stort genomslag och används som om det skulle vara allmänt vedertaget. Även hur geografiska data och tillhörande stilsättning levereras har stora utvecklingsmöjligheter SLD-prototyp SLD-prototypen som beskrivs i avsnitt 6.2 och figur 6.6 är en möjlig framtida lösning för hantering av stilsättning av geografiska data. Att standardisera hanteringen genom en prototyp där de symboliska namnen och värdena ändras efter användarens krav är en flexibel lösning som gör det enkelt att anpassa stilsättningen efter specifika krav Nationell kartportal Att samla geografiska data från de myndigheter som har ett informationsansvar under en portal hade troligtvis underlättat nedladdningen för många användare. Geodataportalen är en bra grund men där är det frivilligt för myndigheter att vara med. Geodataportalen är inte heller en nedladdningstjänst utan en portal som visar vilken data som finns tillgänglig för nedladdning samt var. För att tydliggöra vilka myndigheter som har ett informationsansvar är ett förslag att samla dem i en portal. Webbkarttjänsten GET är ett bra exempel på hur en portal för nedladdning av geografiska data kan se ut. Ett förslag är att skapa en sådan här nedladdningstjänst för de myndigheter som har ett informationsansvar och även integrera stilsättningar i kartportalen. På samma sätt som Lantmäteriet levererar datan i en mapp som heter arcgis, hade en mapp i leveransen kunnat ha namnet qgis och innehållit antingen QML-filer för respektive lager eller en QGS-fil som innehåller den samlade stilsättningen. Det här hade kunnat byggas upp på samma sätt som leveransen från Tyréns kartportal där både stilsättning för ArcGIS och QGIS ingår. QGIS är ett program som har en så pass stor spridning i Sverige att en stilsättning hade varit uppskattad och borde anses vara former som efterfrågas som det anges i den nationella geodatastrategin. Att nedladdningstjänster för myndigheters geografiska data innehåller stilsättning för mer än en programvara och specifikt för en programvara som baseras på öppen källkod ger även fler användare tillgång till geografiska data. Genom det här förslaget skapas stilsättningar så centralt som möjligt vilket är effektivt och leder till att dubbelarbete minskar. Givetvis krävs det mycket tid och resurser för att skapa en sådan här kartportal. Resurserna måste dock vägas mot den samhällsekonomiska nyttan som uppstår när aktuell och korrekt data används i myndighetsutövning, kommuners verksamheter, kommersiella verksamheter och även av privat-

87 8.3 framtida utveckling 71 personer. Laakoma presenterar i sin rapport, se avsnitt 2.5.3, de samhällsekonomiska nyttorna med öppna geografiska data[21]. Om den geografiska datan blir mer tillgänglig genom att den är kompatibel med fler programvarar kommer den användas mer vilket borde leda till mer samhällsekonomiska nytta Lärdomar från andra länder I avsnitt redovisas hur Storbritannien genom Ordnance Survey har skapat OS MasterMap Topography Layer. Stilsättningen kan levereras i formaten LYR, SE och QML. Det här medför en stor flexibilitet för slutanvändarna av datan och är något som Sverige bör dra lärdomar av. OS har därmed kommit underfund med problematiken att stilsättningarna blir exakt likadana i de olika formaten samt att de rimligtvis har funnit det ekonomiskt hållbara att erbjuda och uppdatera flera format. Det är intressant att se att andra länder kan leverera stilsättning i flera format än det proprietära LYRformatet. OS har även skapat en bra användarguide för hur stilsättningarna ska användas vilket underlättar för de slutanvändare som vill testa ett nytt format för stilsättning. Finland och Island tillämpar Oskaris plattform (se avsnitt 2.7) för att utveckla sina nationella kartportaler. Detta verktyg skulle kunna vara ett framtida sätt för att tillhandahålla en svensk kartportal som är kompatibel med OGC-standarder och INSPIRE-direktiv så som SE och GML. I avsnitt beskrivs vilka format som erbjuds i Norge. I Norge finns en policy som säger att data inte ska levereras i programspecifika format om inte det finns ett stort behov från användarna. Leverans ska ske i SOSI och GML. Sverige bör se över sina rutiner med att erbjuda Shape i sådan stor omfattning, då det hämmar fri konkurrens Framtida format för stilättning av geografiska data Stilsättningsformat påverkas av vilket format som används för distribution av geografiska data. Shape har länge varit populärt trots att det inte är en formell standard utan utformat för en specifik programvara. Samtidigt finns andra format som lagrar geografiska data, ett exempel är GeoPackage som har fått en viss spridning inom branschen för geografiska data. Shape-filen kommer troligtvis fortsätta vara ett populärt format framöver men kommer troligtvis utmanas av andra format. Båda formaten, Shape och GeoPackage, kan stilsättas med LYR, SE och QML. Fallstudien visar att stilsättningen, eller en snarlik stilsättning, i LYR-filer för Lantmäteriets Terrängkarta, Vägkarta, Översiktskarta och Sverigekarta kan beskrivas med SE och i de fall det inte går kan en snarlik stilsättning göras. Likvärdiga stilsättningar kan även skapas i QML-filer. En trolig utveckling är att allt mer geografiska data levereras i enlighet med Inspire och Svensk Geoprocess och därmed i GML-format. Detta skulle även påverka leveransen av stilsättning då ett naturligt steg blir att leverera i SE då detta också är en standard från OGC. LYR har en tydlig koppling till Shape och om detta format byts ut kommer även format för stilsättning att göra det. Det rekommenderas att myndigheter med informationsansvar undersöker hur OS i Storbritannien har lyckats stilsätta sin geografiska data i QML och SE. Med tanke på att Storbritannien levererar stilsättning i formaten SE och QML är det en indikation på att det här bör vara möjligt även i Sverige. Fallstudien har visat på att stilsättning av Lantmäteriets och Länsstyrelsens data i QML-filer håller tillräckligt hög kvalitet och är jämförbar med stilsättningen i LYR-filer.

88 72 diskussion För att uppnå målen i den nationella geodatastrategin måste myndigheter med ett informationsansvar i framtiden levererar stilsättning i fler format än LYR. För att geografiska data ska vara enkla att använda och användbara bör datan levereras i olika typer av format. Rimligtvis bör även det här resultera i liknande konsekvenser som i rapporten Samhällsekonomisk effekt av öppna geodata som tas upp i avsnitt Om myndigheters geografiska data blir mer tillgängliga bör det användas mer och därmed bidra till mer samhällsekonomiska nyttor och en större konkurrenskraft för svenska företag. Att Lantmäteriet i så pass stor grad levererar stilsättning i LYR kan tyckas hindra fri konkurrens. Samtliga företag som vill nyttja datan blir direkt beroende av att köpa licenser för ArcMap. Lantmäteriet erbjuder i dagsläget Höjdmodellen, Terrängkartan, Fjällkartan och Vägkartan i Minecraft-format. Dessa data är helt gratis att hämta. Det tål att diskuteras nyttan av att erbjuda data i Minecraft-format och inte i ett öppet stilsättningsformat. Under vår fallstudie har Terrängkartan, Sverigekartan och Översiktskartan från Lantmäteriet stilsatts manuellt i en QGS-fil. Det här tog inte mer tid och resurser än vad Tyréns tyckte var skäligt för att erhålla stilsättning i mer än ett format och om detta arbete lyfts till leverantören av geografiska data kommer än större nytta erhållas. Det skulle spara mycket resurser för verksamheter då de slipper lägga tid på att manuellt konvertera LYR-filer och det skulle innebära en trygghet att stilsättningen är korrekt och uppdaterad av leverantören.

89 9 Slutsatser Ett syfte var att kartlägga vilka format som finns för att hantera stilsättning av geografiska data. Det här syftade till att utreda vilka olika format som hanterar stilsättningen samt hur väl det görs. Slutsatsen är att det ofta är format som är specifika för programvaror som bäst hanterar stilsättning vilket därav också hämmar kompatibiliteten. SE är ett standardiserat format som har fördelen att det är kompatibelt med många programvaror. Dock visar vår fallstudie att samma SE-fil i många fall visualisers olika i olika programvaror, vilket inte borde vara fallet för ett standardiserat format. Det har även utvecklats många utvidgningar av SE med syftet att förbättra användningen av formatet inom olika områden. Nackdelen med den här utvecklingen är att ju fler utvidgningar desto mindre kompatibelt blir SE med olika programvaror. En slutsats är att programspecifika format såsom LYR- och QML-filer är de som fungerar bäst för stilsättning i respektive programvara och bör i dagsläget användas om syftet är att få så bra stilsättning som möjligt. Ett annat syfte var att kartlägga vilka lösningar som finns som ökar kompabiliten mellan olika format som hanterar stilsättning. Eftersom många myndigheter levererar stilsättning i form utav LYR-filer samt att många lösningar som hittades sade sig konvertera LYR-filer blev det formatet snabbt utgångspunkten i fallstudien. Tre lösningar som konverterar LYR-filer till SE-filer utreddes. En lösning som konverterar MXD-filer till QGS-filer utreddes också. En sista lösning bygger på att manuellt konvertera LYR-filen till ett annat format. Det här kan göras genom att använda befintlig stilsättning publicerad på internet eller genom att manuellt stilsätta datan. Det kan även konstateras att ingen lösning byggd på öppen källkod fungerade. Sammanfattningsvis är det ingen av de här lösningarna som skapar en stilsättning som är tillräckligt bra för att kunna användas direkt i en organisation. Alla lösningarna kräver någon form av manuell redigering. GeoCat Bridge som konverterar LYR-filer till SE-filer var den lösning som bäst utförde konverteringen. GeoCat Bridge kan med fördel användas som grund för att bygga vidare på en manuell stilsättning. Det slutgiltiga lösningsförslaget för att i dagsläget konvertera LYR-filer är att använda befintlig stilsättning från internet eller genom Resource Sharing och manuellt korrigera stilsättningen om den är bristfällig. Förslaget minskar beroendet av kommersiella programvaror då det visar på hur stilsättning i QGIS kan delas med andra slutanvändare. Om det inte finns någon befintlig stilsättning tillgänglig ska licenskostnaden för GeoCat Bridge vägas mot kostnaden för att stilsätta datan manuellt. Det här är förhoppningsvis ett förslag som kan ligga till grund för hur stilsättning hanteras i framtiden om inte det kommer att levereras i flera format från myndigheter med informationsansvar. Fallstudien har synliggjort bristerna på kompatibilitet mellan olika format för stilsättning. I enlighet med Inspire och Svensk Geoprocess kommer sannolikt allt mer data levereras i GML. Att myndigheter då kommer fortsätta leverera stilsättning i LYR-filer är inte troligt utan leverans av stilsättning bör troligtvis ske i SE då detta format också är en standard från OGC och kompatibelt med GML. Även om myndigheter med informationsansvar väljer att fortsätta leverera geografiska data i Shape-format bör de leverera stilsättning i flera format än LYR-filer för att underlätta för kommuner, företag och organisationer att själv välja vilken programvara de vill jobba i.

90 74 slutsatser Det har visat sig vara svårt att standardisera stilsättning för geografiska data då den ska klara av avancerad stilsättning men fortfarande vara lätt att använda. CSS är en standard som används för grafik på webbsidor och som fungerar väl. Det borde rimligtvis vara möjligt att skapa en lika väl fungerande standard även för stilsättning av geografiska data.

91 Litteratur [1] Harrie L. Geografisk informationsbehandling. Ver. 4. Stockholm: Forskningsrådet Formas, isbn: [2] Lupp M. Styled Layer Descriptor profile of the Web Map Service Implementation Specification. OGC Implementation Specification. Open Geospatial Consortium. Juni [3] Lantmäteriet. Goda exempel. url: goda-exempel/ (hämtad ). [4] Lantmäteriet. Utbyggd karta räddar liv. url: se / lara / goda - exempel / utbyggd - karta - raddar - liv/ (hämtad ). [5] Chan T.O, Feeney M-E, Rajabifard A och Williamson I. The dynamic nature of spatial data infrastructures: a method of descriptive classification. Tekn. rapport. Department of Geomatics, The University of Melbourne, Victoria 3010, Australia, [6] OGC. FAQ - OGC s purpose and structure. url: org/ogc/faq (hämtad ). [7] Baumann P. OGC WCS 2.0 Interface Standard- Core: Corrigendum. OGC Interface Standard. Open Geospatial Consortium. Juli [8] Vretanos A Panagiotis P. OpenGIS Web Feature Service 2.0 Interface Standard. OpenGIS Implementation Standard. Open Geospatial Consortium. Nov [9] Masó J, Pomakis K och Julíá N. OpenGIS Web Map Tile Service Implementation Standard. OpenGIS Implementation Standard. Open Geospatial Consortium. April [10] Inspire. About INSPIRE. url: (hämtad ). [11] Lantmäteriet. Inspire. url: https : / / www. geodata. se / styrande / inspire/ (hämtad ). [12] Riktlinjer för nationellt genomförande av Inspires nedladdningstjänster. Lantmäteriet. April [13] Inspire. DNF. 21 april url: SDICS/dnf (hämtad ). [14] Lantmäteriet. Sverige bygger en infrastruktur för geodata. I: (2012). [15] Teknisk ramverk Infrastruktur för geodata Diarienr: /4289. Lantmäteriet. Sept [16] Lantmäteriet. Öppna geodata. url: www. lantmateriet. se/ sv / Kartor - och - geografisk - information / Kartor / oppna - data/ (hämtad ). [17] Bertilsson A, Eriksson A-S, Falemo B, Haldorson M, Honauer U, Kjelsson B, Lorentzon F, Notter M, Olsson H, Stölen L-K, Söderström G och Wiberg P. Sverige behöver öppna geodata. Juni [18] Lantmäteriet. Geodatarådet. url: (hämtad ). [19] Lantmäteriet. Nationell Geodatastrategi url: se / globalassets / dokumentarkiv / styrning - och - uppfoljning / geodatastrategin/nationell_geodatastrategi_ pdf. [20] Lantmäteriet. Geodatasamverkan. url: https : / / www. geodata. se / anvanda/geodatasamverkan/ (hämtad ).

92 76 LITTERATUR [21] Lakomaa E. Samhällsekonomisk effekt av öppna geodata. The Institute for Economic, Business History och Reserarch, Handelshögskolan Stockholm, [22] Lantmäteriet. Geodataportalen. url: geodataportalen/ (hämtad ). [23] SIS. Om SIS. url: sis/ (hämtad ). [24] Swedish Standards Institute. SIS/TK 323. url: informationsteknik-kontorsutrustning/kodning-av-information/ sis-tk-323 (hämtad ). [25] ULI Geoforum. Inget mer Stanli ny struktur för geodata inom SIS. url: inget- mer- stanli- ny- struktur- foer- geodata- inom- sis (hämtad ). [26] Lantmäteriet. Delredovisning av uppdraget - Effekter och konsekvenser av öppna data [27] Lantmäteriet. Geodataplatsen. url: http : / / www. lantmateriet. se / sv/om- Lantmateriet/Samverkan- med- andra/geodatasamverkan/ Geodataplatsen/ (hämtad ). [28] Lantmäteriet. Tekniskt ramverk och standard - Nedladdnings- och direktåtkomsttjänster. url: - information / Geodatatjanster / tekniskt - ramverk - och-standard---nedladdnings--och-direktatkomsttjanster/ (hämtad ). [29] Lantmäteriet. Geografisk Indelning Direkt. url: se/sv/kartor- och- geografisk- information/geodatatjanster/ nedladdnings--och-direktatkomsttjanster/geografisk-information/ geografisk-indelning-direkt/ (hämtad ). [30] Sveriges Kommuner och Landsting och Lantmäteriet. Svensk geoprocess. [31] Allstrin L och Bergström K. Uppdragsbeställning Datautbytesmodeller. Utgåva A. Svensk Geoprocess [32] Lantmäteriet. Geodata skapar nya möjligheter för studenter och forskare. [33] Vetenskapsrådet. Infrastrukturer för forskning. url: www. vr. se / forskningsinfrastruktur / infrastrukturerforforskning aba1326e7bd62a html (hämtad ). [34] Webbkarttjänster med av producenten definierade kartskikt SIS/TK 570 N0076. SIS/TK 570. Mars [35] HMK - Kartografi. Ver isbn: [36] Ehrlén M, Ek A, Hjorth K, Isaksson Forsgren A, Olovsson S, Tarandi M och Wilde K. Riktlinjer för webbkartografi inom krishantering. Myndigheten för samhällsskydd och beredskap, Lantmäteriet, Försvaret. Dec [37] Swedish Standards Institute. Webbkartografi. url: http :// www. sis. se/ informationsteknik- kontorsutrustning/ allm% C3% A4nt/ sistk-570 (hämtad ). [38] Webbkarttjänster med av användaren definierade kartskikt Utkast. SIS/TK 570. Febr [39] Swedish Standards Institute. Geografisk information - Modell för avbildning av geografiska data (IS :2012). url: informationsteknik - kontorsutrustning / allm % C3 % A4nt / ss - en - iso (hämtad ). [40] QGIS Sverige. QGIS Sverige. url: (hämtad ).

93 LITTERATUR 77 [41] Gerd Mardal. Retningslinjer for dataformater ved formidling av stedsdata Kartverket [42] Jakobsson A. Data quality and quality management examples of quality evaluation procedures and quality management in European national mapping agencies. I: Spatial data quality (2002). [43] Ordnance Survey. Weŕe all about location. 21 april url: https : // we- do.html (hämtad ). [44] Ordnance Survey. OS MasterMap Topography Layer. 21 april url: and- government/ products/topography-layer.html (hämtad ). [45] Ordnance Survey. Cartographic Stylesheet - User Guide url: https: // guides/cartographicstylesheet-user-guide.pdf. [46] Lantmäteriet. About Oskari url: http : / / www. oskari. org / documentation (hämtad ). [47] MacWright T., Käfer K., Ashton AJ. och Springmeyer D. CartoCSS. 4 maj url: https : / / github. com / mapbox / carto (hämtad ). [48] ESRI Shapefile Technical Description. White Paper. ESRI. Juli [49] Portele C. OGC Geography Markup Language (GML) - Extended schemas and encoding rules. OpenGIS Implementation Standard. Febr [50] Lake R. Introduction to GML - Geography Markup Language. url: https: / / www. w3. org / Mobile / posdep / GMLIntroduction. html (hämtad ). [51] Gröger G, Kolbe T.H, Nagel C och Häfele KH. OGC City Geographic Markup Language (CityGML) Encoding Standard. OpenGIS Encoding Standard. Open Geospatial Consortium. April [52] Google Developers. KML Tutorial. 11 jan url: google.com/kml/documentation/kml_tut (hämtad ). [53] Wilson T. OGC KML. OGC Standard. Open Geospatial Consortium [54] Google Developers. What is KML? url: com/kml/ (hämtad ). [55] Open Geospatial Consortium. GeoPackage. url: org/ (hämtad ). [56] SQLite. About SQLite. url: www. sqlite. org/ about. html (hämtad ). [57] Butler H, Daly M, Doyle A, Gillies S, Hagen S och Schaub T. The GeoJSON Format. RFC RFC Editor, aug [58] de la Beaujardiere J. OpenGIS Web Map Server Implementation Specification. OpenGIS Implemenation Specification. Open Geospatial Consortium [59] World Wide Web Consortium. HTML Styles -CSS. url: w3schools.com/html/html_css.asp (hämtad ). [60] Lantmäteriet. Bilaga 1 med bildexempel - Behov av en samordnad kartografi for OGC-tjänster (WMS, WFS mfl). 1. utg [61] Müller M. Symbology Encoding Implementation Specification. OGC Implementation Standard. Open Geospatial Consortium. Juli [62] OGC. The OGC Announces Styled Layer Descriptor & Symbology Encoding Specifications. 31 jan url: www. opengeospatial. org/ pressroom/pressreleases/761 (hämtad ).

94 78 LITTERATUR [63] Paasch J M. Standarder för geodata - till vilken nytta? I: Samhällsbyggaren (2016). [64] Ionuţ Enescu I, Panchaud N H, Heitzler M, Iosifescu E, Cristina M och Hurni L. Towards Better WMS Maps Through the Use of the Styled Layer Descriptor and Cartographic Conflict Resolution for Linear Features. I: The Cartographic Journal Ver (2015), s [65] Christophe S, Duménieu B, Turbet J, Hoarau C, Mellado N, Ory J, Loi H, Masse A, Arbelot B, Vergne R, Brédif M, Hurtut T, Thollot J och Vanderhaeghe D. Map Style Formalization: Rendering Techniques Extension for Cartography. I: Non-Photorealistic Animation and Rendering. Utg. av Bénard P och Winnemöller H. The Eurographics Association, isbn: doi: /exp [66] Dietze L och Zipf A. Extending OGC Styled Layer Descriptor (SLD) for Thematic Cartography. I: Proc. 4th Int. Symp. on LBS and Telecartography. Springer, Heidelberg [67] Rita E, Borbinha J och Martins B. Extending SLD and SE for cartograms. I: Proceedings of the GSDI Ver. 12 (2010). [68] Vretanos P. OpenGIS Filter Encoding 2.0 Encoding Standard. I: (nov. 2010). OpenGIS Implementation Standard. [69] Esri. Layer file. 10 jan url: (hämtad ). [70] Menke K, Dr.Smith Jr.R, Dr. Pirelli L och Dr. Van Hoesen J. Mastering QGIS. Birmingham: Packt Publishing, isbn: [71] W3C. About W3C. url: (hämtad ). [72] World Wide Web Consortium. SVG Tutorial. url: com/graphics/svg_intro.asp (hämtad ). [73] Le Hégaret P, Whitmer R och Wood L. Document Object Model (DOM). 19 jan url: (hämtad ). [74] W3C. XSLT Introduction. url: svg_intro.asp (hämtad ). [75] Nuemann A och Qinter A.M. Vector-based Web Cartography. Tekn. rapport. Institute of Cartography, Swiss Federal Institute of Technology (ETH), Zurich, Institute for Geography och Regional Studies, University of Vienna, [76] Open Source Initiative. The Open Source Definition. 22 mars url: (hämtad ). [77] Steiniger S och Bocher E. An overview on current free and open source desktop GIS developments. I: International Journal of Geographical Information Science Ver (2009), s doi: / eprint: url: http : / / www. dpi. inpe. br / cursos / ser300 / Referencias / sstein_foss_desktop_gis_overview_ijgis_2008.pdf. [78] Open Source Initiative. The license Review Process. url: org/approval (hämtad ). [79] Open Source Initiative. Report of License Proliferation Committee and draft FAQ. url: report (hämtad ). [80] Open Source Initiative. Frequently Answered Questions. url: opensource.org/faq#copyleft (hämtad ). [81] New Media Rights. Open Source Licensing Guide. 12 sept url: open_source_licensing_guide (hämtad ).

95 LITTERATUR 79 [82] Open Source Geospatial Foundation. About the Open Source Geospatial Foundation. url: about.html (hämtad ). [83] QGIS. About QGIS. url: index.html (hämtad ). [84] GeoServer. What is GeoServer? url: http : / / geoserver. org / about/ (hämtad ). [85] GeoServer. SLD Extension in GeoServer. 10 april url: docs.geoserver.org/latest/en/user/styling/sld/extensions/ index.html (hämtad ). [86] Esri. What is ArcMap? url: arcmap/10.3/main/map/what-is-arcmap-.htm (hämtad ). [87] GeoCat. How to export from Bridge to an SLD file? url: geocat.net/knowledgebase.php?action=displayarticle&id=60 (hämtad ). [88] Arc2Earth. Export Map Symbols to Styled-Layer Descriptor (SLD). url: (hämtad ). [89] Weiser A. A tool for reading out styling information from ArcMap and converting into Styled Layer Descriptor-Files (SLD) of OGC. url: arcmap2sld.i3mainz.hs-mainz.de/arcmap2sldconverter_eng.htm (hämtad ). [90] Dempsey C. MXD - ArcMap Document File. com/mxd-arcmap-document/. Blog [91] Gumbira A. QGIS Resource Sharing. url: com/qgis_resources_sharing/ (hämtad ). [92] Gumbira A. Installing the Plugin. url: http : / / www. akbargumbira. com/ qgis_ resources_ sharing/ user/ installation. html (hämtad ).

96 Appendix A Myndigheter med informationsansvar Följande myndigheter, kommuner och enskilda organ har ett informationsansvar enligt 3 kap 1-33 Förordning (SFS 2010:1770) om geografisk miljöinformation Lantmäteriet Sveriges meteorologiska och hydrologiska institut (SMHI) Trafikverket Luftfartsverket Sjöfartsverket Havs- och vattenmyndigheten Naturvårdsverket Skogsstyrelsen Sveriges geologiska undersökning (SGU) Sveriges geotekniska institut Statistiska centralbyrån (SCB) Riksantikvarieämbetet Statens jordbruksverk Sametinget Myndigheten för samhällsskydd och beredskap (MSB) Socialstyrelsen Folkhälsomyndigheten Länsstyrelsen Inspektionen för vård och omsorg Statens skolverk Svenska kraftnät AB Strålsäkerhetsmyndigheten Sveriges lantbruksuniversitet Statens energimyndighet.

97 b geografiska objekt i fallstudien. 81 B Geografiska objekt i fallstudien. Tabell B.1: Punktobjekt i fallstudie från lagret Bebyggelsesymboler i Vägkartan. Källa: c Lantmäteriet. Namn Typ av stilsättning ID Stilsättning Badplats Illustrativ P1 Golfbana Illustrativ P2 Gästhamn Illustrativ P3 Kyrka Illustrativ P4 Vindkraftverk Illustrativ P5 Skjutbana Enkel P6 Skorsten Enkel P7 Travbana Enkel P8 Hus, 1 storleksklass Enkel P9 Tabell B.2: Linjeobjekt från Vägkartan. Källa: c Lantmäteriet. Namn Typ av stilsättning ID Stilsättning Administrativa gränser: Kommungräns Streckad linje L1 Kraftledningar: stam Kraftledning Kraftledningar: Kraftledning region Kraftledningar: Kraftledning, stam och region i samma ledningsgata Består av två lager Består av två lager Består av två lager Vägar: Motorväg, ej riksväg Består av två lager L6 L3 L4 L5 Vägar: Motorväg, Riksväg Består av två lager L7

98 82 appendix Tabell B.3: Linjeobjekt från lagret Begränsningslinjer för Källa: c Lantmäteriet. markslag i Vägkartan. Namn Typ av stilsättning ID Stilsättning Öppen mark -sankmark,normal eller svårframkomlig Heldragen linje L8 Bebyggelseområde - öppen mark Heldragen linje L11 Bebyggelseområde - skog Heldragen linje L12 Vattenyta - sankmark, normal eller svårframkomlig Heldragen linje L13 Vattenyta - öppen mark Heldragen linje L14 Vattenyta - skog Heldragen linje L15 Vattenyta - bebyggelseområde Heldragen linje L16 Basbegränsning - öppen mark Heldragen linje L17 Basbegränsning - bebyggelseområde Heldragen linje L18 Tabell B.4: Ytobjekt i fallstudie från lagret Bebyggd mark i Terrängkartan. Källa: c Lantmäteriet. Namn Typ av stilsättning ID Stilsättning Fritidsbebyggelse Avancerat mönster Y1 Hög bebyggelse Färgtoner Y2 Industriområde Färgtoner Y3 Låg bebyggelse Färgtoner Y4 Sluten bebyggelse Färgtoner Y5 Tabell B.5: Ytobjekt i fallstudie från lagret Jordart, grundlager i Jordartskartan 1:1 miljon. Källa: c Lantmäteriet. Namn Typ av stilsättning ID Stilsättning Moränlera eller lerig morän Picture Fill Symbol Y6 Torv Isälvssediment Vatten Morän Postglacial sand - grus Lera - silt Helt fylld och outline Helt fylld och outline Helt fylld och outline Helt fylld och outline Helt fylld och outline Helt fylld och outline Y7 Y8 Y9 Y10 Y11 Y12

99 c resultat för geocat bridge och arc2earth 83 C Resultat för GeoCat Bridge och Arc2Earth C.1 Punkter med enkel stilsättning Figur C.1.a: Punkter före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.1.b: Punkter efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.1.c: Punkter efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.1.d: Punkter efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.1.e: Punkter efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.1.f: Symboler efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

100 84 appendix C.2 Symbol för järnväg Figur C.2.a: Symboler före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.2.b: Symboler efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.2.c: Symboler efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.2.d: Symboler efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.2.e: Symboler efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.2.f: Symboler efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

101 c resultat för geocat bridge och arc2earth 85 C.3 Bebyggelsesymboler Figur C.3.a: Symboler före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.3.b: Symboler efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.3.c: Symboler efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.3.d: Symboler efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.3.e: Symboler efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.3.f: Symboler efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet.

102 86 appendix C.4 Begränsningslinjer för markslag Figur C.4.a: Begränsningslinjer före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.4.b: Begränsningslinjer efter konvertering med GeoCat Bridge via Geoserver. Källa: c Lantmäteriet. Figur C.4.c: Begränsningslinjer efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.4.d: Begränsningslinjer efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.4.e: Begränsningslinjer efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.4.f: Begränsningslinjer efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

103 c resultat för geocat bridge och arc2earth 87 C.5 Administrativa gränser Figur C.5.a: Administrativa gränser innan konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.5.b: Administrativa gränser efter konvertering med GeoCat Bridge via Geo- Server. Källa: c Lantmäteriet. Figur C.5.c: Administrativa gränser efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.5.d: Administrativa gränser efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.5.e: Administrativa gränser efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.5.f: Administrativa gränser efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

104 88 appendix C.6 Kraftledningar Figur C.6.a: Kraftledningar innan konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.6.b: Kraftledningar efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.6.c: Kraftledningar efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.6.d: Kraftledningar efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.6.e: Kraftledningar efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.6.f: Kraftledningar efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

105 c resultat för geocat bridge och arc2earth 89 C.7 Vägar Figur C.7.a: Vägar före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.7.b: Vägar efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.7.c: Vägar efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.7.d: Vägar efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.7.e: Vägar efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.7.f: Vägar efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

106 90 appendix C.8 Högexploaterad kust Högexploaterad kust Figur C.8.a: Högexploaterad kust före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.8.b: Högexploaterad kust efter konvertering med GeoCat Bridge via Geo- Sever. Källa: c Lantmäteriet. Figur C.8.c: Högexploaterad kust efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.8.d: Högexploaterad kust efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.8.e: Högexploaterad kust efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.8.f: Högexploaterad kust efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet.

107 c resultat för geocat bridge och arc2earth 91 C.9 Naturvård Naturvård Figur C.9.a: Naturvård före konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.9.b: Naturvård efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.9.c: Naturvård efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.9.d: Naturvård efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.9.e: Naturvård efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.9.f: Naturvård efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

108 92 appendix C.10 Bebyggd mark Figur C.10.a: Bebyggd mark före konvertering, presenterad i ArcMap. Källa: c Lantmäteriet. Figur C.10.b: Bebyggd mark efter konvertering med GeoCat Bridge via GeoServer. Källa: c Lantmäteriet. Figur C.10.c: Bebyggd mark efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.10.d: Bebyggd mark efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.10.e: Bebyggd mark efter konvertering med Arc2Earth, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.10.f: Bebyggd mark efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

109 c resultat för geocat bridge och arc2earth 93 C.11 Jordart, grundlager Figur C.11.a: Jordart, grundlager innan konvertering, presenterat i ArcMap. Källa: c Lantmäteriet. Figur C.11.b: Jordart, grundlager efter konvertering med GeoCat Bridge med GeoServer. Källa: c Lantmäteriet. Figur C.11.c: Jordart, grundlager efter konvertering med GeoCat Bridge, presenterat i QGIS. Källa: c Lantmäteriet. Figur C.11.d: Jordart, grundlager efter konvertering med GeoCat Bridge, presenterat i udig. Källa: c Lantmäteriet. Figur C.11.e: Jordart, grundlager efter konvertering med Arc2Earth, presenteras i QGIS. Källa: c Lantmäteriet. Figur C.11.f: Jordart, grundlager efter konvertering med Arc2Earth, presenterat i udig. Källa: c Lantmäteriet.

110 94 appendix D Lagers uppbyggnad Tabell D.1: Punkt med enkel stilsättning. Programvara Typ av objekt Form Storlek Grund: ArcMap Simple Marker Symbol Circle 4 GeoCat: QGIS Simple Marker Circle 4 udig Simple Style Circle 4 Arc2Earth: QGIS Simple Marker Circle 6 udig X X X Tabell D.2: Symbol för järnväg. Programvara Typ av objekt Form Storlek Grund: ArcMap Character Marker Symbol J, Font Arial 6 Simple Marker Symbol Circle 7 GeoCat: QGIS Simple Marker Circle 6 Simple Marker Circle 7 udig X X X Arc2Earth: QGIS X X X udig Graphic Based Style Tabell D.3: Bebyggelsesymboler (objekt: badplats). Programvara Typ av objekt Font Kod Storlek Grund: ArcMap Simple Marker GSDSymbolsVagkartan GeoCat: QGIS Simple Marker 13 udig Font Based stile GSDSymbolsVagkartan? 13 Arc2Earth: QGIS X X X udig Graphics Based Style Tabell D.4: Begränsningslinjer för markslag. Grund: Programvara Typ av objekt Storlek ArcMap Simple Line Symbol 0,1 GeoCat: QGIS Simple Line 0,1 udig Line 0 Arc2Earth: QGIS Simple Line 0,1 udig Line 0

111 d lagers uppbyggnad 95 Tabell D.5: Administrativa gränser (objekt:kommungräns). Programvara Typ av objekt Storlek Mönster Grund: ArcMap Cartographic Line Symbol 1 1(vit),1(svart),1,1,1,3 GeoCat: QGIS Simple Line 1 1(vit),1(svart),1,1,1,3 udig Line 1 1(vit),1(svart),1,1,1,3 Arc2Earth: QGIS Simple Line 1 1(vit),1(svart),1,1,1,3 udig Line 1 1(vit),1(svart),1,1,1,3 Tabell D.6: Kraftledningar (objekt:region). Grund: Programvara Typ av objekt Storlek Vinkel Mönster ArcMap Hash Line Symbol (vit),1(svart),7 Cartographic Line Symbol 0,8 GeoCat: QGIS Simple Line 4 no angle 7(vit),1(svart),7 Simple Line 0,8 udig X X X X Arc2Earth: QGIS Simple Line 4 no angle 7(vit),1(svart),7 Simple Line 0,8 udig X X X X Tabell D.7: Vägar (objekt: motorväg). Grund: Programvara Typ av objekt Storlek ArcMap Cartographic Line Symbol 0,8 Cartographic Line Symbol 2,6 Cartographic Line Symbol 3,4 GeoCat: QGIS Simple Line 0,8 Simple Line 2,6 Simple Line 3,4 udig X X Arc2Earth: QGIS Simple Line 0,8 Simple Line 2,6 Simple Line 3,4 udig X X

112 96 appendix Tabell D.8: Högexploaterad kust. Grund: Programvara Typ av objekt ArcMap Line Fill Symbol Vinkel:-45, Separation:4 Line: Simple Line Symbol Bredd:1 Outline: Marker Line Symbol Bredd:7, Mönster:1(svart), 5(vit) Symbol: Character Marker Symbol Bredd:7, Font:ESRI Default Marker GeoCat: QGIS Simple fill Fill: no fill, Outline: dash Simple fill Fill:solid, Outline: no outline udig X X Arc2Earth: QGIS Simple line width:7 Simple fill Fill: solid, Outline: no outline Simple fill Fill: solid, Outline: solid udig X X Tabell D.9: Naturvård. Grund: Programvara Typ av objekt ArcMap Line Fill Symbol Vinkel: -45, Separation:4 Line: Simple Line Symbol Bredd:1 Outline: Simple Line Symbol Bredd:7 GeoCat: QGIS Simple fill Fill: no fill, Outline: solid (width:2) udig Border: bredd :2 Fill:Well known mark:inverse diagonal lines bredd:1, size 8 Arc2Earth: QGIS Simple fill Fill: solid, Outline: solid (width:2) udig Border Bredd:2 Fill green

113 d lagers uppbyggnad 97 Tabell D.10: Bebyggd mark (objekt: Fritidsbybyggelse, objekt Y1). Grund: Programvara Typ av objekt ArcMap Line Fill Symbol Angle:135, Separation:1,9842 Line: Cartographic Line Symbol Width:0,4252 Outline: None Line Fill Symbol Angle:45, Separation:1,9842 Line: Cartographic Line Symbol Width:0,4252 Outline: None GeoCat: QGIS Simple fill Fill: no fill, Outline: no fill Simple fill Fill: no fill, Outline: no fill udig Border:none Fill: Well known mark: diagonal lines width: size:3 Arc2Earth: QGIS Simple line Hairline, solid Simple fill Fill: no fill, Outline: no fill Simple line Hairline, solid Simple Fill Fill: no fill, Outline: no fill udig X X Tabell D.11: Jordart, grundlager (objekt: Moränlera eller lerig morän, objekt Y6). Grund: Programvara ArcMap Typ av objekt Picture Fill Symbol Outline: Simple Fill Symbol Outline: width:0,25 None GeoCat: QGIS Simple fill Fill: solid, Outline: solid (width:0,25) Simple fill Fill: solid, Outline: no outline udig Border:none X X Arc2Earth: QGIS Simple fill Fill: solid, Outline: solid (width:0,25) Simple fill Fill: solid, Outline: solid (width:0,25) udig X X

114 98 appendix E Resultat för MXD2QGS E.1 MXD2QGS Figur E.1.a: Resulterande QGS-fil för metoden MXD2QGS. Källa: c Lantmäteriet.

115 f resultat för användning av befintliga stilsättningar 99 F Resultat för Användning av befintliga stilsättningar F.1 QGIS Sverige Figur F.1.a: Terrängkartan före konvertering. Källa: c Lantmäteriet. Figur F.1.b: Terrängkartan efter konvertering. Figur F.1.c: Översiktskartan före konvertering. Källa: c Lantmäteriet. Figur F.1.d: Översiktskartan efter konvertering. F.2 chaoz Figur F.2.a: Terrängkartan före konvertering. Källa: c Lantmäteriet. Figur F.2.b: Terrängkartan efter konvertering.

116 100 appendix F.3 klakar Figur F.3.a: Terrängkartan före konvertering. Källa: c Lantmäteriet. Figur F.3.b: Terrängkartan efter konvertering. F.4 mara91 Figur F.4.a: Terrängkartan före konvertering. Källa: c Lantmäteriet. Figur F.4.b: Terrängkartan efter konvertering.