Implementation av en infrastruktur för geodata CHRISTOFER ÖSTERBERG Examensarbete Stockholm, Sverige 2009
Implementation av en infrastruktur för geodata CHRISTOFER ÖSTERBERG Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2009 Handledare på CSC var Kjell Lindqvist Examinator var Stefan Arnborg TRITA-CSC-E 2009:082 ISRN-KTH/CSC/E--09/082--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.csc.kth.se
Sammanfattning EG-direktivet Inspire ligger till grund för den strategi gällande geografisk data som håller på att implementeras i Sverige idag. Syftet med Inspire är att göra geografisk data mer tillgänglig och mer aktuell med hjälp av publicering via webbtjänster, vilket bildar en infrastruktur för geodata. Detta examensarbete har undersökt vad som krävs av dessa serverbaserade karttjänster för att göra de användbara för tjänsternas konsumenter, speciellt när man arbetar med tjänster från flera olika leverantörer samtidigt, vilket jag anser är viktigt att ta hänsyn till som tjänsteleverantör. Fokusområdena som valts ut och analyserats är kartografisk samordning, prestanda samt tillgänglighet hos dessa webbtjänster. Infrastrukturens användningsområden kommer förmodligen att bli många i framtiden vilket innebär att en lyckad implementation bygger på att systemet är flexibelt och effektivt samtidigt som det är framtidssäkert nog för att fungera även för morgondagens konsumenters krav. Något som jag har funnit är ett betydande problemområde inom den kartografiska samordningen är att det saknas en strategi för hur man ska sköta samordningen av hur geodata ska visualiseras. För att man ska kunna kombinera kartor ifrån olika leverantörer och placera dessa i lager ovanpå varandra krävs möjlighet att påverka visualiseringen för att geodata ska passa in i sitt sammanhang. Konsumentens behov kan variera beroende på vilket tillämpningsområde eller sammanhang som kartan ska användas i eller vilken plattform som konsumenten använder och därmed hur mycket generalisering som krävs. Leverantören av geodata och stilmallar kommer i framtiden heller inte alltid att vara densamma och därför är det viktigt att det finns ett semantiskt gränssnitt för att dessa ska kunna kopplas ihop. Implementation of a Spatial Data Infrastructure Abstract The EC initiative INSPIRE is the basis of the strategy for geographic data that is being implemented in Sweden today. The aim of INSPIRE is to make geographic data more available and up to date by publishing them via web services which form a spatial data infrastructure. This master thesis has examined what is required of these server-based map services to make the service useful for consumers, especially when combining services from different providers in a mashup, which I consider important to take into account as a service provider. Focus areas that are selected and analyzed are the portrayal consistency, performance and availability of these services. The infrastructure s application areas will probably be many in the future, so a successful implementation is based on the system that is flexible and efficient while being future-proof enough to serve also for tomorrow's consumer demands. An important issue which I have analyzed about the portrayal consistency is the lack of a strategy for how to manage the coordination of how the geodata should be visualized. In order to combine maps from different providers and place them in layers on top of each other it must be possible to influence the visualization of geodata to make it fit into the context. The consumer's needs may vary with the scope or context in which the map should be used or the platform that the consumer uses and therefore how much generalization needed. The provider of geodata and stylesheets in the future will not always be the same; therefore, it is important that a semantic interface exists for these to be linked.
Förord Detta examensarbete utfördes våren 2009 vid CSC, KTH med Sweco Position AB som uppdragsgivare. Sweco Position AB arbetar inom geografisk IT och har under den senaste tiden uppmärksammat ett ökat intresse för publicering av geodata i form av webbtjänster kopplat till EGdirektivet Inspire. Eftersom jag fann detta område mycket intressant utformade vi tillsammans frågeställningarna som syftar till att ta reda på hur en implementation av Inspire fungerar i praktiken. Ett antal fokusområden som enligt mig anses vara kritiska framgångsfaktorer valdes ut och dessa analyserades sedan för att leda fram till resultat, slutsatser och rekommendationer för det fortsatta arbetet med att implementera en infrastruktur för geodata. Jag som utfört detta examensarbete vill tacka min handledare på Sweco Position, Niklas Ringdahl och även Mats Dahl, Chi-Hao Poon, Gabriel Hirsch och alla andra på Position-kontoret i Stockholm för stöd och hjälp under mitt arbete. Jag vill också tacka Kjell Lindqvist, min handledare på CSC, och Anders Söderman på GISAssistans som har bidragit med mycket bra hjälp i form av idéer och återkoppling. Jag vill också tacka Kjell Hjorth i geodataprojektet som tagit sig tid att svara på frågor vid flera tillfällen.
Innehållsförteckning 1 Problembeskrivning... 1 1.1 Syfte... 1 1.2 Avgränsning... 1 1.3 Disposition... 2 2 Metodbeskrivning... 3 2.1 Förstudie och undersökning... 3 2.2 Prototyp och testning... 3 2.3 Analys av resultat... 3 3 Bakgrund... 4 3.1 Geodata... 4 3.2 Inspire... 4 3.3 Nationell geodatastrategi... 5 3.4 Intressenter... 5 3.4.1 Samordnare... 5 3.4.2 Leverantörer... 6 3.4.3 Konsumenter... 6 3.4.4 Angränsande projekt... 6 4 Tekniken... 7 4.1 Tjänsteorienterad arkitektur... 7 4.2 Webbtjänster för geodata... 7 4.3 Kartserver... 8 4.4 Kartklient... 9 4.5 Projektets testmiljö... 9 5 Analys av fokusområden... 10 5.1 Kartografisk samordning... 10 5.1.1 Styled Layer Descriptor... 11 5.1.2 Standardiserad kartografi... 17 5.1.3 Semantiska modeller... 17 5.1.4 Stilmallar för olika tillämpningar... 18 5.1.5 En samordnad strategi... 18 5.2 Prestanda... 20 5.2.1 Testerna... 21 5.2.2 Analys av testresultat... 21 5.2.3 Faktorer som påverkar prestanda... 25 5.3 Tillgänglighet... 27
5.3.1 Åtgärder hos tjänsteleverantören... 27 5.3.2 Åtgärder hos tjänstekonsumenten... 28 5.3.3 Tjänstenivåavtal... 30 6 Resultat och slutsats... 31 Referenser... 33 Bilagor... 38 Prototyp av webbklient för visningstjänster... 38 SLD-exempel... 41
Ordlista Tabell 1: Här förklaras de akronymer som förekommer i rapporten. Term Betydelse CSW Catalogue Service for Web GIF Graphics Interchange Format GIS Geografiskt Informationssystem GML Geography Markup Language HTTP Hypertext Transfer Protocol HTTP-GET HTTP förfrågan med metoden GET HTTP-POST HTTP-förfrågan med metoden POST IANA Internet Assigned Numbers Athority IIS Internet Information Services INSPIRE Infrastructure for Spatial Information in Europe IP Internet Protocol ISO International Organization for Standardization ISP Internet Service Provider JPEG Joint Photographic Experts Group OGC Open Geospatial Consortium OWS OGC Web Service PNG Portable Network Graphics QoS Quality of service RIPE NCC Réseaux IP Européens Network Coordination Centre RIR Regional Internet Registry SDI Spatial Data Infrastructure SGU Sveriges geologiska undersökning SIS Swedish Standards Institute SLA Service Level Agreement SLD Styled Layer Descriptor SPOF Single Point of Failure SVG Scalable Vector Graphics TCP Transmission Control Protocol UNGIWG United Nations Geographical Information Working Group UNSDI United Nations Spatial Data Infrastructure URL Uniform Resource Locator WAN Wide Area Network
Term WCS WebCGM WFS WMS WPS XML Betydelse Web Coverage Service Web Computer Graphics Metafile Web Feature Service Web Map Service Web Processing Service Extensible Markup Language
1 Problembeskrivning I detta kapitel beskrivs syftet med examensarbetet och de problem som analyseras i rapporten samt en avgränsning av vad som ingår i projektet. Här beskrivs även upplägget på rapporten. 1.1 Syfte Syftet med examensarbetet är att utreda och praktiskt utvärdera användningen av standardiserade webbtjänster som används för att sprida geografisk information. Utredningen består av att identifiera potentiella problemområden och att sedan utifrån analys av tekniken presentera lösningsförslag. Resultatet av detta kan bidra till utveckling av en bättre infrastruktur vilken bygger på en samverkan mellan många aktörer och intressenter. Dessa intressenter kan ha olika roller, såsom samordnare, leverantörer och konsumenter av geodata. I examensarbetet har jag undersökt hur dessa serverbaserade karttjänster kan nyttjas i en webbklient för att få bästa möjliga resultat när man arbetar med data från flera olika leverantörer samtidigt. Bland de punkter som har utretts finns vilka parametrar som är viktiga för att data från olika tjänster och leverantörer ska kunna kombineras på ett bra sätt samt hur det påverkar prestanda i form av svarstider och bandbredd. EG-direktivet Inspire ligger till grund för den strategi gällande geografisk data som håller på att implementeras i Sverige idag. Syftet med Inspire är att göra geografisk data mer tillgänglig och aktuell med hjälp av publicering av webbtjänster. Fokus i detta examensarbete ligger inte bara på att undersöka tekniken som kan användas utan även att se hur denna kan användas i olika tillämpningar i praktiken. Tre fokusområden har valts ut, studerats och analyserats. Jag har försökt att identifiera vad som är kritiska framgångsfaktorer ur en användares eller konsuments perspektiv. Urvalet har baserats på förstudien och vad som är mina kompetensområden. Resultatet av analysen är rekommendationer inom fokusområdena för att uppnå en användbar, flexibel, effektiv och framtidssäker tjänstearkitektur. De utvalda fokusområdena är: Kartografisk samordning Här kommer jag att utreda hur kartografi ska definieras och användas så att inte flera leverantörer använder samma symbolik för att representera olika företeelser, vilket kan skapa problem när man ska kombinera tjänster från olika leverantörer. Vem ska underhålla och eventuellt standardisera detta och vilken teknik finns för att möjliggöra att konsumenten kan påverka kartografin så att den passar i sitt sammanhang? Prestanda Detta blir en utvärdering av hur man kan påverka prestanda i infrastrukturen för geodatatjänster. Hur beräknar leverantören hur mycket bandbredd som krävs för varje användare och vilka svarstider som är rimliga att kräva för att tjänsten ska vara användbar? Tillgänglighet En diskussion kommer att föras kring hur man ska förhålla sig till tillgängligheten hos tjänster. Vad händer om en viss webbtjänst slutar svara och hur kan man hantera denna problematik? 1.2 Avgränsning Denna studie fokuserar på hur man i praktiken kan implementera en infrastruktur för geodata och analyserar potentiella problem i ett konsumtionsperspektiv. Produktion, digitalisering eller bearbetning av kartmaterial och geodata ingår inte och inte heller hur intern samordning innan publicering sker. Framtagning och publicering av tjänstespecifikationer och metadata för karttjänster analyseras inte. 1
1.3 Disposition Rapporten beskriver först mitt tillvägagångssätt i kapitlet Metodbeskrivning. Jag beskriver där tillvägagångssättet när jag genomförde förstudie och undersökning, prototyp och testning samt analys av resultat. I kapitlet Bakgrund tar jag upp Inspiredirektivet, som ligger till grund för den tjänsteorienterade arkitekturen som håller på att byggas upp. Den nationella geodatastrategin, planen för hur den svenska implementationen ska genomföras, tas också upp samt hur de olika intressenterna hittills har arbetat inom området. Efter detta beskrivs i kapitlet Tekniken de viktigaste delarna i den bakomliggande tekniken som ska göra implementationen möjlig. En introduktion kring tjänsteorienterad arkitektur och webbtjänster följs av en mer ingående beskrivning av webbtjänsterna för geodatapublicering. Resultaten av min analys beskrivs i Analys av fokusområden och här beskrivs även förslag på hur man kan lösa problemen samt den underliggande tekniken som dessa lösningar bygger på. Slutligen, i kapitlet Resultat och slutsats, finns kommentarer och en diskussion av studiens resultat samt rekommendationer. 2
2 Metodbeskrivning I detta kapitel beskrivs det tillvägagångssätt som studien utförts enligt. Metoden bestod övergripande av en förstudie och undersökning, konstruktion av prototyp och testning samt analys av resultat. 2.1 Förstudie och undersökning Studien inleddes med en förstudie av relevanta artiklar, avhandlingar och teknisk dokumentation samt en omfattande förundersökning. Undersökningen gick ut på att samla information kring intressenters pågående arbete med geodatatjänster och genomfördes främst genom att ställa enkätfrågor via telefon. Intressenterna, som var både samordnare, leverantörer och konsumenter av geodata, bestod av myndigheter och verk som på olika sätt deltar i arbetet med nationella geodatatjänster och Inspire. Jag tog även med några företag som var inblandade i utvecklingen av infrastrukturen och projektgrupper inom området. En översikt redovisas i underkapitel 3.4 Intressenter. 2.2 Prototyp och testning För att undersöka de tekniska möjligheterna och utföra de nödvändiga testerna byggdes en prototyp av en klientapplikation som läser in kartor publicerade som webbtjänster. För testerna användes både driftsatta webbtjänster som publicerats från bland annat Lantmäteriet och Sveriges geologiska undersökning (SGU) samt webbtjänster uppsatta i en testmiljö. Mer om testmiljön beskrivs i underkapitel 4.5 Projektets testmiljö. 2.3 Analys av resultat Förstudien och undersökningen ledde fram till att ett antal fokusområden utformades. Dessa valdes utifrån var potentiella problem kunde uppstå. Resultatet av förstudien och testerna analyserades och ledde fram till ett antal lösningsförslag. Dessa beskrivs i slutet på rapporten presenterat per fokusområde. 3
3 Bakgrund I detta kapitel beskrivs projektet bakgrund vilken bygger på den förstudie och undersökning som genomförts. Jag presenterar här dagens situation, det kommande systemet och vilka som kommer att påverkas. 3.1 Geodata Begreppet geodata används i denna rapport synonymt med geografisk data eller geografisk information. Med detta menas data som med hjälp av någon konceptuell modell försöker representera verkligheten [1]. Användningen av geodata ligger främst i GIS-program, men också i webbapplikationer som exempelvis Google Maps. Åtkomsten till geografisk information är idag begränsad och kräver oftast en relativt komplicerad process. Geodata levereras på exempelvis CD eller DVD, vilket tar tid att framställa och leverera. Prismodeller, fakturering och avtal skiljer sig från olika leverantörer. Även tillgängligheten till geodata är dålig. Det är svårt att få en översikt över vilka datamängder som finns tillgängliga och hittar man information om detta är den sällan välstrukturerad och komplett. Viss geodata är inte heller tillgänglig överhuvudtaget. Den situation som råder idag har gjort att de flesta användare av geodata är tvungna att lagra egna kopior, vilket skapar redundans och leder till att man får data som efter en tid blir inaktuell. I vissa fall kan den omständliga åtkomstprocessen till och med leda till att helt nylevererade data är inaktuella. 3.2 Inspire En infrastruktur för rumslig information (eng. Spatial Data Infrastructure, SDI) är ett samhällsnätverk för geodata med tillhörande metadata och verktyg för att leverantörer och konsumenter ska kunna kommunicera på ett effektivt sätt som ofta styrs av lagar och standarder [2]. En av de huvudsakliga principerna är att geodata ska lagras distribuerat hos respektive producent eller leverantör och inte lagras centralt hos någon samordnande part eller utspritt över konsumenter, vars kopior kontinuerligt behöver uppdateras för att inte bli inaktuella. EG-direktivet Inspire [3] är ett initiativ för att skapa en SDI inom den Europeiska gemenskapen. Direktivet syftar till att realisera detta genom att göra webbtjänster tillgängliga, där man kan komma åt den geografiska information som man söker. Inspiredirektivet trädde i kraft den 15 maj 2007 [4]. Det ska vara genomfört i svensk lagstiftning senast den 15 maj 2009 [5], men på grund av att delar har blivit försenade har detta fått skjutas upp [6]. I Sverige är ansvaret för införandet uppdelat mellan regeringen, Lantmäteriet (som har utsetts till samordnare) och de berörda myndigheterna (alltså de myndigheter som har geodata som påverkas av beslutet). Nationell geodatastrategi är en plan som revideras varje år och den innehåller bland annat riktliner för hur Inspire ska realiseras i Sverige. På EU-nivå finns en geoportal [7] som samlar in information från de länder som genomför Inspire. Kravet är att varje land tillhandahåller en katalog. Dock har det nationella geodataprojektet valt att sätta upp en egen, svensk geodataportal eftersom man vill få in mer funktioner och tjänster än vad som ingår i Inspireportalen [8]. Inte alla tjänster som läggs upp på den nationella portalen kommer därmed att publiceras till Inspireportalen. 4
3.3 Nationell geodatastrategi Geodatatjänster har många användningsområden till exempel miljöanalyser, transportplanering, samhällsplanering, ledningssystem för räddningstjänster, navigering och positionering [9]. Den första versionen av den nationella geodatastrategin togs fram 2007 och man beslutade då att den ska revideras och uppdateras en gång per år [9]. Den första fasen har slutförts, som bestod i att genomföra en behovsanalys, och man har sedan arbetat med att ta fram finansieringsmodeller, prismodeller samt modeller för kostnads- och nyttoanalyser. Målet är att i juni 2009 redovisa resultatet av detta. Ett gemensamt koncept för finansiering och prissättning för de tjänster som publicerats på portalen är viktigt. Man ska också, så långt det är möjligt, harmonisera prissättningsprinciper och förenkla för både leverantörer och kunder. I strategin ingår att en nationell geodataportal ska upprättas som ska kunna användas som en katalog för användare som vill söka bland, titta på och ladda ner geodata. Utvecklingen av geodataportalen och infrastruktur beräknas vara färdig 2010-2011 [9]. För att sammanställa tjänsterna på portalen så ska leverantörer av geodata i Sverige publicera metadata till portalen som beskriver de olika dataset som de tillhandahåller. Verktyget MetaGIS Editor [10] har tagits fram för att skapa och underhålla metadatafiler, som sedan publiceras till portalen i XML-format. Det följer standarderna för metadata ISO 19115 och för ISO 19139 [11]. Geodataportalen ska fungera som en ingång till de olika tjänsterna, men ska inte användas för att leverera några tjänster. Detta ska istället ligga distribuerat hos de olika leverantörerna, men däremot kommer förmodligen betalning och behörighet till tjänsterna att styras via portalen. Vem som ska förvalta portalen efter att geodataprojektet är genomfört är ännu inte bestämt [8]. 3.4 Intressenter Det är många som kommer att påverkas av arbetet med att tillgängliggöra geodata i Sverige. Det innebär till att börja med mycket arbete men ger också stora fördelar när det är färdigt, beroende på vilken roll man har som samordnare, leverantör eller konsument. 3.4.1 Samordnare I Sverige har regeringen utsett Lantmäteriet till officiell samordnare av genomförandet för Inspire och den nationella geodatastrategin [12]. Lantmäteriet har därför inrättat ett geodatasekretariat, ett geodataråd och en projektgrupp. Detta innebär också att Lantmäteriet är ansvarigt för att uppdatera den nationella geodatastrategin och rapportera hur arbetet går. Ett 20-tal myndigheter kommer att bli tvungna att leverera data som andra myndigheter, företag och privatpersoner kommer att kunna använda. Geodatarådet har inrättats med representanter från de olika myndigheter och organisationer som påverkas av Inspire och den nationella geodatastrategin och ska fatta beslut i strategiskt viktiga frågor [13]. Geodataprojektet ansvarar för verksamhetsmodellen och den tekniska infrastrukturen. Det innebär bland annat att sätta upp den nationella geodataportalen och samla in metadata från de leverantörer av geodatatjänster som finns i Sverige. Projektet har även utrett vilka behov som finns hos en SDIanvändare. Geodatasekretariatet har etablerats för att sköta administrationen kring arbetet med den nationella geodatastrategin och Inspire. Inspire arbetsgrupp består av representanter från olika myndigheter som påverkas av Inspiredirektivet. Arbetsgruppen är ansvarig för att samordna ärenden som har anknytning till Inspire. Stanli är ett projektområde för geodata inom SIS. Deras uppgift är att utveckla standarder inom området geodatahantering inom ramen för den nationella infrastrukturen för geodata. Stanli arrangerar 5
också Forum för geodatatjänster vilket är tänkt att fungera som en samlingsplats för intressenter inom området, med ett antal seminarium varje år. När det gäller standardisering av kartografi finns det även ett projekt under framtagning med namnet Kartsymboler och ikoner. 3.4.2 Leverantörer Myndigheter som producerar eller av andra anledningar tillhandahåller geodata ska enligt den nationella geodatastrategin leverera denna i form av webbtjänster. De som besitter datamängder som inte tvunget ska publiceras, både myndigheter och företag, kan ansöka hos Lantmäteriet för att få publicera geodatatjänster på geodataportalen. Leverantörer behöver alltså inte vara de som producerar geodata, utan kan exempelvis ha förädlat eller analyserat geodata och sedan publicerar detta i en tjänst. De kan också inneha data av annan typ, exempelvis statistik, som kan omsättas i geodatatjänster. 3.4.3 Konsumenter Konsumenter av geodatatjänster kommer förmodligen att vara såväl myndigheter och kommuner som företag och privatpersoner. Tanken är att vem som helst ska kunna använda tjänsterna. Konsumenterna kommer att kunna söka efter geodata på den svenska geodataportalen och sedan kunna koppla upp sig direkt till leverantören av varje tjänst. Man kommer förhoppningsvis att kunna sköta betalning och autentisering centralt via portalen. 3.4.4 Angränsande projekt UNSDI är FN:s motsvarighet till Inspire, det vill säga en infrastruktur för geodata. Projektet drivs av United Nations Geographical Information Working Group (UNGIWG) [14] som är ett nätverk av yrkesverksamma inom kartografi och forskare inom geodata. Det bildades 2000 för att hantera gemensamma frågor rörande rumslig information kartor, gränser, datautbyte och standarder som påverkar arbetet i FN:s organisationer och medlemsstater. UNGIWG arbetar även med icke-statliga organisationer, forskningsinstitut och näringsliv för att utveckla och upprätthålla gemensamma geografiska databaser och geospatial teknik med syftet att skapa en bättre normativ och operativ förmåga. OneGeology är en global portal med en katalog över geodata rörande jordens geologi [15]. Det är ett internationellt initiativ vars mål är att göra dynamisk geologisk kartinformation över världen tillgänglig via Internet. SGU har sedan tidigare publicerat ett antal datamängder som finns med i katalogen [16]. En viktig del i arbetet med portalen har varit att ta fram en internationell standard för att kunna visa tjänster från alla olika leverantörer i ett gemensamt gränssnitt. På portalen kan vem som helst idag gå in och titta på den geologiska informationen som presenteras i en webbaserad kartapplikation där man kan välja att lägga in den information man vill titta på i separata lager. 6
4 Tekniken I detta kapitel beskrivs det tekniska konceptet med tjänstearkitektur och tekniken som används för webbtjänster samt vilka standarder som är användbara specifikt för karttjänster. Kapitlet bygger på det jag har kommit fram till i min förstudie och undersökning. 4.1 Tjänsteorienterad arkitektur Med tjänsteorienterad arkitektur (eng. Service Oriented Architecture, SOA) menas att man paketerar funktioner som tjänster och gör dessa tillgängliga via ett väldefinierat gränssnitt. Varje tjänst har en leverantör och en konsument som kan kommunicera via tjänstens gränssnitt oavsett vad som händer inom leverantörens eller konsumentens egna system. Exempelvis kan hela det underliggande systemet hos leverantören bytas ut utan att konsumenten upplever någon skillnad, om även det nya systemet uppfyller tjänstespecifikationen (gränssnittet). Webbtjänster (eng. Web Services) är ett sätt att realisera den tjänsteorienterade arkitekturen. Dessa kan definieras som interoperabla datatjänster vars interaktion sker över ett datornätverk, exempelvis Internet [17]. Fördelarna med tjänsteorienterad arkitektur för geodata är framför allt att man kan säkerställa att aktuella data används, eftersom data hämtas direkt från leverantören. Då undviks också administration av stora datamängder som ska underhållas internt och dessutom hållas uppdaterade. Med en standardiserad affärsmodell införd kommer det att bli lättare för konsumenter med små behov att använda och betala endast för de funktioner som de verkligen behöver. Dessutom blir det enklare att integrera GIS i andra applikationer eftersom de konsumerande applikationerna blir helt oberoende av serverns miljö. Vid utveckling av nya applikationer kommer det att bli enklare att integrera leverantör och konsument eftersom man arbetar mot ett väldefinierat gränssnitt istället för att sätta sig in i leverantörens system. Slutligen kommer detta även att förenkla integration mellan olika leverantörer. 4.2 Webbtjänster för geodata Det finns ett antal protokoll för webbtjänster som är specifikt anpassade för att överföra geodata mellan server och klient. Dessa är standardiserade av Open Geospartial Consortium, som är ett globalt konsortium bestående av företag, statliga myndigheter och universitet [18]. Deras specifikationer och standarder syftar till att tillgängliggöra komplexa geodata på webben i form av tjänster användbara för alla typer av applikationer. De vanligaste OGC-tjänsterna (eng. OGC Web Services, OWS) är Web Map Service (WMS) och Web Feature Service (WFS). Det finns även ett antal andra OGC-tjänster, exempelvis Web Coverage Service (WCS) och Web Processing Service (WPS). Denna rapport kommer dock främst att behandla WMS och WFS eftersom dessa är de mest aktuella i den nationella infrastrukturen. Skillnaden mellan dessa två protokoll är att WMS levererar geodata i form av raster och WFS levererar geodata som vektorgrafik i form av geometriska objekt. Dessa tekniker har lite olika tillämpningsområden och för att enbart betrakta kartor är det vanligast och enklast att man använder WMS. Det som är gemensamt för de flesta OGC-tjänster är att de är uppbyggda i olika dataskikt med lager (eng. layers). I den underliggande databasen lagras de geometriobjekt som konstruerar geodata. Dessa objekt (eng. features) tillhör alltid en viss objektklass (eng. feature type) som har ett antal förbestämda attribut. I varje lager kan en eller flera objektklasser representeras. WMS är internationell standard (ISO 19128) sedan 2005 [19] och bygger på överföring av rastergrafik, vilket innebär att uppritningen sker på kartservern som sedan skickar en rastrerad bild till 7
klienten. Detta innebär också att det blir svårt att påverka levererad kartinformationen på klientsidan vilket givetvis är ett problem med protokollet om man har som vision att publicera webbtjänster som är flexibla och användbara i många olika implementationer. Det går dock att skicka med instruktioner till servern då man begär kartan för att påverka uppritningen. Mer om hur man kan ändra utseendet med olika stilmallar tas upp i underkapitel 5.1 Kartografisk samordning. WMS-operationerna GetCapabilities och GetMap är obligatoriska att stödja för alla WMSservrar. GetCapabilities används för att begära en XML-formaterad specifikation över tjänsten, bland annat vilka operationer tjänsten stöder och vilka lager som finns. GetMap används sedan för att begära de rastrerade kartbilderna. Denna rapport tar inte upp dessa operationer mer detaljerat, utan fokuserar mer generellt på hur WMS kan användas. För med information läs WMS-specifikationen [20]. Christofer Jonsson genomförde 2007 sitt examensarbete på Sweco Position där han bland annat undersökte och utvärderade WMS-standardens lämplighet för att visualisera och publicera geografisk information [21] och jag har delvis utgått från hans resultat i detta projekt. WFS bygger på överföring av vektorgrafik, kodad enligt Geography Markup Language (GML) [22] som är ett XML-baserat språk. GML är definierat av OGC och är även internationell standard (ISO 19136) sedan 2007 [23]. I detta fall skickas inte någon bildinformation utan endast information om objekt och dess koordinater. Detta innebär att om kartan ska visualiseras och ritas upp är detta helt upp till klienten. WFS håller på att bli ISO standard [24]. WCS är framtaget för att överföra täckningskartor (eng. coverage) om man exempelvis har en georefererad rasterbild, ett område med ortofoto eller höjddata som man vill publicera som en tjänst. Även WCS håller på att bli ISO standard [19]. Om man jämför rastergrafiken i WMS med vektorgrafiken i WFS så finns det ett antal fördelar och nackdelar när det gäller olika tillämpningsområden. WMS kan relativt enkelt beskriva kontinuerliga ytor och bilddata med relativt lite dataöverföring. Om man vill hantera attributinformation, utföra nätverksoperationer eller om koordinatprecisionen är mycket viktig är det däremot bättre att arbeta med WFS. Detta kan vara nödvändigt i vissa applikationer, exempelvis vid navigation och ruttplanering. Med WFS blir det dock genast betydligt mer dataöverföring när man beskriver ett större område med många objekt, eftersom man måste skicka alla koordinater och attribut, vilket leder till prestandaproblem. Detta problem tas upp i underkapitel 5.2 Prestanda. Vektorformatet ger dock större möjlighet att ändra på innehållet, ger en större noggrannhet och är lättare att analysera. Det är också möjligt att konvertera mellan raster- och vektordata. Konvertering från vektordata till rasterdata innebär inte att man tappar så mycket information (det är ju detta som sker vid de flesta WMS-anrop), men det omvända (rasterdata till vektordata) innebär så pass stor informationsförlust att det knappast är användbart i praktiken [1]. Det går även att kombinera WMS och WFS, för att till exempel visa en översiktskarta men ändå behålla precisionen när man vill undersöka ett visst objekt mer detaljerat. OGC-standarden Catalogue Service for Web (CSW) [25] är ett gränssnitt för att publicera och söka i datamängder av metadata för geodatatjänster. CSW används för att överföra information från den svenska katalogen för geodatatjänster som finns på den nationella geodataportalen till geoportalen på EU-nivå, för att de svenska tjänsterna ska vara sökbara även där [8]. 4.3 Kartserver Kartserverns uppgift är att svara på förfrågningar från klienten och skicka tillbaka en representation av önskat område exempelvis en rasterbild eller GML. Klienten kan även med hjälp av WFS utföra transaktioner mot kartservern för att bland annat ändra ett objekts geometri eller attribut. Det finns många olika varianter av kartservrar, både kommersiella och med öppen källkod. I detta projekt har GeoServer [26] används som är en mjukvara med öppen källkod skriven i Java. Den kan användas för att publicera data som WMS, WFS och WCS. GeoServer har skapats för att stödja de 8
öppna standarder som OGC har tagit fram och mjukvaran utvecklas, testas och drivs av en öppen grupp från olika organisationer runt om i världen. En kommersiell server som är mycket populär och som utvecklats av ESRI är ArcGIS Server [27]. Här stöds WMS, WCS och WFS (transaktioner för WFS dock endast i ArcGIS Server Advanced). Tjänsterna som servern publicerar kan nås via webbapplikationer, GIS-applikationer och via mobila enheter. En annan servermjukvara med öppen källkod är MapServer [28], skriven i C och som också stödjer de flesta OGC-standarderna, dock inte transaktioner med WFS. Den kan köras i Apache eller IIS och finns även i en betalversion där support ingår, vilken kallas MapServer Enterprise. 4.4 Kartklient Det finns olika sätt att konsumera OGC-tjänster beroende på hur man vill använda dem. För kartvisning kan man använda tunna eller tjocka klienter. I en lösning där konsumenten har en tunn klient kan kartdata presenteras exempelvis i en webbläsare, utan att man behöver installera någon speciell programvara. Exempel på tunna klienter är Google Maps, Hitta.se och Eniros webbkartor med flera. En tjock klient kan innebära att man behöver ha tilläggsprogram till webbläsaren eller fristående GIS-program som gör att man får mer funktionalitet, exempelvis för att uppdatera och analysera kartinformation. Med en tjock klient är man alltså inte begränsad till de funktioner som går att bygga i en webbläsare. Exempel på tjocka klienter är Google Earth och ArcView. Det är vanligt att interna karttjänster baseras på tjocka klienter. I detta projekt har jag inte utgått från någon färdig klient, utan byggt en prototyp med hjälp av JavaScriptbiblioteket OpenLayers [29] vilket är framtaget främst för att kunna integrera kartor på webbsidor och det stöder de flesta OGC-standarderna. JavaScriptkod från min prototyp där jag använder OpenLayers återfinns i bilaga 0. 4.5 Projektets testmiljö Den testmiljö som användes i projektet sattes upp på Sweco Position. Den bestod av en server- och en klientdel. Både servern och klienten körde Windows XP Professional SP2. På servern användes webbservern Apache 2.2.8 med Apache Tomcat 6.0.16. Ovanpå detta användes Geoserver 1.7.3 som kartserver. Databashanteraren var PostgreSQL 8.3, med tillägget PostGIS 1.3.3 för att kunna lagra geometrier. I klienten användes Firefox 3.0.8, samt OpenLayers 2.7 och ovan på detta kördes min prototyp av en webbklient skriven i JavaScript (se bilaga 0). För prestandatesten användes Firebug 1.4.0a17. Den SLD som användes i prototypen återfinns i bilaga 0. 9
5 Analys av fokusområden Huvuddelen av projektet har gått ut på att identifiera potentiell problematik i den praktiska implementationen av den tekniska infrastrukturen för geodata och hitta lösningsförslag på dessa problem. I detta kapitel kommer jag att presentera varför följande områden har valts och respektive fokusområde kommer att analyseras. När man genomför en så stor verksamhetsförändring med så många inblandade intressenter som i geodataprojektet är det svårt att få allt att fungera bra från början. Mycket arbete kommer att gå till analyser och tester innan infrastrukturen kommer att vara på plats och vara användbar. Ändå kan det redan från början vara bra att ta reda på vad som är kritiska framgångsfaktorer och vad som är ett potentiellt problem. Det innebär att man försöker se problem som kan tänkas uppstå senare under implementationen genom att tänka sig in i framtidens situation och då bygga in en skalbarhet samt flexibilitet i systemet för att inte riskera att behöva göra om delar av arbetet senare. Förutom att infrastrukturen ska uppfylla de krav som ställs av lagar och regler är det viktigt att göra tjänsterna användbara i sitt tillämpningsområde. Jag har valt att se hur man kan förbättra användningen ur ett konsumentperspektiv. Jag tror att detta är nödvändigt för att alla de investeringar och resurser som läggs på SDI-projektet ska leda till ett framgångsrikt system. När jag valt de fokusområden som ingår i detta projekt har jag utgått ifrån resultat från förundersökningen, områden jag identifierat som kritiska framgångsfaktorer samt mina egna kompetensområden. Det är tyvärr omöjligt för mig att vara heltäckande i denna studie, eftersom jag haft en begränsad tid till förfogande, därför har jag valt ut tre fokusområden som jag nu kommer att presentera och analysera. Det finns även andra områden som jag gärna skulle vilja titta närmare på och som skulle kunna vara objekt för vidare studier, till exempel tjänsternas gränssnitt och metadata eller tjänsternas interoperabilitet för koordinatsystem och modeller. Eftersom en mängd olika tillämpningsområden troligtvis kommer att bli aktuella om man får denna infrastruktur på plats så kommer det att krävas en flexibilitet i tjänsterna för att effektivisera både för leverantörer och för konsumenter. I stort sett alla applikationer som använder geografisk data skulle potentiellt kunna dra nytta av infrastrukturen, förutsatt att man har en fast uppkoppling mot Internet vilket blir allt vanligare även för bärbara enheter som mobiltelefoner och navigatorer. För att uppnå denna flexibilitet och bygga upp en framtidssäker infrastruktur bör man kunna använda samma tjänst i olika tillämpningsområden, i kombination med andra tjänster. Denna problematik beskrivs och diskuteras i underkapitel 5.1 Kartografisk samordning. En annan viktig del för att göra tjänsterna effektiva är att se till att prestanda är tillräckligt hög och att det finns en skalbarhet för att hantera de kapacitetsbehov som kan tänkas uppstå inom en tid framöver. I underkapitel 5.2 Prestanda diskuteras vilka effekter användning av olika tekniker ger på prestanda och vad man kan göra för att påverka tjänsternas prestanda. För att tjänsterna ska vara användbara är det även viktigt att de har en stor tillgänglighet. I underkapitel 5.3 Tillgänglighet diskuteras denna problematik och vad man kan göra för att minimera riskerna för att tjänster blir oåtkomliga. 5.1 Kartografisk samordning När man arbetar med geodatatjänster i praktiken förekommer det fall då man vill kombinera geodata från olika leverantörer, det vill säga att man vill kombinera olika tjänster. Bland målen för Geodataportalen skrivs: Det ska vara möjligt att kombinera webbtjänster med varandra i Geodataportalen [32]. Att hantera flera tjänster i klienten i form av olika lager kommer alltså vara aktuellt och då vill man kunna representera detta på ett kartografiskt korrekt sätt med god läsbarhet. Detta kräver en kartografisk samordning mellan de olika tjänsterna, som antingen kan åstadkommas på servern eller på klienten. 10
Vanligast är att geodatatjänster publiceras som WMS, men eftersom grafiken renderas på servern är det då svårt att efterbearbeta resultatet på klienten. Om man vill påverka resultatet måste man i samband med förfrågan begära att kartan ska ritas upp på ett speciellt sätt, vilket kan göras med stilmallar innehållande regler för uppritningen. För vissa tillämpningsområden, till exempel då konsumenten vill kunna bearbeta geodata på klienten, används WFS. Då är det alltid upp till klienten att avgöra den kartografiska representationen, vilket innebär att dessa tjänster är mycket flexibla i detta avseende. Använder man WFS så försvinner alltså en del av de problem som uppstår med hantering av stilmallar (bland annat rättigheter att använda stilmallar på kartservern) eftersom man flyttar presentationslagret till klienten, men man har fortfarande samma problem med hur man ska representera de olika objekten kartografiskt. Dessutom är det i många fall en dålig idé att låta klienten ta hand om all presentation av flera anledningar. För det första så måste klienten vara mer avancerad för att kunna hantera presentationen, för det andra blir det mer data att överföra från servern och det blir även mer data att bearbeta på klienten. Användningsområdet för WFS är i första hand att beskriva detaljer på en karta som bygger på en WMS eller för att ändra i en datamängd för internt bruk i en organisation. Alltså behöver vi kunna ändra utseende även på geodatatjänster av typen WMS. Oavsett om man använder WMS eller WFS så krävs det att man på klientsidan vet hur kartan ska och kan anpassas för att passa in i sitt sammanhang, eftersom servern inte kan se detta. Det finns alltså ett behov av stilmallar oavsett protokoll. Vissa WMS-tjänster består av rastergrafik som är förrenderad redan på servern, och kan därför inte påverkas av stilmallar. Detta innebär att kartan brutits upp i många småbilder, vilka brukar kallas tiles. En anledning till att man använder förrenderade rasterbilder kan vara att man vill förbättra prestanda, eftersom man slipper rendera bilder på beställning åt varje användare, exempelvis för att man vill använda olika eller egendefinierade stilmallar. Problem blir då att man låser webbtjänsten till ett specifikt användningsområde, och begränsar möjligheten att kombinera tjänsten med andra tjänster. Detta gör alltså att tjänsten inte blir speciellt flexibel. Möjligtvis skulle man använda geodata från denna typ av tjänst som bakgrundskarta och sedan överlagra denna med andra webbtjänster där viss transparens förekommer. I Sverige har man idag inte hunnit komma fram till ett förslag på hur stilmallar ska användas eftersom det nationella geodataprojektet har haft många andra problem att lösa än så länge samtidigt som det inte har varit tillräckligt prioriterat [8]. På EU-nivå har man i ett utkast med tekniska riktlinjer för visningstjänster skrivit att det behövs regler för hur kartor ska visualiseras för att garantera en konsekvent presentation, även om det inte finns några krav på detta i direktivet [30]. Det skrivs också att stilmallsspecifikationer bör lagras på en delad plats och hanteras som ett register. Det krävs en bra samordnad strategi för att detta ska fungera på ett bra sätt. 5.1.1 Styled Layer Descriptor De stilmallar (eng. styles) som används i kombination med WMS kallas för Styled Layer Descriptor (SLD) och är en OGC-standard sedan 2007 [33]. Med hjälp av denna teknik kan man från en extern källa precisera hur genereringen av rastergrafiken på WMS-servern ska gå till. För att definiera reglerna som utgör stilmallen, det vill säga hur lager och dess objekt ska symboliseras, används Symbology Encoding (SE), som skrivs i XML och är definierat av OGC [35]. Det kan användas för att påverka WMS, WFS och WCS [34]. WMS-specifikationen för version 1.3 hänvisar till SLD, men då SLD inte är någon ISO-standard kan detta vara en anledning till att vissa leverantörer väljer att inte stödja WMS 1.3 och SLD [8]. Resultatet har blivit att de flesta använder WMS 1.1.1 istället. Enligt den grupp inom Inspire som arbetar med tekniska rekommendationer för visningstjänster ska dock även andra standarder än ISOstandarder (exempelvis OGC-standarder som i detta fall) kunna användas så länge de stämmer överens med implementationsreglerna [30]. Denna rapport tar inte upp hur stilmallar och regler skrivs med SLD, utan mer generellt om hur SLD kan användas. För mer information läs SLD-specifikationen [34]. 11
5.1.1.1 Konstruktion av SLD för datamängder och objektklasser Man kan säga att det finns två olika sätt att konstruera stilmallar för en datamängd [34]. Det första sättet är att färga grundläggande objektklasser på samma sätt och det andra är att även ta hänsyn till objektattribut. Det finns tre grundläggande objektklasser som man kan skapa SLD-regler för; de geometriska typerna punkter, linjer och polygoner. Exempelvis kanske en användare vill färga alla punkter ljusblåa, linjer röda och insidan av alla polygoner mörkgröna. Detta kräver ingen kunskap om objektklasser eller attribut, men leder vanligtvis inte heller till en begriplig kartografi. För att skapa en utförligare stilmall behöver man veta något om de olika attributen hos objekten. Exempelvis är det ganska troligt att man vill skilja på den grafiska representationen mellan en motorväg och en landsväg, och då räcker det inte med att man vet att det är en linje för att skapa applicerbara SLD-regler utan man behöver veta vilka attribut i datamängden som beskriver vad linjen representerar. För WMS-tjänster finns på vissa kartservrar möjligheten att använda operationen DescribeLayer. När man anropar DescribeLayer får man tillbaka en beskrivning av ett eller flera specifika lager, vilket man definierar med parametern LAYERS. Beskrivningen innehåller information om de objektklasser som förekommer, och för att få information om en specifik objektklass kan man använda operationen DescribeFeatureType via ett WFS-gränssnitt eller DescribeCoverage för ett WCSgränssnitt. För att illustrera hur stilmallar kan konstrueras och tillämpas har jag tagit fram ett exempel med geodata över ett område i norra Stockholm (Hjorthagen med omnejd). Tre lager har använts från det Digitala Kartbiblioteket [31] som Lantmäteriet tillhandahåller. Geodata som används är Fastighetskartan för polygonlagret, Vägkartan för linjelagret och Terrängkartan för punktlagret, (ursprungligen i vektorformat med tillhörande attribut). Noggrannheten är högre i Fastighetskartan än Vägkartan, och därför ser det ut som att vägar på vissa ställen passerar över eller igenom byggnader. Detta har dock med den ursprungliga datamängden att göra och påverkas inte av stilmallen. Ett exempel på hur de tre lagren kan visualiseras med hjälp av en standardstilmall visas i Figur 1. Kartan är genererad genom att datamängderna importerades i en postgresdatabas, som sedan publicerades som en webbtjänst av typen WMS i den testmiljö som användes under projektet. 12
Figur 1: Polygon-, linje- och punktlager som har visualiserats med standardstilmallar. Lantmäteriet Gävle 2009. Medgivande I 2008/1948. När man kombinerar dessa tre lager blir resultatet den karta som visas i Figur 2. Eftersom visualiseringen bygger på standardstilmallar för polygon-, linje- och punktlager har någon hänsyn inte tagits till vilka attribut som objekten har. Resultatet blir att alla objekt av varje geometrisk typ representeras på samma sätt. Figur 2: Visualisering med standardutseende av geodata över ett område i norra Stockholm. Lantmäteriet Gävle 2009. Medgivande I 2008/1948. För att särskilja olika fastigheter, vägar och intressepunkter på kartan krävs en stilmall som känner till de olika attributen, så att regler kan skrivas för hur dessa ska visualiseras. Observera att syftet med min visualisering inte är att skapa en användbar karta, utan endast att demonstrera hur man kan skapa och använda stilmallar. I mitt exempel har jag valt att polygonlagret ska representera husbyggnader med en blå färg, kyrkor med mörkblå färg och uthus med vit färg. I linjelagret har jag valt att markera vägarna E18 och E20 med röda linjer i olika tjocklek. Övriga vägar är svarta. I punktlagret har jag valt att visa kyrkor som trianglar, idrottsanläggningar som kvadrater och torn som cirklar. Övriga punkter 13
visas inte alls. De tre lagren med applicerade stilmallar visas i Figur 3. Den SLD som används återfinns i sin helhet i bilaga 0. Figur 3: Polygon-, linje- och punktlager som har visualiserats med hjälp av en stilmall. Lantmäteriet Gävle 2009. Medgivande I 2008/1948. När de tre lagren läggs ihop i klienten så blir resultatet enligt Figur 4. Med hjälp av stilmallen kan man nu tydliggöra de objekt som användaren är intresserad av och representera dessa på det sätt som passar tillämpningen. Figur 4: Visualisering av geodata över ett område i norra Stockholm med hjälp av en stilmall (Stilmallen återfinns i sin helhet i bilaga 0). Lantmäteriet Gävle 2009. Medgivande I 2008/1948. 5.1.1.2 Användning av SLD För att tala om för WMS-servern att man vill använda en viss stilmall finns det några olika sätt att gå tillväga [36]. Dessa kan vara användbara vid olika tillfällen. Man talar om för servern vilken metod man vill använda genom att skicka med olika parametrar i http-förfrågningarna (vilken typ av parametrar anges inom parentes bredvid varje metod). Alla nedan nämnda parameteruppsättningar används i samband med WMS-operationen GetMap som begär en kartbild från servern. 14
1. Standardstilmall (HTTP-GET) Om man vill använda den stilmall som är standard enligt leverantören för ett visst lager behöver man inte skicka med någon parameter utan endast vilket eller vilka lager som ska renderas med hjälp av parametern LAYERS. Värdet på parametern ska vara en kommateckenseparerad lista. [20] 2. Vald stilmall på servern (HTTP-GET) När man begär geodata från servern kan man välja att använda att använda en viss stilmall som redan finns tillgänglig på servern för ett specifikt lager, genom att skicka med parametrarna LAYERS och STYLES. LAYERS definierar vilka lager som ska renderas och STYLES vilka stilmall som ska användas, båda parametervärdena är i form av en kommateckenseparerad lista. Vilka stilmallar som är tillgängliga för ett visst lager annonseras när man begär GetCapabilities från servern. [20] 3. Extern SLD (HTTP-GET) För att tala om för WMS-servern att man vill använda en extern SLD ska man skicka med parametern SLD [34]. Värdet på parametern ska vara en URL där en stilmall finns. Då behöver man inte använda parametrarna LAYERS och STYLES. Man behöver alltså inte skicka med stilmallen till servern, utan den tillgängliggörs någonstans via en annan webbserver. När servern renderar grafiken hämtas sedan stilmallen och reglerna tillämpas. 4. Bifogad stilmall (HTTP-GET) Det går även att skicka med en SLD-stilmall direkt från klient till server genom att använda parametern SLD_BODY [34]. Värdet på denna parameter ska vara själva stilmallen i URLkodad XML (eng. URL encoded XML). Stilmallen skickas då med i http-förfrågan vid varje getmap-operation. 5. Bifogad stilmall (HTTP-POST XML) Istället för att skicka med stilmallen och de andra parametrarna som GET-parametrar kan man skicka dessa i form av ett XML-dokument som POST-data. Detta tillvägagångssätt rekommenderas även i SLD-specifikationen men har inte implementerats av så många [34]. 6. Bifogad stilmall (HTTP-POST) I den sista varianten skickas alla vanliga parametrar till GetMap som nyckel-värde-par (som vid operationerna med GET-parametrar) och själva stilmallen skickas som en POSTparameter med namnet SLD_BODY. [36] Variant 1-2 i listan ovan bygger på att man använder stilmallar som redan finns på servern. Detta medför givetvis begränsningar i hur man som tjänstekonsument kan påverka det kartografiska utseendet på tjänsten. Fördelar med att använda fördefinierade stilmallar är att man inte behöver ha någon information om datamängden eller de objektklasser som förekommer i tjänsten. För att göra tjänsterna mer flexibla så är variant 3-6 exempel på hur man från klienten kan begära att en egendefinierad stilmall ska användas. Om konsumenten ska kunna tillämpa detta måste först leverantören tillåta att egendefinierade stilmallar används. Klienten kan få reda hur servern tillåter att man använder stilmallar genom att man begär GetCapabilities och studerar värdena på attributen SupportSLD, UserLayer, UserStyle, RemoteWFS, InlineFeatureData och RemoteWCS (alla av typen boolean) [34]. För att möjligheten att tillämpa egendefinierade stilmallar ska vara användbar krävs dock att man kan skapa stilmallarna, vilket i sin tur kräver mer information om tjänsten som kan fås via DescribeLayer och DescribeFeatureType enligt diskussionen tidigare. Om man väljer att använda variant 3, som innebär att en extern URL skickas med som en parameter, krävs det att man har placerat stilmallen på en plats där den är tillgänglig för kartservern. Detta innebär alltså att man måste ha en webbserver som är värd för stilmallen, vilket är en resurs som konsumenten i detta fall måste ha tillgång till eller sätta upp själv. Den enklare varianten är att istället skicka med en SLD direkt från klienten med hjälp av parametern SLD_BODY. Variant 4, där man skickar med stilmallen som en GET-parameter, kan dock leda till att man får väldigt långa URI:er om stilmallen är omfattande. Enligt RFC 2068 (HTTP/1.1) ska man vara 15