Rapport TK 570 N0047. Geografisk information Webbkartografi Riktlinjer för utformning av webbkarttjänster

Transkript

1 Rapport TK 570 N0047 Utgåva Geografisk information Webbkartografi Riktlinjer för utformning av webbkarttjänster [English title level 1 English title level 2 Part n: Part title]

2 SS xxxx:åååå (Sv) Innehåll Sida 1 Om denna rapport Status Orientering Omfattning Termer och definitioner samt förkortningar Termer och definitioner Förkortningar Riktlinjer Utgångspunkter för riktlinjer Systemarkitektur Ansvar Teknik Alternativa kartskikt Objektinformation Texter i kartan Skalintervall Bakgrundsskikt Punktsymbolisering Linjesymbolisering Ytsymbolisering Tjänstespecifikation Bilaga: Tekniska möjligheter och begränsningar Inledning Generell systemarkitektur Kartografiska aspekter på geodataservern Kartografiska aspekter på kartservern Kartografiska aspekter på kartbildservern Kartografiska aspekter på applikationsservern Kartografiska aspekter på kartapplikationen Standardiserade språk för symbolutformning Bilaga: Bakgrundskartor Inledning Kartografi för bakgrundskartor Lyfta fram viktig information i bakgrundskartor Bilaga: Kartografi för tematiska skikt vid sampresentation av kartskikt Introduktion Utvärderingskriterier Sampresentation av bakgrundsskikt och tematiska skikt med ytgeometri Problemställning Prickrastrering Transparens Tvåskiktslinje som konturlinje Linjerastrering i olika riktningar Linjerastrering med olika färger Sampresentation av bakgrundskartor och tematiska skikt med linjegeometri Problemställning Tvåskiktslinje Halvtransparant linje Streckad (alternativt punktstreckad) linje Sampresentation av bakgrundskartor och tematiska skikt med punktgeometri Problemställning Använda grafiska variabeln färg för att särskilja punkter Använda grafiska variabeln storlek för att särskilja punkter Använda grafiska variabeln form för att särskilja punkter

3 6.6 Sampresentation av bakgrundskartor och tematiska skikt med skilda geometrityper Problemställning Sampresentation av bakgrundskartor och beskrivande data Bilaga: Exempel på teknisk beskrivning Litteraturförteckning

4 TK 570 N Om denna rapport 1.1 Status Denna rapport är inte den slutliga tekniska rapport som standardiseringsarbetet i SIS/Stanlis kommitté för webbkartografi (SIS/TK 570) syftar till. Med denna rapport vill kommittén visa vad den kommit fram till hittills. Det arbete som återstår är framför allt riktlinjer för utformning av alternativa kartografiska presentationssätt. Antalet alternativa presentationssätt måste av praktiska skäl begränsas och det krävs ett omfattande laborerande för att kunna konstatera vilka presentationssätt som är de mest lämpliga ur kombinationssynvinkel. Den som har synpunkter på innehållet är välkommen att kontakta kommitténs projektledare, se I rapporten finns bilagor där sådant material tagits med som ger en kunskapsbakgrund till riktlinjerna. Här förklaras också mer i detalj de viktiga tekniska begrepp som refereras i riktlinjerna. Delar av bilagorna kan i framtida utgåvor av denna rapport ersättas av riktlinjer. Arbetet med riktlinjerna kommer att fortsätta löpande under 2014 och redovisas med publicering av fler utgåvor. 1.2 Orientering Denna rapport handlar om visningstjänster av typen Web Map Service (WMS)[4] eller Web Map Tile Service (WMTS)[6]. De kallas här för webbkarttjänster. Rapporten handlar om hur man bör konstruera en webbkarttjänst så att dess kartskikt blir så användbara som möjligt när de kombineras med kartskikt från andra webbkarttjänster. Även om tekniken idag medger att den som konsumerar en webbkarttjänst själv styr detaljerna i utformningen av kartskikten så är det inte det som är utgångspunkten för denna rapport. I stället förutsätts att den som tillhandahåller webbkarttjänsten också bestämmer över utformningen av kartskikten, men i gengäld erbjuder alternativa utformningar. Det är lätt att inse att denna metod inte kan lyckas i varje tänkbart fall, inte ens med ett stort antal alternativa utformningar. Utgångspunkten i arbetet har dock varit att förutsättningarna att lyckas kan bli oerhört mycket större med riktlinjer än utan. Figur 1 visar hur den applikations- eller tjänstedesigner (i mitten av figuren) som kombinerar kartskikt från olika webbkarttjänster utgår från erbjudanden från flera olika tjänsteleverantörer. Det ställer vissa krav på webbkarttjänsternas utformning och dokumentation. Det är till tjänsteleverantörerna (till vänster i figuren) som riktlinjerna i denna tekniska rapport vänder sig. En viktig egenskap är att deras webbkarttjänster är kartografiskt designade för att kunna kombineras och användas tillsammans. I praktiken betyder det att de måste innehålla alternativa kartskikt som går att kombinera utan att läsbarhet och begriplighet påverkas negativt. Applikationsdesignern (som kan vara en tjänstedesigner) har att välja bland olika, alternativa kartskikt. Riktlinjer för dessa val tas endast upp indirekt i denna tekniska rapport men planeras att ingå i kommande utgåvor. I verkligheten kan användaren och applikationsdesignern finnas inom samma organisation eller till och med vara en och samma person. 4

5 1.3 Omfattning Figur 1 - Enkel samverkansmodell för webbkarttjänster med kombinerbara kartskikt. Denna rapport anger riktlinjer för att utforma och erbjuda WMS- och WMTS-baserade visningstjänster, särskilt med tanke på att vara användbara för den som har behov av att skapa webbkartor genom att kombinera kartskikt från flera webbkarttjänster. Riktlinjerna omfattar valmöjligheter i urvalet av data och presentationen av data men även annat som kan stödja utvecklingen av applikationer och tjänster som baseras på webbkarttjänsterna, exempelvis information om valmöjligheter och testmöjligheter för utvecklarna. Denna tekniska rapport innehåller även terminologi för området och en orientering om tekniska lösningar för denna typ av tjänster. Riktlinjerna tar upp hur kombinerbarhet optimeras genom att varje kartskikt inte visar för många objekttyper hur kombinerbarhet optimeras genom lämpliga alternativa presentationsalternativ hur tjänsten, inklusive valmöjligheter, bör dokumenteras hur tekniska behov, som gränssnitt och filformat, bör tillgodoses. 5

