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!

De Minister van metadata (of: terrorismebestrijding in de polder)

De meest extraverte minister uit het kabinet Rutte II, Ronald Plasterk, ligt onder vuur vanwege het vlijtig verzamelen van metadata. Blijkbaar wordt dit verzamelen niet al deugd beschouwd, want de Minister beweerde dat niet onze Vaderlandse veiligheidsdiensten de 1,8 miljoen records hadden geregistreerd, maar dat de veiligheidsdiensten van onze Amerikaanse bondgenoten hier de hand in hadden. Zij begonnen!

Nu wordt in de geosector "metadata"  al enige decennia als speerpunt beschouwd, met Inspire als voorlopig hoogtepunt, maar de metadata waar het hier om gaat zijn van iets andere aard. Toch hebben deze wel een equivalent in de wereld van (geo-)webservices. Ik denk namelijk dat Plasterk en zijn veiligheidsdiensten geografische best zouden willen weten welke organisaties welke geografische thema's wanneer opvragen.

Op zich niets nieuws: de webservices van de risicokaart zijn enige jaren geleden al gesplitst in de publiek en een professioneel deel, waarbij de smakelijke details om redenen van veiligheid op aansporing van de toenmalige Minister van Binnenlandse Zaken voor het grote publiek verborgen moesten worden. Dat waren de jaren waarin de terroristische jeugdclub die bekend werd onder de naam "Hofstadgroep" geregeld de krantenkolommen haalde.

Juist met het voor een groot publiek beschikbaar komen van die geodata is voor onze veiligheidsdiensten het bijhouden wie a) in een georegisters als NGR en PGR zoekt naar bepaalde soorten data, en b) wie vervolgens ook nog daadwerkelijk zo'n webservice aanspreekt een spekkie voor het bekkie. En omdat de logfiles van de GetMap-requests ongetwijfeld ook registreren welke geografisch gebied met die webservices wordt bekeken hebben we hier een mooie bron van informatie voor NSA en
Allemaal metadata, de data zelf, wat een gebruiker er mee doet hoef je nog niet eens te weten. Keer op keer de risicokaart bevragen op ''en bepaalde plek, én dan ook nog bovenmatige interesse tonen voor de PDOK webservice met locaties van overheidsdiensten is natuurlijk verdacht gedrag.

Zo zou je natuurlijk juist ook een voor (aanstaande) terroristen interessant thema als "lokservice" in het NGR en tussen de PDOK webservices kunnen opnemen. na de lokeend, de lok-oma en de loktiener is de lokkaart *) maar een kleine stap.

Het omgekeerde kan ook: de kennisbank terrorisme biedt een mooi overzicht met herkomst en werkgebied van de veiligheid ondermijnende organisaties. Op die kaart moeten de locaties met een korreltje zout worden genomen: het is niet zo dat Al Aqsa Nederland haar thuisbasis tussen het Flevolandse graan heeft, en de inwoners van Eemland hoeven niet direct te vrezen dat het Turkse Marxistische-Leninistisch georiënteerde "Revolutionaire volksbevrijdingsfront" de grazige weiden van Eemnes tot belangrijkste doel van aanslagen heeft verheven.

Voor Ronald Plasterk zijn ambtenaren wel complex dat ook bij het registreren van het gebruik van geo-services er zowel een nationale (PDOK) als een Amerikaanse (ArcGIS Online) service-provider met logfiles over de brug moet komen. En daar bovenop nog eens de diverse OpenStreetMap aanbieders. Best complex!

Tot slot: Zo kan Open Data naast economische waardecreatie, bevordering van bestuurlijke transparantie en uitnodigen tot participatie nog een doel dienen: als lokmiddel waarmee aanstaande terroristen in kaart kunnen worden gebracht. Wie is ook alweer de Minister van Open Data...?



*) Overigens al een bekende kreet in kringen van cryptogrammenmakers. Drie letters.

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!

PDOK is een electriciteitscentrale

Nog pakweg 135 nachtjes slapen en dan is het programma PDOK tot een einde gekomen. Uiteraard loopt de voorziening gewoon door. Daarom wordt er momenteel gekeken hoe PDOK het beste "in de markt" kan worden gezet. GeoNovum organiseerde daarvoor een workshop waar ik was uitgenodigd om over de voorkant van PDOK mee te denken.

PDOK loopt er tegenaan dat een verzameling geoservices lastig verkoopbaar is, want het heeft geen voorkant. Data is niet sexy, een kaart of applicatie wel. Daarom is er een viewer in ontwikkling (PDOK-kaart) die als teaser moet gaan werken.

Naar mijn idee is het een slecht plan om die viewer ook als afzonderlijk PDOK product in de markt te willen zetten. Tijdens de workshop schoot mij de analogie met e-books en e-readers te binnen: een boekhandel levert e-books, en heeft een e-reader (viewer) slechts als hulpmiddel in de etalage staan. wil je een e-reader, ga dan naar je lokale computerboer. Als mijn boekhandel zich gaat richten op de verkoop van e-readers loopt het slecht af. Schoenmaker, blijf bij je leest noemen we dat.

Gisteren realiseerde ik me dat die analogie sterker kan.

PDOK is eigenlijk een electricteitscentrale: je stopt er diverse brandstoffen (datasets) in, een combinatie van kolen, aardgas, olie, biomassa en misschien zelfs wel een nucleair brandstofstaafje. Wat er uitkomt is gestandaardiseerde, gebruiksklare geo-electriciteit: webservices. Hardstikke handig: zo heb ik zelf geen aggregaat nodig om mijn eigen geo-stroom op te wekken.

Om de analogie nog even compleet te maken: Van mijn electriciteitsleverancier verwacht ik ook niet dat die stofzuigers, strijkijzers, televisies en andere stroom verbruikende apparaten gaat verkopen. Goede wijn behoeft geen krans, goede PDOK-geoservices behoeven geen PDOK kaart.

Die geoservices vallen wel trouwens wel in 2 productgroepen uiteen: Enerzijds map services (kaarten met opmaak: als WMS, al dan niet met een serie SLDs, of tiled: TMS/WMTS) anderzijds data services (features: WFS, grids: WCS, downloadservices met een Atom feed als envelopje er omheen). Wezenlijk verschillend, met daardoor ook potentiel verschillende gebruikers.
Misschien dat die 2 productgroepen nog wel een differentiatie in marktbenadering rechtvaardigen.