zondag 26 april 2015

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!

Geen opmerkingen:

Een reactie posten