6 TK 570 N Termer och definitioner samt förkortningar 2.1 Termer och definitioner För tillämpning av detta dokument gäller de termer som följer nedan. applikationsgränssnitt gränssnitt som program använder för att konsumera en tjänst Anm. 1 till termpost: I tekniska sammanhang används ofta termen tjänste-api. [KÄLLA: Vad är en tjänst?, Stanli [12] ] attribut representation av en företeelses egenskap attributdata attributen hos ett dataobjekt bakgrundskarta bakgrundsskikt som utgörs av en karta bakgrundsskikt bakgrund i en webbkarta med syfte att ge geografisk orientering Anm. 1 till termpost: En karta eller ett ortofoto kan utgöra ett bakgrundsskikt. bastjänst IT-baserad tjänst med applikationsgränssnitt [KÄLLA: Vad är en tjänst?, Stanli [12] ] dataobjekt datarepresentation av företeelse digital karta karta avsedd att presenteras på en bildskärm erbjuda en tjänst utställa löften om en tjänsts förmågor och om den prestation och kvalitet som den som konsumerar tjänsten kan förvänta sig samt villkor för konsumerandet [KÄLLA: Vad är en tjänst?, Stanli [12] ] fyllning grafisk markering av yta där ytans innandöme, men inte dess kontur, markeras färgfyllning fyllning där ytan har en färg med viss transparens generalisering åtgärder för att optimera läsbarhet och begriplighet hos en webbkarta Anm. 1 till termpost: Generalisering kan t.ex. innebära urval av geodata och/eller förenkling vid symbolisering. Anm. 2 till termpost: Generaliseringen påverkas vanligen av aktuell skala. 6

7 geodata data som beskriver företeelser inklusive deras geografiska läge geodatalager geodatamängd som innehåller geodataobjekt för ett urval objekttyper Anm. 1 till termpost: Urvalet motsvarar vanligen ett geodatatema. Anm. 2 till termpost: I WMS-standarden[4] motsvarar varje "layer" ett geodatalager. geodatamängd identifierbar samling geodata geodataobjekt dataobjekt som inkluderar företeelsens geografiska läge geodataserver server som tillgängliggör geodata geodatatema identifierbar grupp av idémässigt samhörande objekttyper för geodata gruppskikt av webbkartservern levererat kartskikt som är resultat av en begäran om en sekvens av kartskikt ANM. Ett gruppskikt kan inte i efterhand delas upp i enskilda kartskikt. gränssnitt (inom dataområdet: ) formellt specificerad och beskriven koppling eller kontaktyta mellan system, enheter och människa i olika kombinationer Anmärkning Gränssnitt kan t.ex. gälla fysisk hopkoppling, signaler eller funktioner. Om man avser kontaktytan mellan människa och maskin talar man ofta om användargränssnitt. [Källa: TNC: Basord i våra fackspråk, 2011] ikon grafisk symbol på bildskärm som representerar ett dataobjekt IT-baserad tjänst tjänst som konsumeras via ett elektroniskt gränssnitt och som helt eller delvis produceras elektroniskt [KÄLLA: Vad är en tjänst?, Stanli [12] ] karta tvådimensionell, förminskad, redigerad avbildning av en del av jordens eller annan planets yta i bestämd skala och projektion kartapplikation program som på en bildskärm visar digitala kartor vilkas innehåll och omfattning kan styras av programmets användare kartografi läran om framställning av kartor kartserver server som producerar kartskikt och bakgrundsskikt och där begäran och leverans av dessa sker via Internet 7

8 TK 570 N0047 Anm. 1 till termpost: En web map server är en kartserver som följer WMS-standarden. kartskikt presentation av geodata som tillhör ett urval av objekttyper konsumera en tjänst nyttja en tjänst få en tjänst att produceras och tillgodogöra sig det den presterar [KÄLLA: Vad är en tjänst?, Stanli [12] ] konturlinje, kantlinje grafisk linje längs en ytas kontur konturlinjering grafisk markering av yta där ytans konturer markeras med en konturlinje linje endimensionellt geometriskt objekt Anm. 1 till termpost: Jämför grafisk linje. yta tvådimensionellt geometriskt objekt grafisk linje grafisk presentation av linje linjemönstring regelbundet upprepande av grafiskt element längs en linjes sträckning linjeobjekt geodataobjekt där det geografiska läget beskrivs av geometrin hos en eller flera linjer linjesymbolisering symbolisering av ett linjeobjekt objekttyp abstraktion av en grupp av företeelser med likartade egenskaper opacitet grad av ogenomskinlighet producera en tjänst se till att en tjänsts utlovade prestationer och kvalitet uppstår [KÄLLA: Vad är en tjänst?, Stanli [12] ] punktobjekt geodataobjekt där det geografiska läget beskrivs av geometrin hos en punkt punktsymbolisering symbolisering av ett punktobjekt rastrering ytmönstring med punktmönster 8

9 referensskikt kartskikt som visas i syfte att ge geografisk orientering server program som tillhandahåller gemensamma servicefunktioner i ett datornät skraffering ytmönstring med parallella grafiska linjer stilmall samling av symboliseringsfunktioner Anm. 1 till termpost: En stilmall omfattar vanligen objekttyperna i ett geodatatema. Anm. 2 till termpost: Maskinläsbara stilmallar kan beskrivas med Symbology encoding. Anm. 3 till termpost: I WMS-standarden motsvarar varje "style" en stilmall. symbolisering åtgärd för att grafisk presentera ett geodataobjekt Anm. 1 till termpost: Symbolisering inbegriper såväl utseende som orientering och placering. symboliseringsfunktion funktion som åstadkommer symbolisering av geodataobjekt av en viss objekttyp Anm. 1 till termpost: Tidigare svensk översättning: visualiseringsfunktion en feature portrayal function tematiskt skikt kartskikt som presenterar geodataobjekt för ett geodatatema textsymbolisering symbolisering av text tillhandahålla en tjänst erbjuda en tjänst och ta ansvar för att den produceras [KÄLLA: Vad är en tjänst?, Stanli [12] ] tjänst paketerad service eller lösning som erbjuds för att tillgodose ett behov Anm. 1 till termpost: Paketerad betyder att en tjänst kan erbjudas i samma form till flera mottagare (och ofta även prissättas). Leverans och konsumtion av en tjänst sker i regel samtidigt. En tjänst kan bestå av flera andra tjänster. [KÄLLA: E-delegationen: Terminologi för e-förvaltning, 2011] tjänsteleverantör den som tillhandahåller en tjänst [KÄLLA: Vad är en tjänst?, Stanli [12] ] tjänstespecifikation beskrivning av en tjänst med syfte att göra det möjlig att konsumera tjänsten och nyttja dess förmågor samt ställa krav på dess kvalitet och prestationer 9

