Het Nederlandse keurmerk op WMS

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:

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!

Esri REST API als standaard: het einde van WMS, WFS, WCS (en OGC)?

Reuring in en rond het OGC: Esri heeft haar Geoservices REST API specificatie als standaard aan de internationale geostandaardenbeheerder OGC aangeboden, en deze maand mogen de OGC leden met stemrecht uitroepen of ze het een goed plan vinden deze Esri standaard tot OGC standaard te verheffen.

Op het eerste gezicht lijkt het handig REST tot standaard te verheffen. In veel gemeentelijke en provinciale GIS viewers zie je nu GeoWeb als voorkant dat via REST babbelt met ArcGIS aan de serverkant. Als we allemaal REST-met-een-esri-accent praten kun je die achterkant als je dat wilt inruilen voor open source producten als Geoserver of Mapserver, of proprietary server software van Autodesk, Oracle of Geomedia. Of omgekeerd kun je ArcGIS aan de achterkant houden en er REST sprekende web- en/of desktop clients mee laten werken. Hardstikke interoperabel!

Maar ja, daar hadden we toch al standaarden voor? De familie WxS (de broertjes WMS, WFS, WMTS, WCS, WMC en hun neefjes CSW, SLD). waarom dan toch een nieuwe standaard? Dát staat ontnuchterend beschreven in een bijlage bij het voorstel van Esri (samen met o.a. Oracle) aan het OGC. Daarin staat beschreven wat de overlap is tussen de 8 voorgestelde op REST gebaseerde standaarden en hun bestaande equivalenten. Die overlap is groot, en de motivatie van Esri c.s. om tot een nieuwe serie standaarden te komen is dat van de bestaande standaarden een hoop functionaliteit toch niet gebruikt wordt. Veelal gaat dat om functionaliteit "aan de achterkant": de WxS standaarden ondersteunen veel rijkere datamodellen dan dat Esri's geoservices REST doet.
De OGC standaarden willen alle mogelijkheden omvatten terwijl Esri met zijn REST specificatie een praktische 80/20 regelt hanteert: als we met 20% van de inspanning (lees: regels programmacode) in 80% van de functionaliteit van de OGC services kunnen voorzien, dan is dat toch voldoende?

Dan zijn de bestaande standaarden blijkbaar te complex. Doe daar dan wat aan, zou je denken. In diezelfde bijlage wordt echter ook aangegeven waarom het volgens Esri & Oracle niet mogelijk is de bestaande standaarden aan te passen: "While it would be possible to develop new versions of the OGC Web Services standards using a consistent framework and with support for JSON representations and a RESTful "binding", this will likely take significant time due to the unresolved REST-related discussion items, the current organization of OGC SWGs based on the individual standards and the fragmentation into separate standards."

