Fig. 3. De Web Map Service beantwoordt de
bevraging door een plaatje terug te sturen
met de visualisatie van de opgevraagde
kaartstijl.
Wanneer een 'GetLegendGraphic-re-
quest' wordt uitgevoerd zonder dat er
een 'Rule' wordt opgegeven dan meldt
de SLD 1.O-specificatie letterlijk het
volgende:
In the case that a style has multiple rules but no
specific rule is selected, then the map server is
obligated to produce a graphic that is represen
tative of all of the rules of the style.
Een voorbeeld request en respons hiervan is:
//demo.cubewerx.com/demo/cubeserv/
cubeserv.cgi?CONFIG=nrcan&SERVICE=
WMS&VERSION=1.3.0&REQUEST=Get
Legend Graphic&LAYER=ROUTE_L:nrcan&
STYLE=Topographic&SCALE=125000&
FORMAT=image/png
Representative is echter een subjectief
begrip. Betekent het dat een WMS naast
een icoontje zelf de beschrijvende titel
moet presenteren? Zonder titel zijn de
klassen namelijk niet onderscheidbaar.
Zowel de server-applicatie Mapserver
als Cubewerx toont in dit geval een
complete legenda. Dit is niet altijd het
geval, aangezien de specificatie hier
niet duidelijk over is.
Unclassified
Highway-Hard Surface
Highway-Other, Hard
- - Road Unknown
Main-Hard Surface
Mai iv Unknown
Other-Hand Surface
Secondary - Loose Surface
Secondary - Hard Surface
Fig. 4. De Web Map Server beantwoordt de
bevraging door een plaatje terug te sturen
met de visualisatie van alle kaartstijlen.
De bovengenoemde implementaties voor het opvragen van een
legenda kennen ook beperkingen. Het is bijvoorbeeld niet mo
gelijk om een legenda op te vragen die alleen die klassen toont
die binnen het huidige kaartbeeld aanwezig zijn. Dit kan bij
voorbeeld nuttig zij n voor de legenda van een bodemlcaart, die
vaak meer dan 100 klassen bevat en anders onleesbaar wordt.
Om dit mogelijk te maken, moet een WMS namelijk ook de
'bbox-parameter', die de lcaartuitsnede representeert, doorge
stuurd krijgen voor het 'GetLegendGraphic-request' maar dit is
niet het geval. Daarom heeft de Cubewerx WMS een specifiek
'GetLegend-request' toegevoegd dat dezelfde parameters heeft
als een 'GetMap-request'.
Attribuut-informatie
Attribuut-informatie behorende bij een klik in de kaart kan
opgevraagd worden via het 'GetFeaturelnfo-request'. Dit is het
probleemkind van de WMS-specificatie. Het responsformaat is
erg ruim gedefinieerd. Een WMS mag HTML teruggeven, een
eigen gedefinieerd XML-formaat of bijvoorbeeld GML. In de
praktijk is deze interface dan ook weinig interoperabel. Op dit
moment zijn er initiatieven gaande om het responsformaat
van 'GetFeaturelnfo' nauwkeuriger te definiëren.
MIME-types
In WMS 1.1.1 gebruikt OGC haar eigen MIME-types. Een
MIME-type geeft het type bestand aan, een voorbeeld is
'image/gif of 'application/pdfHet MIME-type van de
'GetCapabilities-respons' is gedefinieerd als 'application
/vnd.ogc.wms_xml' en niet als 'text/xml'. Hierdoor weten
webbrowsers niet wat ze met dit bestand moeten doen en
tonen derhalve de gebruiker een 'opslaan als'-dialoog. In
WMS 1.3.0 is dit gecorrigeerd en is het mime-type gewoon
'text/xml'.
WMS 1.3 versus WMS 1.1.1
Eind 2004 is er een nieuwe versie (1.3) van de WMS-specificatie uit
gekomen. Versie 1.3 is ook meteen de eerste WMS-specificatie die
tevens als ISO-standaard (ISO 19128) is uitgekomen. Tot op heden
zijn er nog weinig implementaties van. Een belangrijke reden is
dat in WMS 1.3 de volgorde van de coördinaat-assen afhankelijk is
van de projectie waardoor de betekenis van de projectie-definitie
EPSG: 4326 (WGS84) verschilt tussen WMS 1.1.1 en WMS 1.3. Een
WMS 1.1.1-request voor de hele wereld in de WGS84-projectie zou
bestaan uit bbox= -180, -90, 180, 90. In WMS 1.3 is dit bbox=
-90, -180, 90, 180. Je kunt je voorstellen wat voor chaos een derge
lijke wijziging kan veroorzaken.
Fig. Sa. Een request
naar een WMS 1.3-
server op basis van
de assen-volgorde
van WMS 1.1.1.
Fig. Sb. Een request
naar een WMS 1.3-
server op basis van
de assen-volgorde
van WMS 1.3.
GEO-INFO 2006-6