10 TK 570 N0047 Anm. 1 till termpost: En tjänstespecifikation beskriver, särskilt när det gäller IT-baserade tjänster, bland annat dess gränssnitt. [KÄLLA: Vad är en tjänst?, Stanli [12] ] transparens grad av genomskinlighet visningstjänst bastjänst för att visualisera data [KÄLLA: Vad är en tjänst?, Stanli [12] ] web map server kartserver som följer WMS-standarden Anm. 1 till termpost: En web map server levererar kartskikten sammanslagna som en enda digital bild. web map service webbkarttjänst som implementeras av en web map server webbkarta digital karta som helt eller delvis är resultatet av bergäran till och leverans från en eller flera kartservrar webbkartografi kartografi för webbkartor webbkarttjänst bastjänst som kan leverera hela eller delar av webbkartor ytobjekt geodataobjekt där det geografiska läget beskrivs av geometrin hos en eller flera ytor ytsymbolisering symbolisering av ett ytobjekt 2.2 Förkortningar CGI Common Gateway Interface CRS Coordinate reference system GIF Graphics Interchange Format (ett format för digitala bilder) JPEG Joint Photographic Expert Group 1 (ett format för digitala bilder) OGC Open Geospatial Consortium PNG Portable Network Graphics (ett format för digitala bilder) SE Symbology Encoding SLD Styled Layer Descriptor SVG Scalable Vector Graphics WFS Web Feature Service WMS Web Map Service WMTS Web Map Tile Service XML exstensible Markup Language 10

11 3 Riktlinjer 3.1 Utgångspunkter för riktlinjer IT-miljön kring webbkartor kan se mycket skiftande ut: De som konstruerar webbkarttjänsterna kan använda sig av olika tjänsteplattformar för utveckling och drift utvecklingsmiljöer. De som kombinerar webbkarttjänsternas kartskikt kan använda sig av olika utvecklingsmiljöer och plattformar. De som slutligen ska titta på de färdiga webbkartorna kan använda sig av olika klientprogramvara för detta. Även hur man arbetar som applikationsdesigner kan skilja sig: Den färdiga applikationen riktar sig till olika, mer eller mindre kända, målgrupper. De kartskikt som ska kombineras kan komma både från webbkarttjänster och finnas eller genereras lokalt. Det finns möjligheter att påverka tjänsteleverantören att anpassa presentationen. Estetiska mål kan vara mer eller mindre viktiga i förhållande till läsbarhet och begriplighet. Även om förhållanden kan vara väldigt olika så måste riktlinjerna i denna rapport utgå från en förenklad modell: Det finns inga möjligheter för applikationsdesignern att påverka kartskikten annat än genom att välja bland de alternativ som erbjuds. Alla kartskikt, inklusive bakgrundsskikt, kommer från tjänster baserade på Web Map Service (WMS)[4][5] eller Web Map Tile Service (WMTS)[6], se 4.1. De möjligheter till styrning av presentationen minst motsvarar den som Styled Layer Descriptor (SLD)[2] och Symbology Engine (SE)[3] erbjuder, se 4.1. Alla tjänster som applikationsdesignern har tillgång till har konstruerats utgående från riktlinjerna. Ambitionerna med riktlinjerna kan inte sättas hur högt som helst. Exempelvis kan man inte förvänta sig att hur många kartskikt som helst ska kunna överlappa varandra eller att bakgrundsskiktet ska kunna se ut hur som helst. 3.2 Systemarkitektur Riktlinjerna har sin utgångspunkt i de två systemarkitekturer som beskrivs i Figur 2. Båda baseras på att tjänsteleverantörer har satt upp visningstjänster. Dessa tjänster baseras vanligen på WMS-standarden men för bakgrundsskikt kan även WMTS-standarden vara aktuell. I den vänstra systemarkitekturen integreras två eller flera visningstjänster i en webbkartapplikation som i sin tur används via en webbläsare. I den högra systemarkitekturen integreras två eller flera visningstjänster i en kartapplikation. 11

12 TK 570 N0047 Figur 2 - Systemarkitekturer som riktlinjerna bygger på 3.3 Ansvar Riktlinje: Myndigheter som har ett tematiskt informationsansvar bör också ta ansvar för val av färger och symboler. Det är i dagsläget inte möjligt att en tjänsteproducent erbjuder full valfrihet när det gäller färger och symboler. Genom Lagen (2010:1767) om geografisk miljöinformation[11] har det tematiska informationsansvaret fördelats mellan olika myndigheter. Även genom geodatasamverkan förbinder sig parterna att ta ansvar för vissa geodata. En utvidgning av detta ansvar skulle öka möjligheten för bra webbkartografisk sampresentation. Riktlinje: De informationsansvariga bör i möjligaste mån stämma av dessa val med varandra. Samordning är alltså önskvärd genom geodatasamverkan eller standardiseringen. Riktlinje: De informationsansvariga bör publicera sina färger och symboler. Publicering kan göras centralt eller som separata rapporter som i fallet med Riktlinjer för webbkartografi inom krishantering. Riktlinje: Valen bör vara medvetna ställningstaganden grundade på tradition och logik. I praktiken innebär det att man inte bör ta lättvindigt på valet. I många fall finns en kartografisk tradition att falla tillbaka på. Med logik avses t.ex. att symboler för likartade företeelser bör ha ett likartat utseende. 3.4 Teknik Riktlinje: Webbkarttjänster bör uppfylla kraven i Tekniskt ramverk. Tekniskt ramverk för en infrastruktur för geodata[10] (se även 4.1) anger ett antal krav på "WMS:er som görs åtkomliga i den svenska infrastrukturen och via Geodataportalen". Dessa krav är en skärpning av de krav som Inspires specifikationer ställer. 3.5 Alternativa kartskikt Riktlinje: Webbkarttjänsten bör erbjuda alternativa kartskikt för presentation av en objekttyp. I praktiken innebär detta alternativa stilmallar att välja på för varje geodatalager. Applikationsdesignern kan då välja det kartskikt som bäst kan kombineras med vald bakgrundskarta och andra kartskikt. 12