Daarmee wordt dit voorstel aan het OGC een verzoek om in te stemmen met de bevinding dat de traagheid en fragmentatie van het OGC en haar Standard Working Groups (SWG's) daadkrachtige en samenhangende ontwikkeling van de standaarden onmogelijk maken. Breng dan maar gelijk een voorstel op tafel om het OGC helemaal af te schaffen!

Het is daarmee een testcase voor het OGC: willen het OGC de club zijn die voor iedere toepassing één standaard voorschrijft, of wordt er voor iedere toepassing een serie "standaarden" goedgekeurd. Net zoals de Nederlandse vereniging van huisvrouwen een keurmerk hanteerde, waaraan zowel Dreft als Dubro voldeden, en net zoals het Koninklijk Huis bij het uitdelen van het predicaat "Hofleverancier" ook geen exclusiviteit binnen een branche nastreeft.

Standaarden: je kunt er niet genoeg van hebben!

Op zoek naar open standaarden

Standaarden, je hebt je nodig. Of niet: er zit er een onder mijn fiets, da's een oude standaard die op zich nog wel werkt, maar waarvan de functie in de praktijk is overgenomen door lantaarnpaal, verkeersbord of "nietje", omdat die in combinatie met een kettingslot aanvullende functionaliteit bieden voor bescherming tegen fietsendieven.

Op de GIS Tech hield Han van Veldhuizen in de AGGN track een bij vlagen hilarisch verhaal over standaarden waar de geo-wereld mee te maken heeft. We hebben in Nederland twee belangrijke lijsten van standaarden.

De eerste is een lijst met standaarden die door het programma Nederland Open In Verbinding (NOIV) gepromoot wordt als het doel van het programma. Hiervoor geldt het "pas toe of leguit" (beter bekend als "comply or explain") principe. Je hebt als overheidsinstantie je aan deze standaarden te houden, en zo niet dan moet je uitleggen waarom. Na dat uitleggen volgt er overigens geen sanctie, en ik zie Peter R. de Vries er ook nog niet 1-2-3 een uitzending aan wijden als je uitleg rammelt.

De tweede bevat in de praktijk veel gebruikte open standaarden. Dat klinkt al wat praktischer, dus eens kijken of ik die lijst ergens kan vinden. Google is my friend, en zie: met hit nummer 1 kom ik op de website van het forum standaardisatie waar een persbericht van 26 mei 2009 zegt dat het College Standaardisatie een lijst met veelgebruikte standaarden heeft samengesteld. Daarnaast is er een lijst gepubliceerd, zo gaat het persbericht door, met standaarden "waarvan nog niet zeker is of zij veelgebruikt zijn". "Beide lijsten zijn gepubliceerd op www.open-standaarden.nl" lees ik. Hé, op die site zit ik toch al? Een hyperlinkje was welkom geweest. Dan maar zoeken op de site zelf: "veelgebruikte open standaarden". Ha, 2 hits! Hmm, hit 1 verwijst naar het persbericht dat ik net heb gelezen. Hit 2 dan? Nee, die verwijst naar een RSS feed waarop ik me kan abonneren, maar niet naar een lijst standaarden. Dan maar eens naar de homepagina (voorpagina?) van Open Standaarden. Kijk nou, daar staat een bericht over deze lijsten.

Inmiddels is op basis van reacties van onder meer LNV en VROM is de lijst met standaarden "waarvan het nog niet zeker is of ze veel gebruikt worden" doorgevlooid. Door vraagtekens bij de praktische haalbaarheid van WFS is die er waarschijnlijk vanaf gevallen, maar vreemd genoeg zijn alle geostandaarden zijn verdwenen van de lijst. Allemaal? Nee, één geostandaard staat er nog wel op: SLD (overigens verkeerd aangeduid als "styles layer descriptor"). Maar WMS (webmapping), WCS (rasterdata), CS-W (catalogs) en GeoDRM (en nauwelijks bekende standaard voor het regelen van toegangsrechten tot geo-services) zijn zoek!

Maakt het uit? De bottleneck in de praktijk is de implementatie in de software en de bruikbaarheid. Gaan we met z'n allen ArcGIS Desktop aan de kant gooien omdat het geen gebruik van SLD ondersteunt? (nee, ook niet in ArcMap 10, zie mijn verzoek aan ESRI). Lijkt me sterk. En je geo-gebruik afhankelijk maken van live WFS-services is qua performance ook geen feest. Daar zou de combinatie van WFS en SLD trouwens wonderen in kunnen verrichten. (Steun dat verzoek op ideas.esri.com!).
Bovendien is het gebruiken van de standarden een middel, het moet geen doel zijn. Als de implementatie meerwaarde biedt gaan de gebruikers vanzelf over. Maar ja, welk doel hebben de softwareleveranciers bij een goede implementatie? Bovendien lopen de standaarden per definitie achter bij de techologische ontwikkeingen, dus je vraagt dan van de softwareleveranciers om hun creatieve ideeën nog niet te implementeren maar te wachten tot er een standaard voor is. Dat lijkt me een hardrem op de innovatie!

Is er leven na de Geoloketten?

Om eventuele angst meteen maar weg te nemen: ja, er is leven na geoloketten. En met geoloketten bedoel ik in dit verband uiteraard het RGI (ruimte voor geo-informatie) project Geoloketten.

Gisteren vond de slotconferentie van dit project plaats. Alleen al de locatie (een oude treinwerkplaats in Amersfoort) geeft al aan dat er creativiteit in dit project zat. En zit! Want het project Geoloketten wil de opgedane ervaringen vastleggen en verder uitdragen en heeft daarvoor de site cartafabrica in het leven geroepen. Dat moet de plaats worden waar jij en ik onze ergernissen en vreugde over standaarden, software (metadata editors als geosticker, portaal bouwdozen als geonetwork) met elkaar kunnen delen.

Goedgekeurd door Geonovum. Maar waarom eigenlijk niet gewoon onderdeel van de Geonovum-site, en ook onder de verantwoording van Geonovum in plaats van het geo-maatschappelijke middenveld. Net zoals er ook een www.helpdeskdurp.nl/ was, die tegenwoordig onderdeel is van de VROM-site. Nou ja, terugtredende overheid zeker?
Maar niet teveel zeuren: de gedachte is prima, en ik weet zeker dat er bij jullie veel technische kennis over de metadata-XML's is, er ideeën zijn over de inhoudelijke kant van diverse metadata-onderdelen, er beren op de weg en adders onder het gras gesignaleerd zijn bij het opzetten van geoportalen met ESRI of Open Source software, kortom er veel herbruikbare kennis in de koppen zit. Schudt ze leeg op www.cartafabrica.nl/!

Verbod op shapefiles?

Op 12 december 2007 is de Tweede Kamer akkoord gegaan met het actieplan Nederland open in verbinding. Dat beleidsplan van de ministeries van Binnenlandse en Economische Zaken heeft zijn oorsprong in de motie-Vendrik uit 2002 (!) en is in vlot tempo door staatsecretaris Frank Heemskerk door de kamer geloodsd.
In de motie wordt de implementatie van open standaarden verplicht en het gebruik van open-source software aangemoedigd. Of een koppeling van deze vaak door elkaar gehaalde begrippen in één plan handig is betwijfel ik, de koppeling is naar mijn idee oneigenlijk.
Maar goed, wat gaat dit nu voor de GIS wereld betekenen?
In januari 2008 wordt een lijst open standaarden opgesteld, die vanaf 2 april 2008 (dat is heel snel) moet de rijksoverheid (vanaf december 2008 door andere overheden) verplicht moet worden gehanteerd bij nieuwbouw, verbouw of contractverlenging van ICT opdrachten. Dit volgens het comply-or-explain and commit principe dat inhoud dat je een open standaard moet toepassen. Uitzonderingscriteria zijn (en nu citeer ik uit het actieprogramma):

1. Voor de gewenste functionaliteit is geen open standaard beschikbaar;
2. De open standaard wordt niet door meerdere leveranciers ondersteund
   en op meerdere platforms;
3. De bedrijfsvoering en/of dienstverlening komen op onaanvaardbare
   wijze in gevaar, inclusief beveiligingsrisico’s;
4. Internationaal gemaakte afspraken worden geschonden.

Helaas is het actieprogramma niet altijd duidelijk of de open standaarden gebruikt moeten kunnen worden of gebruikt moeten worden. Mogen ministeries straks nog shapefiles uitwisselen of moeten ze open standaarden (GML?) gebruiken? Moet de gebruikte software één standaard ondersteunen (bijvoorbeeld WMS) of moeten alle standaarden (WMS, WFS, WCS SLD en nog meer) allemaal worden ondersteund? Ik ben benieuwd hoe de lijst er in januari uit ziet.