Voorwaarts en niet vergeten: over houdbaarheid van data en webservices

Afgelopen week las ik in een al wat ouder exemplaar van The NewYorker een interessant artikel over the Internet Archive. Dat is de organisatie die zich bezig houdt met de archivering van alles wat er op het Web verschijnt. Een dag later was ik op bezoek bij de UvA, om daar te praten over ontsluiting van historisch kaartmateriaal. Die twee zaken maakte dat ik me probeerde voor te stellen wat er morgen gebeurt met geodata die we vandaag als webservice aan de buitenwereld ter beschikking stellen.

Langzaam maar zeker worden geo-webservices zoals die door PDOK worden aangeboden niet alleen maar ingezet om een Proof op Concept op te tuigen maar ook "voor 't eggie". Daarmee komt een aandachtspunt dat een aantal jaar geleden al eens in het PDOK klantenpanel werd aangehaald: historie.
Laat ik voorop stellen dat ik het heel erg waardeer als PDOK en andere aanbieders hun data in zo actueel mogelijke vorm aanbieden. meestal wil je actuele gemeentegrenzen, recente luchtfoto's, en up-to-date adressen. Maar je hoeft geen archivaris te zijn om toch af en toe behoefte te hebben aan iets meer belegen services. Die behoefte aan historiek valt in een paar soorten uiteen.

Allereerst kan voor het in beeld brengen van een historische ontwikkeling het van belang zijn ook over data van gisteren, vorig jaar en vorige eeuw te beschikken. In het verlengde daarvan: het kan voor het kunnen koppelen van administratieve data nodig zijn om te beschikken over de gemeente-indeling, wijk en buurt grenzen of postcodes die in overeenstemming is met die administratieve data.

Een ander aspect is de reproduceerbaarheid. Instellingen zoals de planbureaus hebben de wettelijke plicht hun onderzoek gedurende 5 jaar te kunnen reproduceren. Dat vereist dat de services zoals ze vandaag worden aangeboden tot en met 25 april 2020 beschikbaar zijn. Dat geldt niet alleen voor de geodata waarop de WMS of WFS service is gebaseerd, maar ook de configuratie van die service zelf: de layernamen, de visualisatieregels, het schaalbereik etc. Bij gebruik van een externe SLD moet dus ook die SLD met een datumstempel van vandaag beschikbaar blijven. Zelfs als die configuratie aantoonbare fouten bevatte, en daarom ondertussen een update heeft gekregen.
Vergelijkbaar met de eis vanuit de planbureaus is de simpele wens te garanderen dat als ik vandaag naar een webkaart kijk en daar conclusies uit trek, ik hoop dat ik morgen diezelfde conclusies kan trekken, en kan delen met collega's, of kan verdedigen tegenover andere partijen. Als in de tussentijd a) de geodata en/of b) de configuratie van de service wijzigt wordt verkrijgen van inzichten op basis van die webkaart wel erg vergelijkbaar met het schieten op een bewegend doel.


Voor de geodata wordt er in de brondatabases vaak wel een "versioning" systeem gebruikt, waarin met behulp van delta tables of een vergelijkbaar mechanisme de stand van zaken van ieder willekeurig moment X kan worden teruggehaald. Voor de configuratie van de services geldt hetzelfde mits ze met behulp van een version control system zoals GIT of SVN worden beheerd. Maar voor zowel data als configuratie geldt dat deze vorige versies vaak alleen ten behoeve van het technisch beheer beschikbaar zijn. De eindgebruiker van die services (u en ik) hebben het maar te doen met die ene combinatie van actuele data en huidige configuratie die naar buiten wordt aangeboden.

Ik realiseer me dat dat een fikse inspanning kan zijn voor de aanbieder van de services. aan de andere kant, je kunt ook betogen dat de performance van zo'n historische service een tandje minder mag zijn. Het gros van de request zal immers op actuele data & configuratie betrekking hebben.

Misschien iets voor het Rijkscentrum voor het Cultureel Erfgoed om hier mee te experimenteren met hun geoservices? De geoservices van vandaag zijn immers de Atlas der Neederlanden van morgen!

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!