13 Riktlinje: Varje valbart kartskikt bör presentera få och samhörande objekttyper. Applikationsdesignern kan då välja ut de objekttyper som är relevanta för tillämpningen och göra det möjligt för användaren av webbkartan att välja information. I praktiken kan detta lösas genom att det angivna geodatalagret innehåller de aktuella objekttyperna eller att den angivna stilmallen endast visar de aktuella objekttyperna. Med få objekttyper i datalagret kan samma stil användas för många objekttyper. Exempel på innehåll i kartskikt: Mobilmaster (en objekttyp), snarare än master av alla typer. Kommungränser (en objekttyp), snarare än administrativa gränser. Skyddsområden av olika klass (flera objekttyper som inte är överlappande) Riktlinje: Kartskikt bör erbjudas så att det är möjligt att ha såväl ett mörkt ortofoto som en ljus nedtonad karta som bakgrundsskikt. Detta medför att det i många fall måste finnas minst två alternativa sätt att presentera en objekttyp. 3.6 Objektinformation Riktlinje: Information om presenterade objekt bör kunna hämtas med WMS-anropet GetFeatureInfo. Tekniskt ramverk kräver också detta. Riktlinje: Information hämtad med WMS-anropet GetFeatureInfo bör ha XML-format. Tekniskt ramverk kräver HTML-format. XML-formatet bör vara dokumenterat. Riktlinje: Information hämtad med WMS-anropet GetFeatureInfo bör finnas på svenska. XML-format möjliggör information på flera språk. 3.7 Texter i kartan Riktlinje: Texter bör hanteras som ett separat kartskikt. Texter är antingen ett attribut till en objekttyp eller en egen objekttyp med ett läge på marken. Genom att texterna finns i ett eget kartskikt ökar möjligheterna till presentation. Riktlinje: Texter bör finnas i alternativt utförande vad gäller storlek och färg. Riktlinje: Texter bör finnas somalternativ där olika strategi har använts för urval och placering Skalintervall Riktlinje: Samma indelning i skalintervall bör användas i alla kartskikt. Symboliseringen kan förändras mellan två skalintervall men inte inom ett. Genom att ha samma indelning i skalintervall kommer symboliseringen att förändras på ett förutbestämt sätt. Vilka skalintervall som bör användas bör beskrivas som en riktlinje.om möjligt bör den baseras på internationella riktlinjer. 13

14 TK 570 N Bakgrundsskikt Bakgrundskartans uppgift är att vara ett orienterande stöd till en karta vars huvudsakliga syfte är att presentera tematisk information. Den ska vara utformad så att den inte stör utan hellre förhöjer visualiseringen av temat. Vad som ska finnas med i en bakgrundskarta beror till stor del av vad kartan som helhet vill visa. Generellt brukar strandlinjer, infrastruktur och bebyggelse vara viktiga för att man ska kunna orientera sig geografiskt. Administrativ indelning såsom läns- och kommungränser är ett bra stöd i mindre skalor. Förtydligande karttext ger ett extra stöd för orienteringen. Riktlinje: Kartskikt som ska användas som bakgrundskarta bör finnas i en nedtonad variant. En bakgrundskarta med nedtonade färger ger ett större utrymme för den tematiska informationen att lyftas fram än vad en färglagd karta gör. En helt gråtonad bakgrund ger mest utrymme för överlagrad färgad information, men å andra sidan gör den det svårare att särskilja objekt med liknande symbolisering. Riktlinje: Kartskikt som ska användas som bakgrundskarta bör finnas i en detaljfattig variant. Det är inte alla teman som störs av en färglagd bakgrundskarta. Däremot kan en för detaljerad bakgrund vara störande varför möjligheten att kunna styra innehållet är en fördel. Riktlinje: Detaljer i bakgrundskartan bör kunna framhävas. Vissa objekttyper i bakgrundskartan bör finnas att tillgå som separata kartskikt. Då kan man skapa en nedtonad bakgrundskarta där vissa detaljer, som t.ex. större vägar eller gränser framhävs, se Punktsymbolisering Riktlinjer bör tas fram Linjesymbolisering Riktlinjer bör tas fram Ytsymbolisering Riktlinjer bör tas fram Tjänstespecifikation En tjänstespecifikation definieras som en beskrivning av en tjänst med syfte att göra det möjlig att konsumera tjänsten och nyttja dess förmågor samt ställa krav på dess kvalitet och prestationer. Exempel på hur en tjänstespecifikation kan utformas finns i 7. Gränssnittet är en viktig del av tjänstespecifikationen. För webbkarttjänster beskrivs det i WMS-standarden. En annan del är vad man kan göra med tjänsten. För webbkarttjänster innebär det bl.a. vilken förmåga tjänsten har att tillhandahålla olika kartskikt, beskrivna till informationsinnehåll och utseende. WMS-anropet GetCapabilities ger ett kortfattat och formaliserat svar om detta. Åtkomst av kartskikt från en WMS-baserad webbkarttjänst görs genom WMS-anropet GetMap. I anropet specificeras namnet på ett eller flera geodatalager och namnet på den stilmall som ska användas för respektive geodatalager. För själva kartskiktet finns alltså inget namn. Detaljer om detta beskrivs i 4. Riktlinje: Giltiga kombinationer av geodatalager och stilmallar bör beskrivas på följande sätt: För varje geodatalager bör följande uppgifter anges: 14

15 Datalagrets namn, så som det ska anges i WMS-anropet GetMap. Datalagrets titel, så som den kommer att presenteras i en applikation. En kort beskrivning av datalagrets innehåll, alltså vilka objekttyper som ingår. Inom vilka skalintervall som geodatalagret är synligt. De stilmallar som erbjuds för datalagret. För varje stilmall ska följande uppgifter finnas: o Stilmallens namn, så som det ska anges i WMS-anropet GetMap. o Stilmallens titel, så som den kommer att presenteras i en applikation. o En kort beskrivning av vad som utmärker stilmallen. o Beskrivning av kartskiktets innehåll, t.ex. vilka objekttyper som visas, om detta avviker från datalagrets alla objekttyper. o Rekommenderade skalintervall för kartskiktet. o En exempelbild som illustrerar geodatalagret med aktuell stilmall. o En teckenförklaring som illustrerar hur de olika objekttyperna är symboliserade. Om urvalet och symboliseringen varierar beroende på visningsskala bör detta framgå av teckenförklaringen. Riktlinje: Giltiga värden bör anges för övriga parametrar i WMS-anropet GetMap. De grundläggande parametrarna är följande: VERSION: Vilka versioner av WMS som tjänsten erbjuder. LAYERS: Namn på de geodatalager som tjänsten erbjuder presentation av alt. hänvisning till information ovan. STYLE: Namn på de stilmallar som tjänsten erbjuder alt. hänvisning till information ovan. BBOX: Det geografiska område som täcks av tjänsten. Antingen verbalt, t.ex. Stockholms län, eller min-max-koordinater i ett angivet koordinatsystem. I anropet till tjänsten måste en ruta med koordinater anges men som information kan tjänstens innehåll beskrivas verbalt. SRS: De referenssystem som stöds av tjänsten. I anrop till tjänsten anges EPSGs id-kod för valt system. I beskrivningen är ett förtydligande av vilket namn systemet har till stor hjälp. WIDTH: Maximal antal pixlar i en begärd bilds bredd. HEIGTH: Maximal antal pixlar i en begärd bilds höjd. FORMAT: De bildformat som tjänsten erbjuder. 15

