Gisteren beweerde ik dat WMS minder standaard is dan we wel eens denken, met name door de vrijheidsgraden die deze OGC standaard in zich heeft. Ik had zelf al een follow-up in gedachten, en toen er ook nog een reactie van Thijs Brentjens binnenkwam kon ik niet meer uit onder het publiceren van deze aanvulling:
GeoNovum weet raad, want heeft voor WMS services een Nederlands profiel opgesteld. In dat profiel zijn een flink deel van de hier boven geschetste vrijheidsgraden dichtgetimmerd, zoals de verplichting de WMS in 3 coördinaatsystemen te serveren: RD, ETRS89 en WGS84. Met de bij dat profiel behorende validator kun je nagaan of een WMS service (niet noodzakelijker wijs een die je zelf serveert) aan dit Nederlandse profiel voldoet.
Ook in het Nationaal Georegister staat onder iedere WMS-service een knopje waarmee die service kan worden gechecked op het voldoen aan de Vaderlandse Set van Afspraken. Eerlijk gezegd dacht ik tot gisteren dacht ik dat dat icoontje aangaf óf een service aan het profiel voldoet, maar nee, je moet zelf nog even op die knop drukken om de ("live"-)testresultaten te krijgen.
Ik heb ze niet allemaal uitgeprobeerd, maar een forse steekproef leert dat met name de manier waarop de resultaten van GetFeatureInfo (de "identify") wordt teruggegeven een struikelblok is; "text/xml" blijkt maar weinig ondersteund te worden. Ook de PDOK services gaan daar "nat" op. Dat het wel kan bewijst TNO, de GeoTop-services formatie van Stramproy (onderdeel van DINO) slaagt met vlag en wimpel voor het Nederlandse profiel-"examen".
"The devil is in the detail" riep toenmalig PDOK-programmamanager Pieter Meijer vorig jaar bij het puntjes-op-de-i-zetten. Inderdaad, want juist dit soort details maken het verschil tussen webservices als eeuwige belofte en webservices als echte doorbraak naar een breder publiek.
WMS is niet de enige standaard die een rekbaar begrip is:
dinsdag 23 juli 2013
maandag 22 juli 2013
WMS is geen standaard
Een paar maanden geleden schreef ik dat shapefiles geen standaard zijn. Dat was natuurlijk een open deur. Maar ook die mooie OGC-standaarden, de WxS familie (WMS, WFS, WCS etc.) zijn wat minder standaard dan je zou denken en willen.
Als voorbeeld de WMS, de Web Map Service, zo'n beetje de moeder aller geo-webservicestandarden. Dat die verschillende versies kent (1.1.0, 1.1.1, 1.3.0) is een kwestie van voortschrijdend inzicht, maar in ieder geval zijn die versies door hun nummers helder onderscheidbaar. Lastiger wordt het met de vrijheidsgraden die er binnen die versies zitten. Een "GetCapabilities" en een "GetMap" moet iedere WMS service kunnen ophoesten, maar als je er ook een reeks legendablokjes van wilt opvragen ("GetLegendGraphic") of er met de spreekwoordelijke geo-breinaald een identify op wilt uitvoeren ("GetFeatureInfo") moet je maar hopen dat de serversoftware zo vriendelijk is dat te ondersteunen. En als die GetFeatureInfo wél geïmplementeerd is is het nog een verrassing wat voor soort antwoord je krijgt; dat kan een opgemaakt stukje HTML zijn, of kale text, of een brokje XML of zelfs een hapje GML of JSON.
Opgemaakte HTML leest natuurlijk lekker weg als antwoord, maar als je een webapplicatie hebt waar verschillende WMS services onder hangen, waarvan de aanbieders allemaal hun eigen ideeën hebben over de grafische HTML-opmaak van de GetFeatureInfo wordt die applicatie voor de eindgebruiker erg rommelig. Dan is het handiger als je wat XML terugkrijgt, om daar vervolgens aan de client-kant wat opmaak-logica op toe te passen. Of als je een eigen opmaak-template met het GetFeatureInfo request kunt meesturen om zo voor de nietsvermoedende eindgebruiker een consistente gebruikservaring aan te bieden.
Dus voordat je een externe WMS-service gaat gebruiken even de checklist aflopen: is het een platte WMS zonder zelfs maar identify-mogelijkheden ("koffie zwart") of gaat het om een SLD-enabled WMS met user-stylable GetFeatureInfo ondersteuning ("Decaf Double tall non-fat extra-dry cappuccino"). Dat is voor de geo-sensatie van de eindgebruiker een wereld van verschil!
Als voorbeeld de WMS, de Web Map Service, zo'n beetje de moeder aller geo-webservicestandarden. Dat die verschillende versies kent (1.1.0, 1.1.1, 1.3.0) is een kwestie van voortschrijdend inzicht, maar in ieder geval zijn die versies door hun nummers helder onderscheidbaar. Lastiger wordt het met de vrijheidsgraden die er binnen die versies zitten. Een "GetCapabilities" en een "GetMap" moet iedere WMS service kunnen ophoesten, maar als je er ook een reeks legendablokjes van wilt opvragen ("GetLegendGraphic") of er met de spreekwoordelijke geo-breinaald een identify op wilt uitvoeren ("GetFeatureInfo") moet je maar hopen dat de serversoftware zo vriendelijk is dat te ondersteunen. En als die GetFeatureInfo wél geïmplementeerd is is het nog een verrassing wat voor soort antwoord je krijgt; dat kan een opgemaakt stukje HTML zijn, of kale text, of een brokje XML of zelfs een hapje GML of JSON.
Opgemaakte HTML leest natuurlijk lekker weg als antwoord, maar als je een webapplicatie hebt waar verschillende WMS services onder hangen, waarvan de aanbieders allemaal hun eigen ideeën hebben over de grafische HTML-opmaak van de GetFeatureInfo wordt die applicatie voor de eindgebruiker erg rommelig. Dan is het handiger als je wat XML terugkrijgt, om daar vervolgens aan de client-kant wat opmaak-logica op toe te passen. Of als je een eigen opmaak-template met het GetFeatureInfo request kunt meesturen om zo voor de nietsvermoedende eindgebruiker een consistente gebruikservaring aan te bieden.
Dus voordat je een externe WMS-service gaat gebruiken even de checklist aflopen: is het een platte WMS zonder zelfs maar identify-mogelijkheden ("koffie zwart") of gaat het om een SLD-enabled WMS met user-stylable GetFeatureInfo ondersteuning ("Decaf Double tall non-fat extra-dry cappuccino"). Dat is voor de geo-sensatie van de eindgebruiker een wereld van verschil!
Abonneren op:
Posts (Atom)