De Sint is het land uit, dus dan mogen we ons zoetjesaan weer wagen aan voorspellingen voor het volgende jaar.
Ik zie voor 2014 veel "cloud" aan de geo-hemel.Net zoals wolken worden onderscheiden naar lage, middelbare, hoge en verticaal ontwikkelende exemplaren is zien we in de geo-lucht ook een variëteit aan cloud-oplossingen. Esri is met ArcGIS Online (AGOL) een grote speler, maar sinds 2013 begeeft ook Google zich op deze zakelijke markt: Google Maps Engine (GME) spuugt niet alleen kaarten uit die in Google Maps zelf of in Google Earth bekeken kunnen worden, het serveert ook WMS (zij het heel basaal). Ik ben benieuwd hoe dit Google wolkje zich gaat ontwikkelen. Safe software heeft er in ieder geval het volste vertrouwen in gezien het feit dat FME 2013 al ondersteuning biedt voor GME tables.
Ondertussen wordt er aan het open source front ook druk gewerkt om support voor GME in de GDAL-library in te bouwen. Omdat de GDAL-library wordt gebruikt in vrijwel alle open source geo-software (en trouwens ook in veel "closed source geo-software) ligt daarmee de GME-cloud vanuit heel veel software open.
Maar er is nog veel meer "open source cloud": het Zwitserse bedrijf Sourcepole biedt met QGisCloud een "wolkoplossing" voor QGis. CartoDB is een op open source componenten gebaseerde SaaS (software-as-a-service) oplossing die je echter zelf als lokale of regionale cloud kunt installeren. Misschien iets voor PDOK? MapBox is nog een hosting service, die vooral bekend is van de cartografische tool TileMill waar je héél mooie webkaarten mee kunt maken, zoals de deelnemers aan de TileMill workshop op de OSGeo.nl dag op 13 november jl. hebben kunnen ervaren. Daarmee komt (web)cartografie weer wat dichter bij ontwerpers, die bekend zijn met zaken als CSS en Photoshop-achtige filters.
En zoals FME het gat tussen desktop en cloud probeert te overbruggen voor geodata, zo doet Arc2Earth dat door een tool aan te bieden waarmee je vanuit ArcGIS Desktop naar alle bovengenoemde cloud oplossingen kunt serveren. Dus ook je ArcMap-mxd opzetten naar het CartoCSS van TileMill! (los van publiceren naar de cloud is dat trouwens ook interessant in het kader van de digitale duurzaamheid)
Er zijn nog vele meer wolken een aan de geo-hemel. Google maar eens op "geo" en "cloud". Is dat lastig? Welnee, die rijk geschakeerde wolkenluchten wisten Hollandse meesters als Jacob van Ruisdael in de 17e eeuw ook tot geweldige kunstwerken te inspireren!
De weg kwijt in cloudland? Pink Floyd had het daar in 1973 al over:
maandag 9 december 2013
maandag 11 november 2013
Met geo kun je alles maken! (of: open geodata heeft geen waarde: het creëert waarde!)
Vorige week twitterde ik, koud een uur nadat ik mijn lijfblad van haar cellofaan jasje had ontdaan, enthousiast over de open data special van de Geo-Info. (Lees gerust verder, dat enthousiasme is er nog steeds). Vandaag las ik diezelfde Geo-Info nog een keer. Maar waar ik vorige week met een "open data-bril" las, heb ik vandaag door mijn geodata-glazen gekeken. En jawel, dat gaf een ander beeld!
het is namelijk handig onderscheid te maken tussen aan de ene kant geodata met een intrinsieke waarde, zoals de neerslaggegevens van het KNMI en andere sensordata, maar ook ruimtelijke plannen. Aan de andere kant heb je geodata die als "grondplaat" (bekend van Lego, voor PC-bouwers is "moederbord" misschien een betere term) kan dienen, waarmee andere data meer waarde kan krijgen. In die tweede categorie vallen het Nationaal Wegenbestand (NWB), de BAG (en dan met name de adrescoördinaten), de basisregistratie topografie (BRT) en ook OpenStreetMap. Zelfs als zo'n topografische ondergrond alleen maar als plaatje beschikbaar wordt gesteld heeft het al "grondplaatwaarde". Ook gemeentegrenzen, wijk- en buurtindelingen en postcodepunten en -polygonen vallen in deze groep. Allemaal geodatasets die een ruimtelijke verbinding tussen verschillende administratieve data (de "legosteentjes", of voor de PC-bouwers: de processor, de DIMMs, videokaart etc.) mogelijk maken.
Opvallend is dat de bredere beschikbaarheid van "grondplaatgeodata" niet alleen van waarde is voor administratieve data die als "open data" beschikbaar wordt gesteld, maar ook helpt om "closed data" (zoals klantenkaartgegevens) verder uit te nutten. En daarmee de geo-analyse sector weer een boost geeft.
Open "grondplaatgeodata" heeft dus een andere dynamiek, met andere kansen, dan administratieve open data. Uiteraard heeft de geo-sector er belang bij dat er zo veel mogelijk administratieve data laagdrempelig, liefst als open data beschikbaar komt, omdat daarmee de vraag naar "grondplaten" zelf én de vraag naar kennis van hoe je die steentjes het beste op de grondplaat kunt plaatsen groter wordt: werk aan de geo-advies- en itc-winkel!
Dit alles maakt de rol van open geodata wel bijzonder: het is een aanjager om de potentie van andere open data ten volle te benutten. Daarom is het van groot belang dat we als geosector juist de grondplaten als adrescoördinaten, postcodepunten, gemeentegrenzen en topografie eenvoudig en laagdrempelig beschikbaar stellen. Noem het de "G20", de 20 open basisgeodatasets. Dat is de echte open geodata!
het is namelijk handig onderscheid te maken tussen aan de ene kant geodata met een intrinsieke waarde, zoals de neerslaggegevens van het KNMI en andere sensordata, maar ook ruimtelijke plannen. Aan de andere kant heb je geodata die als "grondplaat" (bekend van Lego, voor PC-bouwers is "moederbord" misschien een betere term) kan dienen, waarmee andere data meer waarde kan krijgen. In die tweede categorie vallen het Nationaal Wegenbestand (NWB), de BAG (en dan met name de adrescoördinaten), de basisregistratie topografie (BRT) en ook OpenStreetMap. Zelfs als zo'n topografische ondergrond alleen maar als plaatje beschikbaar wordt gesteld heeft het al "grondplaatwaarde". Ook gemeentegrenzen, wijk- en buurtindelingen en postcodepunten en -polygonen vallen in deze groep. Allemaal geodatasets die een ruimtelijke verbinding tussen verschillende administratieve data (de "legosteentjes", of voor de PC-bouwers: de processor, de DIMMs, videokaart etc.) mogelijk maken.
Opvallend is dat de bredere beschikbaarheid van "grondplaatgeodata" niet alleen van waarde is voor administratieve data die als "open data" beschikbaar wordt gesteld, maar ook helpt om "closed data" (zoals klantenkaartgegevens) verder uit te nutten. En daarmee de geo-analyse sector weer een boost geeft.
Open "grondplaatgeodata" heeft dus een andere dynamiek, met andere kansen, dan administratieve open data. Uiteraard heeft de geo-sector er belang bij dat er zo veel mogelijk administratieve data laagdrempelig, liefst als open data beschikbaar komt, omdat daarmee de vraag naar "grondplaten" zelf én de vraag naar kennis van hoe je die steentjes het beste op de grondplaat kunt plaatsen groter wordt: werk aan de geo-advies- en itc-winkel!
Dit alles maakt de rol van open geodata wel bijzonder: het is een aanjager om de potentie van andere open data ten volle te benutten. Daarom is het van groot belang dat we als geosector juist de grondplaten als adrescoördinaten, postcodepunten, gemeentegrenzen en topografie eenvoudig en laagdrempelig beschikbaar stellen. Noem het de "G20", de 20 open basisgeodatasets. Dat is de echte open geodata!
Labels:
adressen,
BAG,
bestemmingsplan,
gemeenten,
geo-info,
geodata,
nwb,
open data,
openstreetmap
zondag 3 november 2013
OSGeo.nl in de Blender?
Over 10 dagen barst op de faculteit Bouwkunde van de TU Delft de OSGeo.nl dag 2013 los.
Als trekker vanuit OSGeo.nl ben ik daar dezer dagen druk mee bezig: programmapuntjes op de i, zorgen dat de begroting klopt, nog een laatste rondje persoonlijke "je mag dit niet missen!" mails en niet vergeten mijn verhaal waarmee de dag begint voor te bereiden.
En natuurlijk ook bezig zijn met "the day after", want met de leuke variëteit aan bezoekers op de OSGeo.nl dag krijgen we als bestuur van de stichting OSGeo.nl vast en zeker ideeën aangereikt over waar de stichting het verschil kan maken: het verbinden van bestaande open geo-ict communities met elkaar, met nieuwe gebruikers, én met relevante open source ontwikkelingen op het randje van geo.
Wat dat laatste betreft moet ik met schaamrood op de kaken bekennen dat ik een conferentie compleet over het hoofd heb gezien: de Blender-conference, precies een week geleden. In de hoofdstedelijke Beurs van Berlage nog wel: dus in mijn achtertuin, en een mooie locatie bovendien. (maar niet zo mooi als de Oostserre bij Bouwkunde waar de OSGeo.nl dag gaat plaatsvinden!).
Voor de duidelijkheid: ik heb het hier over Blender-met-twee-e's, het open source 3D modelleer en animatieprogramma. Niet te verwarren met Blendr (dus met één e): de geosocial networking application. (overigens ten onrecht nogal eens neergezet als de hetero uitvoering van Grindr). Over die geosocial networking apps'in een volgende blog meer.
Blender is om meerdere redenen interessant.
Allereerst als open source organisatie. Blender is ontstaan als commerciële software , maar op het moment dat de investeerders de stekker er zo'n beetje uittrokken heeft de Blender-community 100.000 euro bij elkaar weten te harken om de software "los te kopen". En sindsdien is Blender open source, onder een GPL license. (nog een aardigheidje voor geo-ers: de animatiestudio die in 1988 de ontwikkeling van Blender begin heette.... NeoGeo).
Inmiddels is er naast de community een Blender Institute dat zich toelegt op het maken van open 3D animaties en games waarbij Blender niet alleen als tool wordt gebruikt, maar ook verder wordt ontwikkeld.
Daarnaast is Blender voor geo's interessant omdat er inmiddels importmogelijkheden voor geodata in Blender mogelijk zijn. Daarmee is er een brug geslagen tussen geo en een zeer krachtige 3D modelleeromgeving, die weer eens uit een heel andere hoek komt.
Misschien op 19 november maar eens op de 3D inspiratiesessie kijken in hoeverre de B.V. Geo-Nederland al een hand in de Blender heeft gestoken. En in ieder geval op 13 november aanstaande de OSGeo.nl de vraag eens aan de bezoekers stellen wie hier al mee bezig is.
Als trekker vanuit OSGeo.nl ben ik daar dezer dagen druk mee bezig: programmapuntjes op de i, zorgen dat de begroting klopt, nog een laatste rondje persoonlijke "je mag dit niet missen!" mails en niet vergeten mijn verhaal waarmee de dag begint voor te bereiden.
En natuurlijk ook bezig zijn met "the day after", want met de leuke variëteit aan bezoekers op de OSGeo.nl dag krijgen we als bestuur van de stichting OSGeo.nl vast en zeker ideeën aangereikt over waar de stichting het verschil kan maken: het verbinden van bestaande open geo-ict communities met elkaar, met nieuwe gebruikers, én met relevante open source ontwikkelingen op het randje van geo.
Wat dat laatste betreft moet ik met schaamrood op de kaken bekennen dat ik een conferentie compleet over het hoofd heb gezien: de Blender-conference, precies een week geleden. In de hoofdstedelijke Beurs van Berlage nog wel: dus in mijn achtertuin, en een mooie locatie bovendien. (maar niet zo mooi als de Oostserre bij Bouwkunde waar de OSGeo.nl dag gaat plaatsvinden!).
Voor de duidelijkheid: ik heb het hier over Blender-met-twee-e's, het open source 3D modelleer en animatieprogramma. Niet te verwarren met Blendr (dus met één e): de geosocial networking application. (overigens ten onrecht nogal eens neergezet als de hetero uitvoering van Grindr). Over die geosocial networking apps'in een volgende blog meer.
Blender is om meerdere redenen interessant.
Allereerst als open source organisatie. Blender is ontstaan als commerciële software , maar op het moment dat de investeerders de stekker er zo'n beetje uittrokken heeft de Blender-community 100.000 euro bij elkaar weten te harken om de software "los te kopen". En sindsdien is Blender open source, onder een GPL license. (nog een aardigheidje voor geo-ers: de animatiestudio die in 1988 de ontwikkeling van Blender begin heette.... NeoGeo).
Inmiddels is er naast de community een Blender Institute dat zich toelegt op het maken van open 3D animaties en games waarbij Blender niet alleen als tool wordt gebruikt, maar ook verder wordt ontwikkeld.
Daarnaast is Blender voor geo's interessant omdat er inmiddels importmogelijkheden voor geodata in Blender mogelijk zijn. Daarmee is er een brug geslagen tussen geo en een zeer krachtige 3D modelleeromgeving, die weer eens uit een heel andere hoek komt.
Misschien op 19 november maar eens op de 3D inspiratiesessie kijken in hoeverre de B.V. Geo-Nederland al een hand in de Blender heeft gestoken. En in ieder geval op 13 november aanstaande de OSGeo.nl de vraag eens aan de bezoekers stellen wie hier al mee bezig is.
Labels:
3D,
blender,
geonovum,
GIS,
Open Source,
open source geo-ict,
osgeo.nl,
WebGL
zaterdag 19 oktober 2013
Een écht geo-bewust broertje van Buienradar
Terwijl ik dit stukje tik, tikt de regen zachtjes op mijn zolderraam. Perfecte inspiratie voor dit blog dus.
Sinds een paar maanden heb ik de app Buienalarm op mijn smartphone geïnstalleerd. Voor mij hardstikke handig: ik fiets iedere ochtend naar Amsterdam Centraal en pedaleer in Den Haag naar de "nieuwe wijken" waar mijn gemeentelijke werkplek gevestigd is en leg die route 's avonds in omgekeerde richting af. Buienalarm geeft voor mij -naast mijn actuele locatie- voor die 2 plekken aan wanneer er regen wordt verwacht.
Voor mij is de locatie immers "fixed" (ik ga niet omdat het op mijn vast route regent naar een andere bestemming) terwijl ik wel de keuze heb om eerder of later op de fiets te stappen; mijn tijdstip van reizen is flexibel.
Zo biedt Buienalarm voor mij informatie op maat, terwijl ik bij Buienradar zelf nog interpretatie in ruimte (door kaartlezen) en tijd (door de animatie) zou moeten doen.
Om een bekend geo-gezegde te parafraseren: één tijdas zegt meer dan duizend kaartbeelden!
Sinds een paar maanden heb ik de app Buienalarm op mijn smartphone geïnstalleerd. Voor mij hardstikke handig: ik fiets iedere ochtend naar Amsterdam Centraal en pedaleer in Den Haag naar de "nieuwe wijken" waar mijn gemeentelijke werkplek gevestigd is en leg die route 's avonds in omgekeerde richting af. Buienalarm geeft voor mij -naast mijn actuele locatie- voor die 2 plekken aan wanneer er regen wordt verwacht.
Voor mij is de locatie immers "fixed" (ik ga niet omdat het op mijn vast route regent naar een andere bestemming) terwijl ik wel de keuze heb om eerder of later op de fiets te stappen; mijn tijdstip van reizen is flexibel.
Zo biedt Buienalarm voor mij informatie op maat, terwijl ik bij Buienradar zelf nog interpretatie in ruimte (door kaartlezen) en tijd (door de animatie) zou moeten doen.
Om een bekend geo-gezegde te parafraseren: één tijdas zegt meer dan duizend kaartbeelden!
zondag 13 oktober 2013
Innovatie doe je zelf, uitvinden doen de buren. Maar wie zijn die buren?
De quote kwam voorbij tijdens het lustrum van de AGGN (sorry, ik weet niet meer of Layar voorman Raimo van der Klein was, of dat Geodan-er Eduado Dias de opmerking plaatste): "innovatie is niet zelf iets uitvinden, maar het zinvol toepassen van iets dat al uitgevonden is". En vandaag las ik in de lectorale rede van Alexander Pleijter (Fontsys Hogeschool) woorden van gelijke strekking. Dus stop met zelf Willie Wortel spelen, maar kijk over de schutting om te zien of buurman of buurvrouw het wiel heeft uitgevonden waar jij een nieuwe draai aan kunt geven.
Om die reden is het altijd interessant om bijeenkomsten van andere (liefst wel enigszins aanpalende) disciplines te bezoeken. Ik heb het geluk dat zo ongeveer in mijn achtertuin Pakhuis De Zwijger staat, waar de hoofdstedelijke creatieve sector geregeld evenementen organiseert, waar Platform 31 (de opvolger van het NIROV) een aantal keer per jaar haar vaktijdschrift presenteert, waar de uitreiking van de privacyprijs "Big Brother Award" plaats heeft, waar Nederland van Boven aan de pers wordt gepresenteerd en waar de Adobe gebruikersgroep (Illustrator, Photoshop enzo) geregeld een verenigingsbijeenkomst houdt.
Allemaal onderwerpen die aan mijn vakgebied (geo-informatie) raken. Waarom? Omdat ze gaan over het toepassen van geo-informatie. Open data, datavisualisatie, ruimtelijke ordening, allemaal zaken die tegen het gebruik van geo-informatie aanschurken.
Als cartograaf heb ik dus de luxe dat het aantal aanpalende vakdisciplines bijzonder groot is, maar hoe doen mijn geo-collega's die zich geodeet of landmeter noemen dat eigenlijk. Wie zijn de buurmannen en -vrouwen bij wie zij over de schutting kijken om zich te laten inspireren? Het Koninklijk Wiskundig Genootschap? De Nederlandse vereniging voor Ruimtevaart? Ik kan het even niet bedenken, maar ben er oprecht nieuwsgierig naar!
Overigens: naast inspiratie opdoen bij aanpalende of zelfs wat verder verwijderde vakdisciplines blijft een goed gesprek met een geo-collega natuurlijk ook waardevol. Net als trouwens een mooie tentoonstelling, een goed boek of fraaie film. Be inspired!
Om die reden is het altijd interessant om bijeenkomsten van andere (liefst wel enigszins aanpalende) disciplines te bezoeken. Ik heb het geluk dat zo ongeveer in mijn achtertuin Pakhuis De Zwijger staat, waar de hoofdstedelijke creatieve sector geregeld evenementen organiseert, waar Platform 31 (de opvolger van het NIROV) een aantal keer per jaar haar vaktijdschrift presenteert, waar de uitreiking van de privacyprijs "Big Brother Award" plaats heeft, waar Nederland van Boven aan de pers wordt gepresenteerd en waar de Adobe gebruikersgroep (Illustrator, Photoshop enzo) geregeld een verenigingsbijeenkomst houdt.
Allemaal onderwerpen die aan mijn vakgebied (geo-informatie) raken. Waarom? Omdat ze gaan over het toepassen van geo-informatie. Open data, datavisualisatie, ruimtelijke ordening, allemaal zaken die tegen het gebruik van geo-informatie aanschurken.
Als cartograaf heb ik dus de luxe dat het aantal aanpalende vakdisciplines bijzonder groot is, maar hoe doen mijn geo-collega's die zich geodeet of landmeter noemen dat eigenlijk. Wie zijn de buurmannen en -vrouwen bij wie zij over de schutting kijken om zich te laten inspireren? Het Koninklijk Wiskundig Genootschap? De Nederlandse vereniging voor Ruimtevaart? Ik kan het even niet bedenken, maar ben er oprecht nieuwsgierig naar!
Overigens: naast inspiratie opdoen bij aanpalende of zelfs wat verder verwijderde vakdisciplines blijft een goed gesprek met een geo-collega natuurlijk ook waardevol. Net als trouwens een mooie tentoonstelling, een goed boek of fraaie film. Be inspired!
Labels:
AGGN,
cartografie,
de zwijger,
innovatie,
inspiratie,
visualisatie
donderdag 10 oktober 2013
Open data: slachtafval of (w)etenwaardige kliekjes?
De vaste lezers van dit blog (overigens: excuses voor de blogstilte, de voorbereidingen voor de osgeo.nl dag 2013 kosten nogal wat tijd) weten dat de metafoor een van mijn favoriete stijlfiguren is. Voor open data was ik al een poos op zoek naar een fijne metafoor.
Eergisteren was ik aanwezig op een "Inspiration Lab" van de University Leiden/campus The Hague (voertaal inderdaad Engels) waar Open State voorman Arjan El Fassad sprak over open data.
De 10 minuten van Arjan waren voor de doorgewinterde open data betrokkene niet wereldschokkend. Wel grappig: de verontschuldiging, haast schaamte van Arjan voor de naam "Hack de Overheid" (onderdeel van Open State). Even grappig: de suggestie aan het publiek (dat overwegend een Jeugd van Tegenwoordige leeftijd had) dat alle ambtenaren Methusalemiaanse leeftijden zouden hebben. Nu is de scribent dezes weliswaar ambtenaar, en grijs, en varifocusbrildragend, maar ik loop nog zonder rollator en luister zonder gehoorapparaat naar mijn iPod. En trouwens, El Fassed zit zelf ook al aan de verkeerde kant van de veertig.
Maar goed, weer on-topic, en dat topic was open data. In de uitgebreide nazit van de meeting prettig gesproken met Arjan El Fassed en anderen, waarbij natuurlijk weer die mantra "het beschikbaar stellen van alle overheidsdata, ook de ruwe data, zou integraal onderdeel van het werkproces moeten zijn". Daar kun je ver mee gaan, ik kan me niet zo goed voorstellen dat er mensen zitten te wachten op de nog niet eens vereffende punten die mijn landmetende geo-collega's op een dag bij elkaar meten (of gaat er iemand een App maken met de functionaliteit van MOVE3, ik laat me graag verrassen), of op de individuele enquetes waar alle half ingevulde exemplaren ook nog tussen zitten.
Voor de duidelijkheid: alle bij-nijvere dataproducenten doen dat niet omdat ze data willen produceren, maar omdat ze informatie willen genereren. Data is daar een middel bij. Net als kennis trouwens.
Terugkijkend op eergisteren bedacht ik de restaurantkok als metafoor: die maakt voor u een smakelijke hap, en snijdt daarvoor de vetrandjes van het vlees, haalt het loof van de worteltjes en schilt de aardappelen. Die restjes gaan, hup!, de biobak in. Of naar de varkenstrog als de biggetjes in de achtertuin van het restaurant rondlopen. Die kok gebruikt er ook nog een klontje boter bij (en zet de rest van de boter terug in de koelkast), voegt er wat versgemalen peper aan toe (en laat de rest van de peperkorrels in de molen zitten). En dat biefstukreepje dat tijdens het bakken uit de pan springt serveert onze kok ook niet aan u als gast, maar -dierenvriend als hij is- voert hij dat aan de kat van de buren.
En dan hebben we het nog maar over een routinematige restaurantavond, niet over de maandagavond waarop het restaurant gesloten is en de kok voor een select gezelschap dingen probeert waarbij er halverwege de middag goedbedoelde doch niet etenswaardige maaltijden de kliko in gaan.
Zo ook met data. Tijdens het informatieproductieproces (want dat is het doel!) wordt er geëxperimenteerd, weggegooid, toch weer uit de afvalbak (lees: van de backuptape) teruggehaald, geclassificeerd, geïnterpoleerd, gegeneraliseerd. Ik kan me niet voorstellen dat iemand in die complete datadiarree wil zitten roeren.
Is dan alleen de tabel of kaart zoals die op de gemeentelijke website of in het provinciale rapport wordt gepresenteerd datgene wat als open data beschikbaar moet worden gesteld? Nee. Ik denk dat we moeten insteken op één stap daaraan voorafgaand, namelijk de stap waarbij de (beleidsneutrale) onderzoeker de data overdraagt aan de beleidsmaker. Oftewel: het punt waarop data geïnterpreteerd wordt. En ja hoor: dan mis je als open data militant de mogelijkheid de onderzoeker te onderzoeken.
Maar om de huidige open data impasse te doorbreken zullen we voor het moment toch ergens een middenweg moeten vinden tussen het als open data beschikbaar stellen van alleen de viergangenmaaltijd aan de ene kant en het beschikbaar stellen van schillen, botten en gebruikt frituurvet aan de andere kant.
Dan blijft het voor alle partijen behapbaar.
Eergisteren was ik aanwezig op een "Inspiration Lab" van de University Leiden/campus The Hague (voertaal inderdaad Engels) waar Open State voorman Arjan El Fassad sprak over open data.
De 10 minuten van Arjan waren voor de doorgewinterde open data betrokkene niet wereldschokkend. Wel grappig: de verontschuldiging, haast schaamte van Arjan voor de naam "Hack de Overheid" (onderdeel van Open State). Even grappig: de suggestie aan het publiek (dat overwegend een Jeugd van Tegenwoordige leeftijd had) dat alle ambtenaren Methusalemiaanse leeftijden zouden hebben. Nu is de scribent dezes weliswaar ambtenaar, en grijs, en varifocusbrildragend, maar ik loop nog zonder rollator en luister zonder gehoorapparaat naar mijn iPod. En trouwens, El Fassed zit zelf ook al aan de verkeerde kant van de veertig.
Maar goed, weer on-topic, en dat topic was open data. In de uitgebreide nazit van de meeting prettig gesproken met Arjan El Fassed en anderen, waarbij natuurlijk weer die mantra "het beschikbaar stellen van alle overheidsdata, ook de ruwe data, zou integraal onderdeel van het werkproces moeten zijn". Daar kun je ver mee gaan, ik kan me niet zo goed voorstellen dat er mensen zitten te wachten op de nog niet eens vereffende punten die mijn landmetende geo-collega's op een dag bij elkaar meten (of gaat er iemand een App maken met de functionaliteit van MOVE3, ik laat me graag verrassen), of op de individuele enquetes waar alle half ingevulde exemplaren ook nog tussen zitten.
Voor de duidelijkheid: alle bij-nijvere dataproducenten doen dat niet omdat ze data willen produceren, maar omdat ze informatie willen genereren. Data is daar een middel bij. Net als kennis trouwens.
Terugkijkend op eergisteren bedacht ik de restaurantkok als metafoor: die maakt voor u een smakelijke hap, en snijdt daarvoor de vetrandjes van het vlees, haalt het loof van de worteltjes en schilt de aardappelen. Die restjes gaan, hup!, de biobak in. Of naar de varkenstrog als de biggetjes in de achtertuin van het restaurant rondlopen. Die kok gebruikt er ook nog een klontje boter bij (en zet de rest van de boter terug in de koelkast), voegt er wat versgemalen peper aan toe (en laat de rest van de peperkorrels in de molen zitten). En dat biefstukreepje dat tijdens het bakken uit de pan springt serveert onze kok ook niet aan u als gast, maar -dierenvriend als hij is- voert hij dat aan de kat van de buren.
En dan hebben we het nog maar over een routinematige restaurantavond, niet over de maandagavond waarop het restaurant gesloten is en de kok voor een select gezelschap dingen probeert waarbij er halverwege de middag goedbedoelde doch niet etenswaardige maaltijden de kliko in gaan.
Zo ook met data. Tijdens het informatieproductieproces (want dat is het doel!) wordt er geëxperimenteerd, weggegooid, toch weer uit de afvalbak (lees: van de backuptape) teruggehaald, geclassificeerd, geïnterpoleerd, gegeneraliseerd. Ik kan me niet voorstellen dat iemand in die complete datadiarree wil zitten roeren.
Is dan alleen de tabel of kaart zoals die op de gemeentelijke website of in het provinciale rapport wordt gepresenteerd datgene wat als open data beschikbaar moet worden gesteld? Nee. Ik denk dat we moeten insteken op één stap daaraan voorafgaand, namelijk de stap waarbij de (beleidsneutrale) onderzoeker de data overdraagt aan de beleidsmaker. Oftewel: het punt waarop data geïnterpreteerd wordt. En ja hoor: dan mis je als open data militant de mogelijkheid de onderzoeker te onderzoeken.
Maar om de huidige open data impasse te doorbreken zullen we voor het moment toch ergens een middenweg moeten vinden tussen het als open data beschikbaar stellen van alleen de viergangenmaaltijd aan de ene kant en het beschikbaar stellen van schillen, botten en gebruikt frituurvet aan de andere kant.
Dan blijft het voor alle partijen behapbaar.
Labels:
datadiarree,
hack de overheid,
open data,
open informatie,
open state
dinsdag 23 juli 2013
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:
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:
Labels:
DINO,
geonovum,
nationaal georegister,
ngr,
pdok,
standaarden,
WMS
maandag 22 juli 2013
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!
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!
woensdag 26 juni 2013
"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.
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.
Labels:
arcgis.com,
big data,
cartografie,
esri,
geo-informatie,
geo-inzicht,
Morozov,
Patrick Tucker
maandag 24 juni 2013
Geodesign in de "actieagenda architectuur en ruimtelijk ontwerp"?
Vorige week stuitte ik op de "actieagenda architectuur en ruimtelijk ontwerp". Dat gezamenlijke product van de departementen van Infrastructuur & Milieu en Onderwijs, Cultuur & Wetenschap blijkt op 18 september (zegge en schrijve 4 dagen na Carl Steinitz' bezoek aan de VU waar ik in een vorige blog over schreef) door Minister Schultz van Haegen aan de Tweede Kamer te zijn aangeboden. Daarin wordt beschreven wat het belang is van ruimtelijk ontwerp in zijn algemeenheid ("ontwerp helpt andere (top)sectoren verder") en waar de urgentie zit in Nederland (onder meer herbestemming, onderwijshuisvesting, krimp en wateropgaven).
Opvallend is dat waar er in die actieagenda wordt gesproken over "innovatie" en "vernieuwing" dat gaat over a) hoe ontwerp bijdraagt aan innovatie, b) over de veranderende rol omdat gebruikers ("the people of the place, in Carl Steinitz' terminologie) door ontwikkelingen in de ICT beter geïnformeerd zijn dan vroeger, én omdat die gebruikers steeds vaker een actieve rol hebben, soms zelfs als (mede-)opdrachtgever en c) over een nieuwe typen ruimtelijke opgaven . Maar dat technologische ontwikkelingen én gemakkelijker beschikbaar van steeds meer data tot innovatieve vormen van ontwerp kan leiden lees ik niet in de actieagenda.
Misschien kan er op de European Geodesign Summit in september 2013 een workshop worden gewijd aan het doorspitten van de "actieagenda architectuur en ruimtelijk ontwerp" om te kijken waar Geodesign tussen de regels kan worden gelezen, of waar een Geodesign paragraaf kan worden toegevoegd. Daarmee wordt Geodesign uit de geo-ict-hoek getrokken en neergezet als wat het echt is: een logische, 21e eeuwse vorm van ruimtelijk ontwerp.
Ruimtelijk ontwerp dat trouwens geen doel op zich is, maar "slechts" een methodiek om in het planningsproces partijen tot een "common picture" te laten komen. Zo klinkt het heel bescheiden, maar die rol is wel essentieel.
Gelukkig zitten het kloppend hart van ruimtelijk ontwerpend Nederland en dat van het geo-informatiebeleid zo'n beetje op dezelfde gang in het Ministerie van IenM aan de Haagse Plesmanweg. Dat is niet nieuw, ruimtelijk ontwerp en geo-informatie zaten al in de jaren tachtig van de vorige eeuw bijna bij elkaar op schoot bij de toenmalige Rijksplanologsiche Dienst (RPD). Wel nieuw is dat in een belangrijk beleidsdocument, de Structuurvisie Infrastructuur en Ruimte (SVIR) ruimtelijk ontwerp en geo-informatie zo'n beetje in één adem worden genoemd, dus wie weet gaat het langverwachte huwelijk tussen die twee er toch nog eens van komen.
Nb. Om die cross-over te vergemakkelijken: die structuurvisie staat sinds afgelopen weekend in maar liefst twee vormen in PDOK: een keer als onderdeel van alle vigerende ruimtelijke plannen (ook bekend van RO-Online), en daarnaast nog eens als losse geodataset: ruim 200 Mb aan shapefiles!
Opvallend is dat waar er in die actieagenda wordt gesproken over "innovatie" en "vernieuwing" dat gaat over a) hoe ontwerp bijdraagt aan innovatie, b) over de veranderende rol omdat gebruikers ("the people of the place, in Carl Steinitz' terminologie) door ontwikkelingen in de ICT beter geïnformeerd zijn dan vroeger, én omdat die gebruikers steeds vaker een actieve rol hebben, soms zelfs als (mede-)opdrachtgever en c) over een nieuwe typen ruimtelijke opgaven . Maar dat technologische ontwikkelingen én gemakkelijker beschikbaar van steeds meer data tot innovatieve vormen van ontwerp kan leiden lees ik niet in de actieagenda.
Misschien kan er op de European Geodesign Summit in september 2013 een workshop worden gewijd aan het doorspitten van de "actieagenda architectuur en ruimtelijk ontwerp" om te kijken waar Geodesign tussen de regels kan worden gelezen, of waar een Geodesign paragraaf kan worden toegevoegd. Daarmee wordt Geodesign uit de geo-ict-hoek getrokken en neergezet als wat het echt is: een logische, 21e eeuwse vorm van ruimtelijk ontwerp.
Ruimtelijk ontwerp dat trouwens geen doel op zich is, maar "slechts" een methodiek om in het planningsproces partijen tot een "common picture" te laten komen. Zo klinkt het heel bescheiden, maar die rol is wel essentieel.
Gelukkig zitten het kloppend hart van ruimtelijk ontwerpend Nederland en dat van het geo-informatiebeleid zo'n beetje op dezelfde gang in het Ministerie van IenM aan de Haagse Plesmanweg. Dat is niet nieuw, ruimtelijk ontwerp en geo-informatie zaten al in de jaren tachtig van de vorige eeuw bijna bij elkaar op schoot bij de toenmalige Rijksplanologsiche Dienst (RPD). Wel nieuw is dat in een belangrijk beleidsdocument, de Structuurvisie Infrastructuur en Ruimte (SVIR) ruimtelijk ontwerp en geo-informatie zo'n beetje in één adem worden genoemd, dus wie weet gaat het langverwachte huwelijk tussen die twee er toch nog eens van komen.
Nb. Om die cross-over te vergemakkelijken: die structuurvisie staat sinds afgelopen weekend in maar liefst twee vormen in PDOK: een keer als onderdeel van alle vigerende ruimtelijke plannen (ook bekend van RO-Online), en daarnaast nog eens als losse geodataset: ruim 200 Mb aan shapefiles!
zondag 9 juni 2013
Geodesign: ruimtelijk ontwerp op z'n Agile's
Bijna driekwart jaar geleden werd ik door GeoNovum-directeur Rob van der Velde uitgenodigd om op de Amsterdamse VU bij een lezing van dr. Carl Steinitz aan te schuiven. Onderwerp: Geodesign. Op dat moment was Geodesign voor mij nog een onbekend thema. Wel had ik in de pakweg 8 voorafgaande jaren bij het Ministerie van I&M (voorheen VROM) als geo-specialist gewerkt op de afdeling die zich ook met ruimtelijk ontwerp bezig hield. Had ik al die tijd zó in het midden van de Geodesign-orkaan gezeten dat ik niet doorhad dat ik continue aan het Geodesignen was? Want ja, we hadden wel ArcGIS én ArcSketch én Illustrator op onze computers staan! En was Geodesign dan niet meer dan een nieuwe naam voor een al heel lang bestaand concept? (En ook op het moment dat ik dit stuk schrijf levert de combinatie "geodesign" en "ruimtelijk ontwerp" bij Google slechts 2 hits op).
Die dag in september werd zeer enthousiast geopend door Henk Scholten, waarna een introrondje langs de ongeveer 50 aanwezigen leerde dat we met een breed gezelschap aanwezig waren. Da's altijd interessant. Carl Steinitz vertelde boeiend, over "changing geography through design", over hoe "the people of the place", IT, wetenschap en ontwerp in samenwerking tot een goed ruimtelijk ontwerp komen. Wel vroeg ik me af in hoeverre dit nu specifiek voor "geography" was: is niet ieder goed ontwerp een samenwerking van die 4 groepen? En ik miste de politiek-bestuurlijke factor in Steinitz' betoog: ook goede ontwerpen kunnen politiek onhaalbaar zijn.
Geënthousiasmeerd diezelfde dag nog naar de boekhandel om het boek "A framework for geodesign" te bestellen. En vreemd genoeg kwam ik daar niet doorheen. Wat wordt mij voor nieuws verteld? Ik miste de spanning er in, de drive waardoor je nieuwsgierig bent naar de volgende pagina. Dus na pakweg 65 van de 200 bladzijden ging het boekwerk de kast weer in.
Toch blijft de kreet "Geodesign" tot op heden in mijn hoofd rondzingen. Inmiddels ben ik er op uit gekomen dat "real-time" het toverwoord is. Omdat de processorcapaciteit anno 2013 zo groot is dat we ontwerpen "real-time" in 3D kunnen doorrekenen. Omdat alle benodigde geo-informatie tegenwoordig dankzij het gebruik van webservices er ter plekke met de bytes bijgesleept kan worden. Omdat dat proces niet meer tussen 9 en 5 in een met computers volgestouwd rekencentrum moet plaatsvinden maar anywhere, anytime uitgevoerd kan worden.
Dus niet langer meer de lineaire aanpak van een serie randvoorwaarden opstellen, binnen dat kader een ontwerp maken (uiteraard met een aantal varianten) en die tegen elkaar afzetten. Nee: ontwerpen, toetsen, aanpassen (of weggooien), toetsen. In een snelkookpan, samen met alle stakeholders. Klaar terwijl u wacht!
Verrek, het lijkt wel een Agile-aanpak! Een aanpak die we met name uit de software ontwikkeling kennen, maar die langzamerhand ook in andere vakgebieden wordt toegepast.
Geodesign is wat mij betreft dus vooral een proces: ruimtelijk ontwerp met een Agile-aanpak. De opgave voor de geo-sector zit er in die Agile-aanpak (mede) mogelijk te maken.
Die dag in september werd zeer enthousiast geopend door Henk Scholten, waarna een introrondje langs de ongeveer 50 aanwezigen leerde dat we met een breed gezelschap aanwezig waren. Da's altijd interessant. Carl Steinitz vertelde boeiend, over "changing geography through design", over hoe "the people of the place", IT, wetenschap en ontwerp in samenwerking tot een goed ruimtelijk ontwerp komen. Wel vroeg ik me af in hoeverre dit nu specifiek voor "geography" was: is niet ieder goed ontwerp een samenwerking van die 4 groepen? En ik miste de politiek-bestuurlijke factor in Steinitz' betoog: ook goede ontwerpen kunnen politiek onhaalbaar zijn.
Geënthousiasmeerd diezelfde dag nog naar de boekhandel om het boek "A framework for geodesign" te bestellen. En vreemd genoeg kwam ik daar niet doorheen. Wat wordt mij voor nieuws verteld? Ik miste de spanning er in, de drive waardoor je nieuwsgierig bent naar de volgende pagina. Dus na pakweg 65 van de 200 bladzijden ging het boekwerk de kast weer in.
Toch blijft de kreet "Geodesign" tot op heden in mijn hoofd rondzingen. Inmiddels ben ik er op uit gekomen dat "real-time" het toverwoord is. Omdat de processorcapaciteit anno 2013 zo groot is dat we ontwerpen "real-time" in 3D kunnen doorrekenen. Omdat alle benodigde geo-informatie tegenwoordig dankzij het gebruik van webservices er ter plekke met de bytes bijgesleept kan worden. Omdat dat proces niet meer tussen 9 en 5 in een met computers volgestouwd rekencentrum moet plaatsvinden maar anywhere, anytime uitgevoerd kan worden.
Dus niet langer meer de lineaire aanpak van een serie randvoorwaarden opstellen, binnen dat kader een ontwerp maken (uiteraard met een aantal varianten) en die tegen elkaar afzetten. Nee: ontwerpen, toetsen, aanpassen (of weggooien), toetsen. In een snelkookpan, samen met alle stakeholders. Klaar terwijl u wacht!
Verrek, het lijkt wel een Agile-aanpak! Een aanpak die we met name uit de software ontwikkeling kennen, maar die langzamerhand ook in andere vakgebieden wordt toegepast.
Geodesign is wat mij betreft dus vooral een proces: ruimtelijk ontwerp met een Agile-aanpak. De opgave voor de geo-sector zit er in die Agile-aanpak (mede) mogelijk te maken.
woensdag 8 mei 2013
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 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!
zondag 21 april 2013
van framework tot platform: instant geo-informatie
In de bijna dertig jaar dat GIS in Nederland wordt toegepast zijn er een aantal kantelmomenten geweest. Soms zie je dat aankomen, soms besef je dat pas achteraf. Eén zo'n kantelmoment speelde zich af aan het einde van de vorige eeuw. Mede door de komst van ArcView 2 en 3 beleefde GIS een doorbraakmoment: organisaties gingen zélf met GIS aan de slag, dat bleef niet langer beperkt tot een selectief gezelschap van fulltime GIS-experts.
Op de GIS Tech (herstel: de Esri GIS Tech. De in naam mede-organiserende AGGN moest ik met een lichtje zoeken, blijkbaar paste een gebruikerstrack niet meer in het nieuwe GIS Tech format), bespeurde ik ook zo'n essentiële verandering.
De focus bij Esri is al jaren geleden verschoven van softwareleverancier naar "leverancier van een platform" met aanpalende diensten, bedoeld om u te helpen geo-informatie succesvol in te zetten. Nu was dat platform in een recent verleden nog waardevrij: het was een framework, waar je je eigen data in kon, nee zelfs moest stoppen, en waaraan je je zelf verzonnen of goed gejatte analyses en cartografische presentaties kon ophangen. Met de stap van dat framework naar een platform hoef je je niet meer te bekommeren om data, en de templates voor kaarten en voorgebakken analyses zitten er ook al in. Handig!
Toch knaagt er wat. Als geo-professional zit ik liever zelf aan het stuur. (Dat ik me iedere werkdag van Hoofdstad naar Hofstad door machinist en conducteur laat vervoeren heeft met de reiskostenvergoedingspolicy van mijn werkgever te maken.) Ik wil weten wat voor data er in zit, wát die analyse doet en -niet onlogisch voor een cartograaf- heb ik mijn eigen ideeën over de wijze waarop de theorieën van Jacques Bertin en Jacob Nielsen tot een optimale geo/web-ervaring kunnen worden samengesmeed.
Zo'n kant-en-klaar platform kan best handig zijn hoor; open de verpakking, voeg wat water toe, 5 minuten op vol vermogen en je geovraagstuk is opgelost. Maar nog afgezien van het feit dat deze instant-aanpak leidt tot verhoging van de werkeloosheid onder geoprofessionals doet het ook weinig recht aan locatie (lees: organisatie) specifieke omstandigheden. Ieder vraagstuk-met-een-ruimtelijke-component (want we zouden niet meer van geo-vraagstukken spreken) wordt zo geuniformiseerd tot een hapklare eenheidsworst waar Mao en Jan Marijnissen hun vingers bij zouden aflikken.
"Met meer content wordt de afnemer meer content", lijkt het parool. Ik houd echter liever zelf wat te kiezen. Net zoals deze blog-omgeving voor mij een handig platform biedt, maar ik nog wel altijd met mijn eigen woorden zin aan de alinea's geef.
Op de GIS Tech (herstel: de Esri GIS Tech. De in naam mede-organiserende AGGN moest ik met een lichtje zoeken, blijkbaar paste een gebruikerstrack niet meer in het nieuwe GIS Tech format), bespeurde ik ook zo'n essentiële verandering.
De focus bij Esri is al jaren geleden verschoven van softwareleverancier naar "leverancier van een platform" met aanpalende diensten, bedoeld om u te helpen geo-informatie succesvol in te zetten. Nu was dat platform in een recent verleden nog waardevrij: het was een framework, waar je je eigen data in kon, nee zelfs moest stoppen, en waaraan je je zelf verzonnen of goed gejatte analyses en cartografische presentaties kon ophangen. Met de stap van dat framework naar een platform hoef je je niet meer te bekommeren om data, en de templates voor kaarten en voorgebakken analyses zitten er ook al in. Handig!
Toch knaagt er wat. Als geo-professional zit ik liever zelf aan het stuur. (Dat ik me iedere werkdag van Hoofdstad naar Hofstad door machinist en conducteur laat vervoeren heeft met de reiskostenvergoedingspolicy van mijn werkgever te maken.) Ik wil weten wat voor data er in zit, wát die analyse doet en -niet onlogisch voor een cartograaf- heb ik mijn eigen ideeën over de wijze waarop de theorieën van Jacques Bertin en Jacob Nielsen tot een optimale geo/web-ervaring kunnen worden samengesmeed.
Zo'n kant-en-klaar platform kan best handig zijn hoor; open de verpakking, voeg wat water toe, 5 minuten op vol vermogen en je geovraagstuk is opgelost. Maar nog afgezien van het feit dat deze instant-aanpak leidt tot verhoging van de werkeloosheid onder geoprofessionals doet het ook weinig recht aan locatie (lees: organisatie) specifieke omstandigheden. Ieder vraagstuk-met-een-ruimtelijke-component (want we zouden niet meer van geo-vraagstukken spreken) wordt zo geuniformiseerd tot een hapklare eenheidsworst waar Mao en Jan Marijnissen hun vingers bij zouden aflikken.
"Met meer content wordt de afnemer meer content", lijkt het parool. Ik houd echter liever zelf wat te kiezen. Net zoals deze blog-omgeving voor mij een handig platform biedt, maar ik nog wel altijd met mijn eigen woorden zin aan de alinea's geef.
maandag 11 maart 2013
Shapefiles zijn geen standaard
Shapefiles, dat zijn toch dé standaard GIS bestanden? Ieder weldenkend GIS-pakket leest en schrijft ze, en veel geo-professionals weten al amper meer dat het shape-formaat van origine uit de ontwikkelaarskelders van Esri afkomstig is.
Zodra je écht professioneel aan de gang gaat, met een dataset van serieuze omvang, is een geografische index onontbeerlijk. We zijn van de geo, maar nog te vaak doen we onze dierbare geometrieën te weinig eer door ze geen "spatial index" gunnen. Met veel koffiepauze tot gevolg, zelfs bij simpele teken- en identify-acties. Bij data die over het netwerk benaderd werd zag ik zelfs een snelheidswinst van een factor 15!
Wel is er wat vreemds aan de hand als je niet 100% Esri bent. Onze softwarebouwer uit Redlands is in de beroemde white paper uit 1998 waarin het shapefile formaat wordt beschreven "vergeten" de geografische index te beschrijven. Zodoende blijft die .sbn file ("oh, is die daarvoor!") een van de best bewaarde geheimen van de geowereld.
Zelfs Safe, de makers van FME, kennen dit geheim niet. Als gevolg daarvan moet jouw en mijn FME voor het aanmaken van een index uitwijken naar ArcGIS, indien op de PC aanwezig. Als ArcGIS niet op je PC staat, of er geen ArcGIS license vrij is, of ArcGIS als gevolg van applicatie-virtualisatie niet zichtbaar is voor FME kun je fluiten naar je spatial index. En daarmee naar een fatsoenlijke performance. Melk en suiker graag. En doe maar extra sterk.
In Open Source geo-land is dit tot op heden opgelost door dan zelf maar een geografische index op shapefiles te ontwikkelen. In de bekende OGR library en utilities wordt dezelfde .qix index gebruikt die al lang geleden voor Mapserver is ontwikkeld.
Ik typ "tot op heden", want door enthousiast reverse engineeren is het geheim van de "echte" shapefile index ontrafeld en wordt deze met ingang van versie 1.10 van de OGR programmerbibliotheek ondersteund. Da's goed nieuws, want die OGR library wordt in heel veel programma's gebruikt, onder meer in QGis, de Open Source tegenhanger van ArcMap. Vooralsnog overigens alleen bij leesacties, maar ik verwacht in de nabije toekomst ook het aanmaken/bijwerken van indexen in OGR.
Daarvoor zou het helpen als Esri de beschrijving van de indexen in een update van de genoemde whitepaper op zou nemen. Dat zou 15 jaar na het verschijnen van die white paper toch moeten kunnen.
Zodra je écht professioneel aan de gang gaat, met een dataset van serieuze omvang, is een geografische index onontbeerlijk. We zijn van de geo, maar nog te vaak doen we onze dierbare geometrieën te weinig eer door ze geen "spatial index" gunnen. Met veel koffiepauze tot gevolg, zelfs bij simpele teken- en identify-acties. Bij data die over het netwerk benaderd werd zag ik zelfs een snelheidswinst van een factor 15!
Wel is er wat vreemds aan de hand als je niet 100% Esri bent. Onze softwarebouwer uit Redlands is in de beroemde white paper uit 1998 waarin het shapefile formaat wordt beschreven "vergeten" de geografische index te beschrijven. Zodoende blijft die .sbn file ("oh, is die daarvoor!") een van de best bewaarde geheimen van de geowereld.
Zelfs Safe, de makers van FME, kennen dit geheim niet. Als gevolg daarvan moet jouw en mijn FME voor het aanmaken van een index uitwijken naar ArcGIS, indien op de PC aanwezig. Als ArcGIS niet op je PC staat, of er geen ArcGIS license vrij is, of ArcGIS als gevolg van applicatie-virtualisatie niet zichtbaar is voor FME kun je fluiten naar je spatial index. En daarmee naar een fatsoenlijke performance. Melk en suiker graag. En doe maar extra sterk.
In Open Source geo-land is dit tot op heden opgelost door dan zelf maar een geografische index op shapefiles te ontwikkelen. In de bekende OGR library en utilities wordt dezelfde .qix index gebruikt die al lang geleden voor Mapserver is ontwikkeld.
Ik typ "tot op heden", want door enthousiast reverse engineeren is het geheim van de "echte" shapefile index ontrafeld en wordt deze met ingang van versie 1.10 van de OGR programmerbibliotheek ondersteund. Da's goed nieuws, want die OGR library wordt in heel veel programma's gebruikt, onder meer in QGis, de Open Source tegenhanger van ArcMap. Vooralsnog overigens alleen bij leesacties, maar ik verwacht in de nabije toekomst ook het aanmaken/bijwerken van indexen in OGR.
Daarvoor zou het helpen als Esri de beschrijving van de indexen in een update van de genoemde whitepaper op zou nemen. Dat zou 15 jaar na het verschijnen van die white paper toch moeten kunnen.
Abonneren op:
Posts (Atom)