"big data" of "understanding our world"?

Stomtoevallig kwamen vanochtend twee artikelen voor mijn leesbril die "big data" en "geo" met elkaar in verband brachten. Allereerst las ik in de weekendbijlage van het NRC een artikel van internetscepticus Evgeny Morozov. Dat artikel is in de Engelstalige versie online te lezen op Slate Magazine, dus lees vooral even mee. Morozov betoogt in het artikel dat "big data" vooral gaat over het ontdekken van een cijfermatig verband tussen verschijnselen door bergen data in de übergrote statistiekmolen te gooien, terwijl het geen enkel inzicht geeft in causaliteit: wordt verschijnsel A door verschijnsel B veroorzaakt, of is het er juist een gevolg van, of zijn beide verschijnselen allebei het gevolg van oorzaak C?
Morozov geeft aan dat big data ons lui maakt; in plaats van op zoek te gaan naar de oorzaak van verschijnselen focussen we alleen maar op de gevolgen: "we hoeven niet te vragen waarom alles is zoals het is, zolang we het maar naar believen kunnen beïnvloeden", schrijft Morozov.

5 minuten later werd ik gewezen op het artikel Mapping the Future with Big Data van Patrick Tucker in "The Futurist", het magazine van de World Future Society. Daarin beschrijft Tucker hoe het simpelweg op elkaar stapelen van bergen data op het eerste inzicht wel inzicht lijkt te bieden, maar dat bij nader inzien juist een dwaalspoor blijkt te zijn: het op een topografische ondergrond projecteren van a) een dataset met sociale woningbouw en b) een dataset met misdaadlocaties geeft slechtsaan dat er correlatie is, maar vertelt helemaal niets over een oorzakelijk verband. "Every map is only as good as the data that built it and the understanding of the map maker", schrijft Tucker na een interview met Jack Dangermond, en "If we can avoid the temptation to view any map as complete, if we can remind ourselves not to simply layer a map of housing subsidies on top of the crime map and call it a day, if we can find the energy to instead go one map further, and then another, and then another, then perhaps GIS will live up to its fullest potential."

Dát is de opgave voor iedere serieuze cartograaf: duidelijk maken dat de kaart niet de ultieme waarheid is, maar een hulmiddel naar het ontdekken van oorzakelijke verbanden. En die oorzakelijke verbanden hoeven helemaal niet ruimtelijk te zijn. "Understanding our world" noemt Esri dat, en dat is wezenlijk meer dan (pseudo-)informatie genereren door datasets te stapelen.

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!

GIS in the cloud: door de bomen de wolken niet meer zien

Als nietsvermoedende GIS adviseur wordt je tegenwoordig van alle kanten bestookt met cloudinaanse oplossingen.
Esri bombardeert de GIS gemeenschap met de mogelijkheden van ArcGIS Online. Daarbij wordt het brede publiek, pakweg de gebruikers van al die open data die overheden tegenwoordig ruimhartig over de burgers uitstrooien ook benaderd. Maar binnenkort onder de titel "ArcGIS for Organizations" ook in een vorm waarbij ArcGIS Online een deel van je professionele geo-infrastructuur kan overnemen.

Meer functionaliteit (en dus ook meer beheerslast) bieden SAAS oplossingen zoals die Grontmij, Esri en anderen met ArcGIS Server, al dan niet met GeoWeb er boven op, leveren. De server staat niet meer bij jouw gemeente in de kelder maar in De Bilt of Rotterdam. Of misschien een kant-en-klare Portal for ArcGIS, lekker binnen de veilige firewall van je eigen organisatie. Of toch die kant-en-klare opossing liever in eigen beheer, draaiend op een virtuele EC2 server bij Amazon?

Verder timmert www.giscloud.com flink aan de weg. Ziet eruit als en voelt aan als ArcGIS Online.

En dan de data: al dat lekkers dat PDOK biedt wil je toch ook niet links laten liggen. Natuurlijk kun je dat eerst zelf in ArcGIS Online of GISCloud opnemen, maar dan ben je niet alleen dubbel werk aan het verrichten, maar wordt je cloudketen een aaneenschakeling van meer en meer schakels, en dus kwetsbaarder. Uptime uit SLA ARCGIS Online maal Uptime uit SLA PDOK maal Uptime uit je eigen infrastructuur: houd je dan nog wel wat over?

Gecompliceerde, dus leuke, ontwikkelingen. Voer voor een liefst onafhankelijke conferentie waarin al deze oplossingsaanbieders mogen aangeven hoe ze gezamelijk de ideale geo-informatieinfrastructuur vormen.

Spyware in PDOK diensten?

Nog een paar nachtjes slapen en dan komen de PDOK diensten (kosteloos) beschikbaar voor alle overheden, lees ik in een tweet van programmamanager Pieter Meijer.
Alle overheden, dat zijn pakweg duizend diensten of afdelingen die iets met het PDOK aanbod kunnen gaan doen. Ik ben hardstikke nieuwsgierig wat al deze clubs met die PDOK diensten doen en laat me graag inspireren door creatieve combinaties die pakweg de gemeente Enschede (om voor mij maar eens iets aan de andere kant van het land te noemen) maakt.
Kan er niet ergens in de PDOK toegangslaag een voorziening worden ingebouwd die dit gebruik registreert, verzamelt en aan klantprofielen koppelt? Wees gerust, uiteraard geanonimiseerd, en -in geaggregeerde vorm- alleen toegankelijk voor geautoriseerde PDOK afnemers.

Of moet ik het nog een stap dichterbij de applicatiesoftware (zoals Geomedia en ArcGIS) zoeken. Kan daar spyware in worden ingebouwd die mij laat zien wat voor informatiebronnen in welke combinaties worden gebruikt. Eigenlijk hetzelfde als wat AWStats en Google Analytics voor websites doen: wie vragen je pagina's op, hoe vaak, langs welke weg.

Uiteraard is zo'n mechanisme ook waanzinnig interessante informatie voor de aanbieders van data: eindelijk krijg je zicht op wat je afnemers met de data doen. Soms wellicht tot afgrijzen ("dat mág je er helemaal niet mee doen!"), hopelijk vaak tot voldoening ("joepie, mijn data wordt veel gebruikt!") en tot inspiratie ("verrek, dat kan ook met mijn data").

In een andere recente tweet van Pieter Meijer las ik dat hij een constructief gesprek met Esri Nederland heeft gehad. Dan moet het goed komen met zo'n geodatagebruiksmonitoringsysteem!