16 TK 570 N Bilaga: Tekniska möjligheter och begränsningar 4.1 Inledning I detta avsnitt beskrivs de tekniska möjligheterna och begränsningarna som finns vid kartografisk utformning av webbkartor. Dessa möjligheter och begränsningar beror givetvis på vilken teknisk miljö man arbetar med. Det finns ingen möjlighet att här gå igenom detaljer om olika tekniska miljöer. I stället kommer vi att göra en generell beskrivning av tekniska möjligheter och begränsningar. Beskrivningen utgår från att standarder från Open Geospatial Consortium (OGC)[1] används. OGC är ett internationellt konsortium som arbetar för utveckling och genomförande av öppna standarder inom geografisk information. Standarderna beskriver gränssnitt för att göra geografiska data och tjänster interoperabla. Avsnittet har följande struktur. Vi inleder med att beskriva en generell systemarkitektur i avsnitt 4.2. I arkitekturen har vi utgått från att man använder en kartapplikation som kan få sin kartinformation från en: applikationsserver, kartbildserver, kartserver, geodataserver eller en lokal databas. I de fem följande avsnitten i avsnittet, 4.3 till 4.7 behandlas kartografiska aspekter på de olika komponenterna i systemarkitekturen. Syftet med denna beskrivning är att ge en översiktlig beskrivning av vilka tekniska möjligheter det finns att påverka den kartografiska utformningen. För att öka möjligheten för användare att påverka den kartografiska utformningen har OGC skapat språk för symbolutformning: Styled Layer Descriptor (SLD)[2] och Symbology Encoding (SE)[3]. Dessa beskrivs i avsnitt Generell systemarkitektur Figur 3 visar en generell systemarkitektur för webbkartor. Slutanvändaren använder kartapplikationen som visar en sammansatt kartbild från en eller flera servrar. Vi har här förutsatt att kommunikationen mellan kartapplikationen och servrarna sker med OGC standarderna Web Map Service (WMS)[4], Web Map Tile Service (WMTS)[6] och Web Feature Service (WFS)[7] eventuellt kompletterade med standarder för symbolutformning (Tabell 1). Vi inleder beskrivningen av systemarkitekturen i Figur 3 nerifrån. En geodataserver tillgängliggör geodata (oftast i form av en GML-fil) med hjälp av en nedladdningstjänst (Web Feature Service, WFS). Dessa data kan användas direkt i kartapplikationen. Vanligtvis sker detta genom att data hämtas hem och lagras i en lokal databas före användning, men det går även att hämta hem data i realtid via en nedladdningstjänst. En kartserver skapar vanligen en karta i form av en rasterbild (t.ex. PNG, jpeg eller GIF) men kan också använda vektorgrafik (t.ex. Scalable Vector Graphics, SVG[8]). För att skapa dessa kartbilder använder kartservern antingen geodata lagrade lokalt på servern eller så hämtas geodata i realtid från en nedladdningstjänst. En kartserver tillgängliggör sina kartdata via en visningstjänst (Web Map Service, WMS). En nackdel, ur ett prestandaperspektiv, med WMS-tekniken är att alla kartskikt måste genereras i realtid. För att öka prestandan kan man förgenerera kartskikt och lagra dem i en kartbildserver. I praktiken indelas kartskiktet i ett rutnät och det skapas en kartbild för varje ruta (på engelska kallas dessa förgenererade kartbilder för tiles). OGC har tagit fram en standard, Web Map Tile Service (WMTS), som specificerar hur en klient kan hämta dessa förgenererade kartbilder från en kartbildserver. Kartbildsservrar används ofta för bakgrundskartor. Applikationsservern skapar en karttjänst (sammansatt kartbild) utifrån en eller flera kartbilder. Kartbilderna kan lagras antingen lokalt eller hämtas i realtid via visningstjänster eller nedladdningstjänster; i det senare fallet måste geodata symboliseras till en kartbild i applikationsservern. 16

17 Figur 3 - Generell systemarkitektur för webbkartor Tabell 1 - Tjänster för geodata och kartografiska data. Typ av server Typ av tjänst Levererar data av typ OGC-standard Geodataserver Nedladdningstjänst Geodata i vektorformat WFS Kartserver Visningstjänst Kartskikt i raster- eller vektorgrafikformat Kartbildserver Visningstjänst Förgenererade kartskikt i rasterformat WMS WMTS Applikationsserver Webbkartapplikation En applikation anpassad för att användas i en webbläsare 4.3 Kartografiska aspekter på geodataservern En geodataserver som t.ex. WFS, levererar endast geodata vilka i sig inte har någon kartografisk utformning. För att dessa geodata ska kunna presenteras så måste det ske en symbolisering av data i ett senare led (antingen lokalt i kartapplikationen eller t.ex. i en kartserver). 17

18 TK 570 N Kartografiska aspekter på kartservern En kartserver är en typ av visningstjänst, dvs. den ger möjligheten för en användare att beställa en kartbild. För att få en bild av hur användaren kan påverka den kartografiska utformningen görs här en kortfattad beskrivning av OGC-standarden Web Map Service (WMS) ur ett kartografiskt perspektiv. Det finns två obligatoriska typer av anrop i WMS: GetCapabilities och GetMap (se Figur 4). Med hjälp av GetCapabilities får klienten metadata om de kartskikt som kan erhållas; bland annat finns information om vilka symboliseringar som finns tillgängliga. Ett GetMap-anrop är en förfrågan om en kartbild. Anropet innehåller parametrar som specificerar: version av WMS (VERSION, obligatoriskt) typ av begäran (REQUEST, obligatoriskt) lista över geodatalager som ska användas för kartskikt i kartbilden (LAYERS, obligatoriskt) lista över stilmallar, alltså specifikation av vilken symbolisering som ska användas (STYLES, obligatoriskt) geodetiskt referenssystem och kartprojektion (CRS, obligatoriskt) utsträckning av kartbilden (BBOX, obligatoriskt) beskrivning av hur kartbilden ska levereras (storlek WIDTH och HEIGHT; filformat FORMAT) Dessa parametrar specificeras som CGI-parametrar i en begäran. Ett fiktivt exempel på ett GetMap-anrop är: buildings,roads,water&styles=normal,normal,normal,normal&crs=epsg:4326&bbox=9.0,45.0,25.0,61.0 &WIDTH=800&HEIGHT=800&FORMAT=image/png WMS specificerar också ett icke-obligatorisk anrop GetFeatureInfo som används för att fråga efter attributdata. Figur 4 - Kommunikation mellan en WMS-klient och en WMS-server. Följande är viktigt i WMS-standarden ur ett kartografiskt perspektiv: Geodatalagrens ordningsföljd i GetMap-anropet avgör ritordningen hos kartskikten. Det innebär bland annat att polygoner vanligtvis ska listas före linjer och punkter, annars kommer polygonerna att täcka linjerna och punkterna i kartbilden. Det är en en-till-en-relation mellan geodatalager (LAYER) och stilmallar (STYLES). Det första geodatalagret i LAYERS-listan återges med den första stilmallen i STYLES-listan och så vidare. Om man vill använda default-stilmallen kan parametern lämnas tom (STYLES =). Det är dock inte enkelt 18

19 för användaren att veta vilken stilmall som är satt till default eftersom detta inte ges av listningen av stilmallar i svaret på GetCapabilities-anropet. Därför bör man alltid specificera vilken stilmall som ska användas. 4.5 Kartografiska aspekter på kartbildservern En kartbildserver har begränsningar ut ett kartografiskt perspektiv. Användaren kan inte välja mellan olika symboliseringar utan är begränsad till den symbolisering som användes vid förgenereringen av kartbilderna (dock är det givetvis möjligt att de som sätter upp tjänsten skapar flera olika kartbildstjänster med olika symbolisering). Vidare kan det vara svårt för de som skapar en kartbildstjänst att få till en bra textsättning i skarvarna mellan de olika bilderna (i praktiken används överlappande bilder för att lösa detta). 4.6 Kartografiska aspekter på applikationsservern En applikationsserver skapar en webbkartapplikation som ofta innehåller en sammansatt kartbild av ett eller flera tematiska kartskikt och en bakgrundskarta. Svårigheten här är att få en bra kartografisk lösning för den sammansatta kartbilden. I de fall då alla data lagras lokalt på applikationsservern har den som sätter upp applikationen bra möjligheter att själv skapa den kartografiska utformningen. Vi går dock mot alltmer tjänstebaserade system där den kartografiska utmaningen är större. I detta fall är den som designar applikationen begränsad till de symboliseringar som finns tillgängliga hos kart- och kartbildsservrarna (om inte man använder en kartserver som tillåter SLD, se 4.8). Den som använder webbkartapplikationen ges vanligen inga större kartografiska möjligheter. Möjligheterna är ofta endast på nivån att välja vilka lager som ska visas. 4.7 Kartografiska aspekter på kartapplikationen De kartografiska möjligheterna i kartapplikationen beror till stor del på varifrån data hämtas. I de fall geodata ligger lokalt på datorn (eller i ett lokalt nätverk) finns det stora möjligheter att påverka symboliseringen. I de fall då data hämtas från visningstjänster är användaren av kartapplikationen beroende av vilka kartografiska möjligheter som producenterna av dessa tjänster har satt upp och vilken typ av kartapplikation som används. Vissa applikationer är enkla och tillåter inte ändring av symboliseringen (t.ex. enkla webbklienter) medan andra applikationer ger stora möjligheter till egen kartografisk utformning (t.ex. GIS-program). 4.8 Standardiserade språk för symbolutformning Ur ett kartografiskt perspektiv är det viktigt att ge möjligheter till den som sätter upp en tjänst (alternativt för slutanvändaren) att tillhandahålla bra verktyg för kartografisk utformning. Ett problem för dem som använder flera visningstjänster är att tjänsterna inte är utformade för sampresentation. För detta krävs t.ex. möjligheter för den som sätter upp en applikationsserver att kunna vara med och påverka den kartografiska utformningen i de kartservrar som används, dvs. att kunna påverka vilka stilmallar (STYLE) som ska finnas för varje geodatalager (LAYER). För att möjliggöra detta definierade OGC språket Styled Layer Descriptor (SLD). Version 1.0 av SLD innehåller både möjlighet att specificera stilmallar och möjlighet att knyta geodatalager till stilmall. Under 2007 delades SLD upp i två standarder: Symbology Encoding (SE) som definierar utseendet på en stilmall och Styled Layer Descriptor Profile of the Web Map Service Implementation Specification (SLD version 1.1.0) som definierar vilken stilmall som respektive geodatalager ska använda. Rent tekniskt är det ett protokoll för kommunikation mellan en WMS-tjänst och ett SE-dokument. Beskrivningen nedan använder SE och SLD version Beskrivningen ges utifrån ett förenklat exempel (baserat på Olsson 2011[]). För den som är intresserad av detaljer om SLD/SE hänvisas till specifikationerna på OGCs webbplats[]. Anta att följande stilar har definierats i WMS-servern: BlackRectangle för lagret Buildings, och Border och CenterLine för lagret Roads. Då kan följande GetMap-anrop göras för att skapa kartan i Figur 5: STYLES=Border,CenterLine,BlackRectangle 19

20 TK 570 N0047 Figur 5 - En karta (nederst) som byggs upp av lager enligt GetMap-anropet ovan. Genom att använda SLD-kod får man en förbättrad möjlighet att skapa de LAYER-STYLE-par som definieras i ett GetMap-anrop. Denna SLD-kod kan antingen ligga externt alternativt inkluderas i GetMap-anropet. Ett exempel är följande: <StyledLayerDescriptor version="1.1.0"> <NamedLayer> <Name>roads</Name> <NamedStyle> <Name>Border</Name> </NamedStyle> </NamedLayer> <NamedLayer> <Name>roads</Name> <NamedStyle> <Name>CenterLine</Name> </NamedStyle> </NamedLayer> <NamedLayer> <Name>buildings</Name> <NamedStyle> <Name>Buildings</Name> </NamedStyle> </NamedLayer> </StyledLayerDescriptor> SLD-koden ovan kräver i sin tur att det finns en SE-beskrivning av själva stilarna, exempelvis: <LineSymbolizer> <Name>Border</Name> <Stroke> <SvgParameter name="stroke">#ff0000</svgparameter> <SvgParameter name="stroke-width">5</svgparameter> </Stroke> </LineSymbolizer> <LineSymbolizer> <Name>CenterLine</Name> <Stroke> <SvgParameter name="stroke">#ffff00</svgparameter> <SvgParameter name="stroke-width">3</svgparameter> </Stroke> </LineSymbolizer> <PolygonSymbolizer> <Name>Buildings</Name> <Stroke> <SvgParameter name="stroke">#000000</svgparameter> </Stroke> </PolygonSymbolizer> 20

21 5 Bilaga: Bakgrundskartor 5.1 Inledning Bakgrundskartans uppgift är att vara ett orienterande stöd till en karta vars huvudsakliga syfte är att presentera tematisk information. Den ska vara utformad så att den inte stör utan hellre förhöjer visualiseringen av temat. Vad som ska finnas med i en bakgrundskarta beror till stor del av vad kartan som helhet vill visa. Generellt brukar infrastruktur och bebyggelse vara viktiga för att man ska kunna orientera sig geografiskt. Administrativ indelning såsom läns- och kommungränser är ett bra stöd i mindre skalor. Förtydligande karttext ger ett extra stöd för orienteringen. I en generell bakgrundskarta bör det i någon utsträckning vara möjligt att kunna välja vilken information man vill ha med. 5.2 Kartografi för bakgrundskartor Figur 6 En bakgrundskarta med nedtonade färger ger ett större utrymme för den tematiska informationen att lyftas fram än vad en färglagd karta gör. En helt gråtonad bakgrund ger mest utrymme för överlagrad färgad information, men å andra sidan gör den det svårare att särskilja objekt med liknande symbolisering. Det är inte alla teman som störs av en färglagd bakgrundskarta. Däremot kan en för detaljerad bakgrund vara störande varför möjligheten att kunna styra innehållet är en fördel. 21

22 TK 570 N0047 Figur Lyfta fram viktig information i bakgrundskartor I vissa fall kan bakgrundskartan även ha ett annat än enbart en orienterande funktion. I de fall har innehållet i kartan en roll som referens till något som är viktigt för temat. Som exempel kan nämnas väg- och gatunät då transporter av olika slag utgör temat. Ett annat fall kan vara i en krissituation där temat är det olycksdrabbade området och det är viktigt att veta hur man tar sig dit eller undviker att passera just där. Andra exempel på referensobjekt är bebyggelse och höjdinformation. 22

23 Figur 8 23

24 TK 570 N Bilaga: Kartografi för tematiska skikt vid sampresentation av kartskikt 6.1 Introduktion I detta avsnitt beskrivs några kartografiska metoder för sampresentation av kartskikt. Syftet är inte att ge en allmän kartografisk beskrivning; för en sådan hänvisas till HMK-kartografi eller läroböcker i kartografi. Beskrivningen nedan kommer att koncentrera sig på några viktiga kartografiska frågeställningar som behandlar kombination av två eller flera visningstjänster. I typfallet används en visningstjänst som innehåller ett bakgrundsskikt och minst en tjänst som innehåller tematisk information (som ska placeras visuellt ovanpå bakgrundsskiktet). I detta avsnitt kommer vi endast att göra en beskrivning av kartografi för de tematiska skikten. Dock är de kartografiska rekommendationerna för de tematiska skikten avhängiga bakrundsskiktet. Följande typer av bakgrundsskikt används: - bakgrundskarta i färg - bakgrundskarta i gråskala - bakgrundsbild. Observera att ett bakgrundsskikt kan indelas i flera kartskikt vilket är lämpligt om man vill lyfta fram vissa teman i en bakgrundskarta (jfr Figur 8). Informationen i de tematiska kartskikten indelas i två grupper: symboliserade geodataobjekt och beskrivande data. För symboliserade geodataobjekt är presentationen bestämd som t.ex. linjebredd och färg. Dessa geodataobjekt indelas i ytobjekt, linjeobjekt och punktobjekt. Beskrivande data är attributdata som hör till geodataobjekten som presenteras i kartan. De två typer av beskrivande data som beskrivs nedan är texter och ikoner. 6.2 Utvärderingskriterier Nedan ges exempel på kartografiska lösningar för de tematiska kartskikten ovanpå ett bakgrundsskikt. Föroch nackdelar med lösningarna diskuteras utifrån ett antal utvärderingskriterier som listas nedan. Observera att kriterierna är formulerade utifrån att varje tematisk kartskikt kan innehålla en eller flera tematiska kategorier. 1) Begriplighet - Hur intuitiv är presentationen? Behövs teckenförklaring eller liknande? - Är det enkelt att särskilja presentation av olika tematiska kategorier? - Det ska vara enkelt att avgöra vad som är innanför respektive utanför en tematisk polygon. 2) Läsbarhet - Mängden information per ytenhet får inte vara så stor på skärmen att det inte går att särskilja information. - Kontrast mellan presentation av tematiska kategorier och bakgrundskartan. Denna kontrast inbegriper både färgskillnader och geometriska metoder. - De tematiska kartskikten ska gå att läsa oberoende vad bakgrundsskiktet visar, dvs. läsbarheten ska vara oberoende av bakgrundsinformationen. - Det ska gå att presentera alla kombinationer av tematiska kategorier. 3) Klarar av ett stort skalomfång - Presentationen av tematiska kategorier ska fungera när man zoomar in/ut i kartan. 4) Informationsförlust - Döljer det tematiska kartskiktet viktig information i bakgrundskartan. - Döljer det tematiska kartskiktet annan viktig tematisk information. 5) Associativa egenskaper - Är det enkelt att se att symboler/områden är av samma typ även om de befinner sig på långt avstånd från varandra. 6) Tematiskt djup och tematisk gruppering 24

25 - Hur många tematiska kategorier kan särskiljas i presentationsmetoden? - Stödjer presentationsmetoden gruppering av tematiska kategorier? 7) Del av färgrymden - Om symboliseringen av de tematiska kartskikten tar en alltför stor del av färgrymden fås litet utrymme av färgrymd till bakgrundskartan. 6.3 Sampresentation av bakgrundsskikt och tematiska skikt med ytgeometri Problemställning Utmaningen med att presentera tematisk information i form av ytgeometrier är främst att visualisera olika objekttyper som områden som kan överlappa varandra och samtidigt kunna utläsa områdenas gränser, vad som är innanför och utanför ett område och vilken objekttyp som avses Prickrastrering Lösningen innebär att varje objekttyp symboliseras med en kombination av ett prickraster med viss färg och täthet och en kantlinje av viss färg och grad. Fördelar: En objekttyp kan ha samma symbolisering vid olika skalor. Det är lätt att avgöra vad som är innanför och utanför området. Nackdelar: Kartan upplevs som rörig och brusig. Exempel: Figur 9 25

26 TK 570 N Transparens Lösningen innebär att varje objekttyp symboliseras med en kombination av en viss färg med viss transparens och en konturlinjelinje av viss färg och grad. Fördelar: En objekttyp kan ha samma symbolisering vid olika skalor. Det är lätt att avgöra vad som är innanför och utanför området. Informationen i bakgrundskartan framträder tydligt. Nackdelar: Nya färger skapas när områden överlappar varandra. Det är svårt att utläsa vilken objekttyp som avses. Exempel: Tvåskiktslinje som konturlinje Figur 10 Detta innebär att varje objekttyp symboliseras med ett område med en konturlinje som utgörs av en tvåskiktslinje där en viss färg markerar utsidan och en viss färg markerar insidan av området. Fördelar: Kartan blir renare och mindre brusig. Informationen i bakgrundskartan framträder tydligt. Nackdelar: Symboliseringen blir skalberoende. Det är svårt att avgöra vad som är innanför och utanför området. 26

27 6.3.5 Linjerastrering i olika riktningar Lösningen innebär att varje objekttyp symboliseras med ett linjeraster med viss täthet och grad Linjerastrering med olika färger Lösningen innebär att varje objekttyp symboliseras med ett linjeraster med viss färg där färgerna skiljer sig tillräckligt mycket åt. 6.4 Sampresentation av bakgrundskartor och tematiska skikt med linjegeometri Problemställning Problemet är att visualisera olika objekttyper som linjesymboler med hög läsbarhet oberoende av vilken bakgrundskarta de presenteras på. Ytterligare en svårighet är att visualisera två linjer som går parallellt med varandra (och överlappar) Tvåskiktslinje Lösningen innebär att varje objekttyp symboliseras med en tvåskiktslinje med en färg som inte förekommer i bakgrundskartan. Fördelar: Det är en enkel lösning. Nackdelar: Inga Halvtransparant linje Streckad (alternativt punktstreckad) linje 6.5 Sampresentation av bakgrundskartor och tematiska skikt med punktgeometri Problemställning En utmaning med visualisering av tematisk punktinformation är att intuitivt kunna tolka kartan. Det är viktigt att punktsymbolerna är lagom stora och att det går att särskilja, och i förekommande fall gruppera, informationen Använda grafiska variabeln färg för att särskilja punkter Använda grafiska variabeln storlek för att särskilja punkter Använda grafiska variabeln form för att särskilja punkter 6.6 Sampresentation av bakgrundskartor och tematiska skikt med skilda geometrityper Problemställning En svårighet med att visualisera tematisk information med skilda geometrityper är att de olika lagren stör varandra. Ett typfall är att visualisera en tematisk linje ovanpå en linjerastrerad yta. 6.7 Sampresentation av bakgrundskartor och beskrivande data 27

28 TK 570 N Bilaga: Exempel på teknisk beskrivning Den tekniska beskrivningen innehåller information som i första hand riktar sig till den som utvecklar applikationer där tjänsten används. Den tekniska beskrivningen ska innehålla information om URL till tjänstens åtkomstpunkt. EXEMPEL 1 EXEMPEL 2 Den tekniska beskrivningen kompletteras lämpligen med exempel på anrop (för begäran om tjänstens förmågor, GetCapabilities). Exemplet bör direkt kunna kopieras och användas i en applikation. EXEMPEL 3 EXEMPEL 4 Namn Titel Beskrivning fastighetsgranser Fastighetsgränser Fastighets-, trakt-, kommun-, läns- och riksgränser ljus_bakgrund En stil för ljus bakgrund Heldragna rödbruna linjer med olika linjebredd mork_bakgrund En stil för mörk bakgrund Heldragna gula linjer med olika linjebredd Giltiga värden för grundläggande parametrar för ett GetCapabilities-anrop o Versionsnummer, som är den enda parameter i GetCapabilities-anropet där alternativa värden kan förekomma. De möjliga, giltiga värdena ska vara angivna. EXEMPEL 5 Namn Beskrivning Giltiga värden VERSION=version WMS-version Anrop EXEMPEL 6 Namn Beskrivning Giltiga värden VERSION=version WMS-version LAYERS=lagerlista Kommaseparerad lista Se giltiga lagernamn ovan STYLE= stillista Kommaseparerad lista Se giltiga stilnamn ovan. Listan ska vara synkroniserad med lagerlistan. En stil per lager och i samma ordning. BBOX=emin,nmin, emax, nmax Geografisk utbredning i angivet referenssystem Inom Sveriges riks- och territorialgräns: , , , Koordinater angivna i SWEREF 99 TM SRS=EPSG:id-kod Referenssystem EPSG:4326 (WGS84) EPSG:4619 (SWEREF99) EPSG:3006 (SWEREF99 TM) WIDTH=bredd Resultatbildens bredd i pixlar 0 < antal pixlar < 4097 HEIGHT=höjd Resultatbildens höjd i pixlar 0 < antal pixlar < 4097 FORMAT=bildformat Resultatbildens filformat image/png image/jpeg image/gif Anrop ht=512&bbox=580000, ,580512, &layers=granser,text&style=mork_bakgrund,m ork_bakgrund&format=image/png&srs=epsg:3006&exceptions=application/vnd.ogc.se_xml 28

29 Litteraturförteckning [1] Open Geospatial Consortium (OGC), [2] Styled Layer Descriptor (SLD), [3] Symbology Encoding (SE), [4] Web Map Service (WMS), [5] SS-EN ISO 19128, Geografisk information - Web Map Service (WMS) [6] Web Map Tile Service (WMTS), [7] Web Feature Service (WFS), [8] Scalable Vector Graphics (SVG), [9] Riktlinjer för nationellt genomförande av Inspire Visningstjänster, [10] TEKNISKT RAMVERK Version 2.0, [11] Lagen (2010:1767) om geografisk miljöinformation, Lagar/Lagar/Svenskforfattningssamling/Lag om-geografisk-_sfs / [12] Vad är en tjänst? Begrepp för tjänster inom e-förvaltnings- och geodataområdet, Stanli 2013, 29