De inkt van het -voor mij verrassende- bericht over het faillissement van geodatamakelaar Bridgis was nog niet droog of op diverse plekken ontstonden er discussies en initiatieven over het zélf vervaardigen van een bestand met postcodegrenzen. Niet dat erop dit moment in het geheel geen bronnen meer zijn voor zo'n bestand, bij mijn weten levert First Element nog steeds de Bridgis versie, terwijl Geodan al sinds jaar en dag zelf zo'n bestand maakt en vermarkt.
In de Nederlandse open source geo community werd de discussie of we geen crowdsourced 6 positie postcodevlakkenkaart zouden kunnen maken aangezwengeld door Jan-Willem van Aalst, en een weekje later zag ik dat Esri Nederland ook aan het experimenteren is met het zelf uitwerken van een algoritme om aan de hand van de BAG, het NWB en andere open data tot een landsdekkend 6-positie postcodevlakkenbestand te komen.
Los van de vraag over nut en noodzaak van het zelf maken van zo'n dataset, over eigenaarschap en hoe je een en ander "vermarkt" is zijn deze initiatieven erg interessant voor het thema datakwaliteit. Het is een prima oefening in het definiëren van kwaliteitsparameters: waar moet een 6-positie postcodevlak (en zijn "vader" en "grootvader", de 5- en 4-positie vlakken) eigenlijk aan voldoen?
Een primaire eis lijkt mij dat alle adrespunten van een 6-positie postcode binnen het resulterende vlak moeten liggen. Maar zelfs dat is niet altijd evident; de plaatsing van een verblijfsobjectpunt in de BAG is soms discutabel: neem je als BAG-beheerder de bij een appartement de locatie van de gemeenschappelijke ingang (vaak ook de locatie van de brievenbus) of prik je dat VBO-punt op het verblijfsobject zelf? Die 355 verblijfsobjecten in de 42 verdiepingen tellende Haagse Toren zijn op dat punt een mooie uitdaging! Zoek 'm maar op in de BAG-viewer: bij postcode 2516LX.
Voor het oog van de kaartlezer is het daarnaast prettig als de grenzen van de postcodegebieden er een beetje smakelijk uitzien: liefst geharmoniseerd met topografie wegen, spoorlijnen, rivieren en kanalen. En voor het koppelen van data ook handig als de grenzen waar mogelijk samenvallend met wijk- en buurtgrenzen zoals CBS en gemeenten die hanteren. Maar dat dan wel met zo min mogelijk vertices (tussenpunten): performance is immers ook een kwaliteit.
Historie opbouwen zou natuurlijk mooi zijn, maar dan leg ik de lat wel heel erg hoog; als ik er van uitgaan dat het een landsdekkend bestand moet opleveren ontkom je er niet aan dat bij het ontstaan van een nieuwe 6-positie postcode de buurvlakken iets van hun oorspronkelijke territorium moeten prijsgeven. O ja, wat is dan eigenlijk landsdekkend? Moet het IJsselmeer in 6-positie postcodes worden verkaveld? Het Hollands Diep? De Rijn, IJssel, Waal en Maas. Het Uddelermeertje?
Nog een stap verder redenerend kun je je afvragen waarvoor je eigenlijk een 6-positie vlakkenkaart zou willen toepassen. Voor het weergeven van een absoluut verschijnsel (bijvoorbeeld: aantal inwoners) is een figuratieve kaart beter geschikt, voor het weergeven van een relatief verschijnsel (zoals inwonerdichtheid) zou dit de extra eis opleveren dat de oppervlakte van de te maken postcodevlakken een direct relatie heeft met het aantal adressen (of nog scherper: verblijfsobjecten) in dat postcodegebiedje. Dat wordt wel heel complex. Mag ik die even parkeren?
Zoals u op de GeoBuzz kon merken is Alterra bezig met het opzetten van een framework waarmee de vraag "wat is datakwaliteit?" beter moet kunnen worden beantwoord. Misschien zijn deze bottom-up postcodegrenzen een leuke case: het vereist geen specifieke domeinkennis (over bijv. bodem, geluid of natuur), de discussie leeft al op diverse plekken, en is concreet genoeg om ook direct toepasbaar te zijn.
Ik ben er nog niet over uitgepraat, zoals de lezer aan de titel al merkte. Stay tuned voor meer aspecten, en voortschrijdend inzicht
Posts tonen met het label BAG. Alle posts tonen
Posts tonen met het label BAG. Alle posts tonen
zondag 8 februari 2015
zondag 7 september 2014
It is dienmakke! De BAG zit in OpenStreetMap
Afeglopen zaterdag reisde een groep OpenStreetMap enthousiastelingen naar De Fabriek in Leeuwarden om daar de laatste hand te leggen aan de import van de BAG panden en adressen in OpenStreetMap (OSM). Weinig volbloed Friezen overigens, maar met een introductierondje bleek dat iedereen wel een historische band ("ik ben wel eens in Harlingen geweest") met Friesland had .
Ik ga er van uit dat ik bij de lezer het bestaan van OpenStreetMap niet hoef te introduceren. Wel is het handig te weten dat er ruwweg 3 manieren zijn waarop OpenStreetMap kan worden bijgehouden.
Gewapend met GPS wandelend of fietsen op pad, en onderweg nieuwe wegen en paden signaleren, nieuwe Points-of-Interest markeren etc. In landmeetkundige terminologie terrestrische inmeting, in OSM-taal "warme mapping". Al is die laatste term in guur novemberweer misschien wat vreemd. De aldus ingewonnen data wordt bij terugkomst op de thuisbasis (bij moeder de vrouw, of op buitenlandse hotelkamer) verwerkt en definitief in OSM gezet.
Het winterseizoen leent zich wellicht meer voor het thuis bij de kachel en met de poes op schoot aan de hand van luchtfoto's (BING, PDOK) intekenen van nieuwe of veranderde objecten. Deze fotogrammetrische vorm van OSM-data-inwinning is in Nederland minder relevant. De OSM-datadichtheid is al groot, en de wijzigingen in paden en lanen worden vaak sneller in het terrein opgemerkt en aangepast, dan via de vertragende omweg van luchtfoto's van enkele jaren oud. Maar misschien dat het begin 2015 via PDOK beschikbaar komen van luchtfotos'uit 2014 deze vorm van mapping ook in ons land nieuwe perspectieven biedf.
De derde vorm is de vorm waar ik in deze post wat dieper op in ga, het importeren van andere datasets.
In de Nederlandse OSM-historie zijn er 2 grote imports van externe data geweest. De eerste was het offer you can't refuse van autonavigatiebedrijf AND, dat in 2007 haar toenmalige dataset van Nederland, China en India ter integrale opname aanbood. Daarmee werd de Nederlandse in een klap van vele witte vlekken naar een landsbreed goed gevuld raamwerk van wegen. Wat bij veel mappers enthousiasme ontlokte om dan ook de fiets- en wandelpaden in OSM te krijgen.
Een tweede importgolf kwam in 2010. Het Amsterdamse adviesbureau ObjectVision had enige jaren daarvoor in opdracht van het Planbureau voor de Leefomgeving op basis van het AHN-1 en de Top10vector ten behoeve van het project GESO het 3DShapes bestand ontwikkeld, en dit er download up hun site aangeboden. uit de top een Na wat juridisch getouwtrek werd duidelijk dat 3D shapes inderdaad rechtenvrij (public domain) in OSM geïmporteerd kon worden. Daarmee veranderde het aanzien van OSM van alleen een wegenkaart naar een compleet topografisch bestand met bebouwingscontouren, grazige weilanden, vruchtbare akkers en eeuwig ruisende wouden.
Op de open data golf die sinds enige jaren ons land overspoeld kwam de BAG als een lekker hapje in beeld van de OSM-mappers. Rond 2011 verschenen de eerst suggesties op het OSM-forum om iets met de BAG te gaan doen. Likkebaardend vanwege de smaakvolle detaillering van middeleeuwse kathedralen zoals de Sint Jan. (zie ook in de OpenTopo kaarten van Jan-Willem van Aalst). Maar ook als vernieuwing van de toch al flink verouderde bebouwing uit 3DShapes. Die was immers gebaseerd op de Top10vector uit 2007, wat met de toenmalige updatefrequentie neerkwam op een bronjaar van pakweg 2005. Een periode waarin in suburbia de Vinexhuizen nog als paddenstoelen uit de grond schoten.
Niet alleen de eye-candy van die pandcontouren uit de BAG is interessant. De adressen zijn misschien nog wel waardevoller. Er zijn bovenop OpenStreetMap diverse routezoekers ontwikkeld. Om te zorgen dat je aan de goede kant van de Haagse Laan van Meerdervoort uitkomt is het wel erg handig als niet alleen straatnamen maar ook huisnummers in OSM zijn opgenomen. Weliswaar hadden sommige mappers al met de hand huisnummer toegevoegd, maar een import van de BAG is een heel aantrekkelijke manier om die 10 miljoen adressen in OSM te krijgen.
Op basis van flinke discussie op het forum en in een tweetal real-life sessies eind 2013 in Utrecht en voorjaar 2014 in Duivendrecht is er een methodiek ontwikkeld om de import gecontroleerd te laten verlopen. Geen niets ontziende import, maar onderzoekt alle dingen en behoudt het goede als leidraad. Een aanpak waar de Data Working Group (DWG) van de OpenStreetMap foundation ook op toe ziet (Ja, OpenStreetMap is veel gestructureerder en georganiseerder dan velen denken!). De complete werkwijze is vastgelegd op de Wiki, voor wie het nog eens wil naspelen.
Zo'n import roept allerlei vragen op. Moet je het überhaupt wel willen (ja: met name voor die routezoekerij is het wel erg handig als de data in OSM zélf zit), hoe ga je het bijhouden (de relevante ID's zijn mee-geïmporteerd uit de BAG, de methodiek wordt nog verder ontwikkeld), en wat is de volgende stap? De OSM-community kijkt nu al uit naar de Basisregistratie Grootschalige Topografie (BGT). Ik betwijfel of die net zo'n meerwaarde heeft. Waarom zou je OSM belasten met topografische detail voor een schaalniveau van pakweg 1:1000, terwijl OSM voor gebruik te voet, te paard of op de fiets eerder een 1:10.000 - 1:50.000 karakter heeft. Aan de andere kant, je ziet in OSM allerlei micro-mapping ontstaan, zoals in Artis en de Efteling.waar het BGT-detailniveau wel een handige basis voor is. We gaan het zien, want het leuke van OSM is juist dat de toekomst niet in beton is gegoten.
Die import deed ook op een andere manier de wenkbrouwen fronsen. De geometrievalidatie in OSM liegt er niet om, waardoor in sommige gemeenten het alarm erg vaak afging bij panden die elkaar een paar centimeter overlappen. Blijkbaar staan (sommige) BAG-beheer applicaties dat toe. Ook kwam de OSM-importeurs diverse gebouwen tegen die inmiddels niet meer bestaan. Met een serie terugmeldingen is met deze import actie de BAG zelf ook verbeterd.
Da's een mooie bijvangst, maar de mooiste bijvangst is dat alle acties rond deze import de Nederlandse OSM-community wat meer body heeft gegeven. Daar kan voor de verdere ontwikkeling van OSM in Nederland best wat moois uitkomen.
Ik ga er van uit dat ik bij de lezer het bestaan van OpenStreetMap niet hoef te introduceren. Wel is het handig te weten dat er ruwweg 3 manieren zijn waarop OpenStreetMap kan worden bijgehouden.
Gewapend met GPS wandelend of fietsen op pad, en onderweg nieuwe wegen en paden signaleren, nieuwe Points-of-Interest markeren etc. In landmeetkundige terminologie terrestrische inmeting, in OSM-taal "warme mapping". Al is die laatste term in guur novemberweer misschien wat vreemd. De aldus ingewonnen data wordt bij terugkomst op de thuisbasis (bij moeder de vrouw, of op buitenlandse hotelkamer) verwerkt en definitief in OSM gezet.
Het winterseizoen leent zich wellicht meer voor het thuis bij de kachel en met de poes op schoot aan de hand van luchtfoto's (BING, PDOK) intekenen van nieuwe of veranderde objecten. Deze fotogrammetrische vorm van OSM-data-inwinning is in Nederland minder relevant. De OSM-datadichtheid is al groot, en de wijzigingen in paden en lanen worden vaak sneller in het terrein opgemerkt en aangepast, dan via de vertragende omweg van luchtfoto's van enkele jaren oud. Maar misschien dat het begin 2015 via PDOK beschikbaar komen van luchtfotos'uit 2014 deze vorm van mapping ook in ons land nieuwe perspectieven biedf.
De derde vorm is de vorm waar ik in deze post wat dieper op in ga, het importeren van andere datasets.
In de Nederlandse OSM-historie zijn er 2 grote imports van externe data geweest. De eerste was het offer you can't refuse van autonavigatiebedrijf AND, dat in 2007 haar toenmalige dataset van Nederland, China en India ter integrale opname aanbood. Daarmee werd de Nederlandse in een klap van vele witte vlekken naar een landsbreed goed gevuld raamwerk van wegen. Wat bij veel mappers enthousiasme ontlokte om dan ook de fiets- en wandelpaden in OSM te krijgen.
Een tweede importgolf kwam in 2010. Het Amsterdamse adviesbureau ObjectVision had enige jaren daarvoor in opdracht van het Planbureau voor de Leefomgeving op basis van het AHN-1 en de Top10vector ten behoeve van het project GESO het 3DShapes bestand ontwikkeld, en dit er download up hun site aangeboden. uit de top een Na wat juridisch getouwtrek werd duidelijk dat 3D shapes inderdaad rechtenvrij (public domain) in OSM geïmporteerd kon worden. Daarmee veranderde het aanzien van OSM van alleen een wegenkaart naar een compleet topografisch bestand met bebouwingscontouren, grazige weilanden, vruchtbare akkers en eeuwig ruisende wouden.
Op de open data golf die sinds enige jaren ons land overspoeld kwam de BAG als een lekker hapje in beeld van de OSM-mappers. Rond 2011 verschenen de eerst suggesties op het OSM-forum om iets met de BAG te gaan doen. Likkebaardend vanwege de smaakvolle detaillering van middeleeuwse kathedralen zoals de Sint Jan. (zie ook in de OpenTopo kaarten van Jan-Willem van Aalst). Maar ook als vernieuwing van de toch al flink verouderde bebouwing uit 3DShapes. Die was immers gebaseerd op de Top10vector uit 2007, wat met de toenmalige updatefrequentie neerkwam op een bronjaar van pakweg 2005. Een periode waarin in suburbia de Vinexhuizen nog als paddenstoelen uit de grond schoten.
Niet alleen de eye-candy van die pandcontouren uit de BAG is interessant. De adressen zijn misschien nog wel waardevoller. Er zijn bovenop OpenStreetMap diverse routezoekers ontwikkeld. Om te zorgen dat je aan de goede kant van de Haagse Laan van Meerdervoort uitkomt is het wel erg handig als niet alleen straatnamen maar ook huisnummers in OSM zijn opgenomen. Weliswaar hadden sommige mappers al met de hand huisnummer toegevoegd, maar een import van de BAG is een heel aantrekkelijke manier om die 10 miljoen adressen in OSM te krijgen.
Op basis van flinke discussie op het forum en in een tweetal real-life sessies eind 2013 in Utrecht en voorjaar 2014 in Duivendrecht is er een methodiek ontwikkeld om de import gecontroleerd te laten verlopen. Geen niets ontziende import, maar onderzoekt alle dingen en behoudt het goede als leidraad. Een aanpak waar de Data Working Group (DWG) van de OpenStreetMap foundation ook op toe ziet (Ja, OpenStreetMap is veel gestructureerder en georganiseerder dan velen denken!). De complete werkwijze is vastgelegd op de Wiki, voor wie het nog eens wil naspelen.
Zo'n import roept allerlei vragen op. Moet je het überhaupt wel willen (ja: met name voor die routezoekerij is het wel erg handig als de data in OSM zélf zit), hoe ga je het bijhouden (de relevante ID's zijn mee-geïmporteerd uit de BAG, de methodiek wordt nog verder ontwikkeld), en wat is de volgende stap? De OSM-community kijkt nu al uit naar de Basisregistratie Grootschalige Topografie (BGT). Ik betwijfel of die net zo'n meerwaarde heeft. Waarom zou je OSM belasten met topografische detail voor een schaalniveau van pakweg 1:1000, terwijl OSM voor gebruik te voet, te paard of op de fiets eerder een 1:10.000 - 1:50.000 karakter heeft. Aan de andere kant, je ziet in OSM allerlei micro-mapping ontstaan, zoals in Artis en de Efteling.waar het BGT-detailniveau wel een handige basis voor is. We gaan het zien, want het leuke van OSM is juist dat de toekomst niet in beton is gegoten.
Die import deed ook op een andere manier de wenkbrouwen fronsen. De geometrievalidatie in OSM liegt er niet om, waardoor in sommige gemeenten het alarm erg vaak afging bij panden die elkaar een paar centimeter overlappen. Blijkbaar staan (sommige) BAG-beheer applicaties dat toe. Ook kwam de OSM-importeurs diverse gebouwen tegen die inmiddels niet meer bestaan. Met een serie terugmeldingen is met deze import actie de BAG zelf ook verbeterd.
Da's een mooie bijvangst, maar de mooiste bijvangst is dat alle acties rond deze import de Nederlandse OSM-community wat meer body heeft gegeven. Daar kan voor de verdere ontwikkeling van OSM in Nederland best wat moois uitkomen.
zondag 20 juli 2014
Met de BAG oude koeien uit de sloot halen
Onlangs had ik het al over het doen van meldingen, met name terugmeldingen op basisregistraties en andere geodata.
Vandaag had ik zelf te maken met een locatiegebonden melding: een noodgeval! Fietsend langs een kanaal ten zuiden van Amsterdam bemerkte mijn vriendin dat een koe het weiland waar haar zusters nog wel stonden had verlaten en in de aanpalende sloot was beland. Gezien de buitentemperatuur van circa 30 graden geen gekke gedachte van dit rund, maar de slootkant bleek toch wat te hoog om weer veilige veengrond onder de poten te krijgen.
Het dier leek ons niet direct in paniek, maar een seintje naar een hulpinstantie leek wel op zijn plaats. Tja, wie bel je dan? Dat niet-spoedeisende alarmnummer wil maar niet in mijn geheugen blijven plakken, en bovendien leek het ons geen goed plan de koe uren in de sloot te laten staan. Toch maar 1-1-2 gebeld dus. "Brandweer, politie of ambulance?", is dan de vraag die je moet beantwoorden. Dierenambulance was geen mogelijk antwoord (misschien maar goed ook, in mijn meest angstige gedachten komt dierenmishandelingsbestrijder Dion Graus dan gelijk mee), "politie" leek me het meest zinvol, de hermandad weet vast wel hoe ze de eigenaar kunnen opsporen en tot een reddingsactie kunnen aanzetten. Of, als de boer zomerreces heeft, de brandweer voor dit karretje kunnen spannen). Ik werd doorverbonden met de regionale politiemeldkamer.
Gelukkig stonden we langs het A.R kanaal exact bij kilometerpaaltje 16.0, dus over de locatie van de plek des onheils kon weinig misverstand ontstaan. Dacht ik. In welke woonplaats ik me bevond, vroeg de meldkamer. Aan den einder geen kerktoren te ontwaren, maar mijn parate topografische kennis mikte op halverwege B. en L. "Straatnaam?", vroeg de stem in mijn telefoon. Ik schatte het dichtstbijzijnde straatnaambord al gauw op enkele kilometers afstand. "Kanaaldijk", aan de westzijde, de kant van B. en L. probeerde ik voorzichtig. Aan de andere kant klonk een opgelucht "OK, Westkanaaldijk". Blijkbaar voorzag het ongetwijfeld door de BAG gevoede meldkamersysteem in een openbare ruimte-aanduiding met die naam!
Mijn vriendin kon het niet meer aanzien, en spring op de fiets in de richting van de dichtstbijzijnde zijweg. Die leidde na een kilometer naar een boerderij, waarvan de boer ook de eigenaar van het slachtoffer bleek te zijn. Al gauw kwam de trekker het land op gereden, waarna het dier met een lassoworp werd gevangen, en al gauw hand de boer zijn koeien op het droge.
Dit moet toch handiger kunnen! Mijn telefoon weet waar-ie is (zeker als ik ga fietsen, dan staat de GPS aan om mijn tochtje in Strava te registreren), dan hoef ik toch niet te gokken in welke woonplaats ik ben, en langs welke straat ik me bevind? Ja, in de bebouwde kom weet ik dat wel (al kan dat op de grens van pakweg Voorburg en Leidschendam nog best lastig zijn en licht verwarring tussen de Maasstraat in de Amsterdamse Rivierenbuurt, en de een kilometer noordelijk gelegen Nicolaas Maesstraat op de loer).
In de Google Playstore vind ik tientallen 112-apps, maar die blijken alleen maar een doorgeefluik van de meldingen in mijn buurt naar mijn telefoon. Iets Voor de lokale journalisten en andere sensatiezoekers dus.
Na 10 minuten googelen vind ik wel een als sinds 2011 bestaande 112-App van de Ambulancedienst Noord-Nederland, en van recenter datum een vergelijkbare App van de Regionale Ambulance Voorziening Brabant Midden-West-Noord (terzijde: wat is dát voor een bijzondere geografische aanduiding). Van die eerste zijn de recensies overwegend vernietigend, van die tweede zijn ze wel positief. En inderdaad: de app ziet er overzichtelijk uit, dus als ik in Midden-West-Noord-Noord-Brabant een ambulance nodig heb komt dat wel goed.
Een landelijke app, voor brandweer, politie én ambulance schijnt in de maak te zijn. Was zelfs al begin dit jaar verwacht. Mijn verwachtingen zijn hooggespannen. En tot die tijd ga ik het lassowerpen maar eens oefenen om indien nodig zelf oude koeien uit de sloot te kunnen halen.
Een paar geo-bemerkingen achteraf:
Die "Westkanaaldijk" klopte, maar gaat 400 meter verder wel over in de Kanaaldijk-West. Hoe verwarrend wil je het hebben. Vooral ook omdat de plaats van handeling noch B, noch L. bleek te zijn, maar juist in een uitstekende punt van woonplaats A. lag.
Een vergelijkbare geval had ik 2 jaar terug, langs een kanaal ten Noorden van Amsterdam. Daar had iemand een ambulance besteld voor de "Kanaaldijk, ter hoogte van W." Helaas bleek de weg aan de andere kant aan de andere kant van het water ook Kanaaldijk te heten, en zelfs ín woonplaats W. te liggen. U raadt het al: daar stoof de ambulance voorbij, aan de overkant van het kanaal. Mensen kennen bebouwde kommen, mensen kennen geen (BAG-)woonplaatsgrenzen.
In dit opzicht is de woonwijk Bijvanck, op de grens van Huizen en Blaricum, helemaal curieus; de gemeentegrens loopt dwars door de wijk en zelfs door sommige woningen. Knappe kop die daar weet te melden in welke BAG-woonplaats dat-ie staat.
Vandaag had ik zelf te maken met een locatiegebonden melding: een noodgeval! Fietsend langs een kanaal ten zuiden van Amsterdam bemerkte mijn vriendin dat een koe het weiland waar haar zusters nog wel stonden had verlaten en in de aanpalende sloot was beland. Gezien de buitentemperatuur van circa 30 graden geen gekke gedachte van dit rund, maar de slootkant bleek toch wat te hoog om weer veilige veengrond onder de poten te krijgen.
Het dier leek ons niet direct in paniek, maar een seintje naar een hulpinstantie leek wel op zijn plaats. Tja, wie bel je dan? Dat niet-spoedeisende alarmnummer wil maar niet in mijn geheugen blijven plakken, en bovendien leek het ons geen goed plan de koe uren in de sloot te laten staan. Toch maar 1-1-2 gebeld dus. "Brandweer, politie of ambulance?", is dan de vraag die je moet beantwoorden. Dierenambulance was geen mogelijk antwoord (misschien maar goed ook, in mijn meest angstige gedachten komt dierenmishandelingsbestrijder Dion Graus dan gelijk mee), "politie" leek me het meest zinvol, de hermandad weet vast wel hoe ze de eigenaar kunnen opsporen en tot een reddingsactie kunnen aanzetten. Of, als de boer zomerreces heeft, de brandweer voor dit karretje kunnen spannen). Ik werd doorverbonden met de regionale politiemeldkamer.
Gelukkig stonden we langs het A.R kanaal exact bij kilometerpaaltje 16.0, dus over de locatie van de plek des onheils kon weinig misverstand ontstaan. Dacht ik. In welke woonplaats ik me bevond, vroeg de meldkamer. Aan den einder geen kerktoren te ontwaren, maar mijn parate topografische kennis mikte op halverwege B. en L. "Straatnaam?", vroeg de stem in mijn telefoon. Ik schatte het dichtstbijzijnde straatnaambord al gauw op enkele kilometers afstand. "Kanaaldijk", aan de westzijde, de kant van B. en L. probeerde ik voorzichtig. Aan de andere kant klonk een opgelucht "OK, Westkanaaldijk". Blijkbaar voorzag het ongetwijfeld door de BAG gevoede meldkamersysteem in een openbare ruimte-aanduiding met die naam!
Mijn vriendin kon het niet meer aanzien, en spring op de fiets in de richting van de dichtstbijzijnde zijweg. Die leidde na een kilometer naar een boerderij, waarvan de boer ook de eigenaar van het slachtoffer bleek te zijn. Al gauw kwam de trekker het land op gereden, waarna het dier met een lassoworp werd gevangen, en al gauw hand de boer zijn koeien op het droge.
Dit moet toch handiger kunnen! Mijn telefoon weet waar-ie is (zeker als ik ga fietsen, dan staat de GPS aan om mijn tochtje in Strava te registreren), dan hoef ik toch niet te gokken in welke woonplaats ik ben, en langs welke straat ik me bevind? Ja, in de bebouwde kom weet ik dat wel (al kan dat op de grens van pakweg Voorburg en Leidschendam nog best lastig zijn en licht verwarring tussen de Maasstraat in de Amsterdamse Rivierenbuurt, en de een kilometer noordelijk gelegen Nicolaas Maesstraat op de loer).
In de Google Playstore vind ik tientallen 112-apps, maar die blijken alleen maar een doorgeefluik van de meldingen in mijn buurt naar mijn telefoon. Iets Voor de lokale journalisten en andere sensatiezoekers dus.
Na 10 minuten googelen vind ik wel een als sinds 2011 bestaande 112-App van de Ambulancedienst Noord-Nederland, en van recenter datum een vergelijkbare App van de Regionale Ambulance Voorziening Brabant Midden-West-Noord (terzijde: wat is dát voor een bijzondere geografische aanduiding). Van die eerste zijn de recensies overwegend vernietigend, van die tweede zijn ze wel positief. En inderdaad: de app ziet er overzichtelijk uit, dus als ik in Midden-West-Noord-Noord-Brabant een ambulance nodig heb komt dat wel goed.
Een landelijke app, voor brandweer, politie én ambulance schijnt in de maak te zijn. Was zelfs al begin dit jaar verwacht. Mijn verwachtingen zijn hooggespannen. En tot die tijd ga ik het lassowerpen maar eens oefenen om indien nodig zelf oude koeien uit de sloot te kunnen halen.
Een paar geo-bemerkingen achteraf:
Die "Westkanaaldijk" klopte, maar gaat 400 meter verder wel over in de Kanaaldijk-West. Hoe verwarrend wil je het hebben. Vooral ook omdat de plaats van handeling noch B, noch L. bleek te zijn, maar juist in een uitstekende punt van woonplaats A. lag.
Een vergelijkbare geval had ik 2 jaar terug, langs een kanaal ten Noorden van Amsterdam. Daar had iemand een ambulance besteld voor de "Kanaaldijk, ter hoogte van W." Helaas bleek de weg aan de andere kant aan de andere kant van het water ook Kanaaldijk te heten, en zelfs ín woonplaats W. te liggen. U raadt het al: daar stoof de ambulance voorbij, aan de overkant van het kanaal. Mensen kennen bebouwde kommen, mensen kennen geen (BAG-)woonplaatsgrenzen.
In dit opzicht is de woonwijk Bijvanck, op de grens van Huizen en Blaricum, helemaal curieus; de gemeentegrens loopt dwars door de wijk en zelfs door sommige woningen. Knappe kop die daar weet te melden in welke BAG-woonplaats dat-ie staat.
zondag 13 juli 2014
Melden is goed, repareren is beter! De 6e en 7e ster van Tim Berners-Lee
Een terugmelding doen op de BAG is van een andere orde dan zélf een onvolkomenheid in OpenStreetMap rechtbreien. Bij de makers van MapInfo, GeoMedia of ArcGIS melden dat er een weeffoutje zit in hun software is iets anders dan zélf zo'n weeffoutje in QGis herstellen. Melden is goed, repareren is beter!
Het leuke is dat dit principe in de maatschappij langzaamaan gemeengoed wordt. Langzaamaan, want we zitten op veel plaatsen pas in de stand van het melden van "bugs": de klassieke kapotte lantaarnpaal, de exemplarische scheefliggende stoeptegel. Met dank aan verbeterdebuurt.nl en andere MOR-apps (vakjargon voor Meldingen Openbare Ruimte) sporen gemeenten hun burgers aan hun klagen over die onvolkomenheden van de dagelijkse leefomgeving te melden aan het (digitale) gemeentelijk loket.
De échte participatiemaatschappij begint echter pas bij door buurtbewoners adopteren van de plaatselijke afvalcontainer of het in de straat gelegen plantsoen. Dat laatste levert op diverse plaatsen in Nederland niet alleen tuiniervreugde maar ook prachtige stukken openbaar groen op, tegen een prijs waarvoor de gemeentelijke groendienst niet verder komt dan het één keer per maand met de grasmaaier over een armetierig stoppelveldje rijden.
Zo beschouwd is niet open data het data-equivalent van open source software, maar crowdsourced data. Hoe ver wil je, of durf je als data-eigenaar te gaan met het ter verbetering open stellen van data? Is een terugmeldingsvoorziening (met daar achter een backoffice) de zesde ster in het model van Tim Berners-Lee? En dan is crowdsourced data de zevende!
Doe bijvoorbeeld eerst eens een terugmelding op de terugmelding BAG of BRT, en doe daarna een edit op OpenStreetMap. Die eerste geeft een gevoel van goed burgerschap, maar bij die tweede geeft het echt een kick om jouw eigen edit na enige uren (in de diverse tiled lagen) op www.openstreetmap.org terug te zien.
Goed om te zien dat Kadaster druk bezig is met het verder uitnutten van de terugmeldfaciliteit. De resultaten van de pilot zijn hier te zien, de komende maande wordt gekeken hoe de terugmeldfaciliteit voor 't echie vorm kan worden gegeven. Ben benieuwd of dat een zes- of zeven sterren variant wordt!
Het leuke is dat dit principe in de maatschappij langzaamaan gemeengoed wordt. Langzaamaan, want we zitten op veel plaatsen pas in de stand van het melden van "bugs": de klassieke kapotte lantaarnpaal, de exemplarische scheefliggende stoeptegel. Met dank aan verbeterdebuurt.nl en andere MOR-apps (vakjargon voor Meldingen Openbare Ruimte) sporen gemeenten hun burgers aan hun klagen over die onvolkomenheden van de dagelijkse leefomgeving te melden aan het (digitale) gemeentelijk loket.
De échte participatiemaatschappij begint echter pas bij door buurtbewoners adopteren van de plaatselijke afvalcontainer of het in de straat gelegen plantsoen. Dat laatste levert op diverse plaatsen in Nederland niet alleen tuiniervreugde maar ook prachtige stukken openbaar groen op, tegen een prijs waarvoor de gemeentelijke groendienst niet verder komt dan het één keer per maand met de grasmaaier over een armetierig stoppelveldje rijden.
Zo beschouwd is niet open data het data-equivalent van open source software, maar crowdsourced data. Hoe ver wil je, of durf je als data-eigenaar te gaan met het ter verbetering open stellen van data? Is een terugmeldingsvoorziening (met daar achter een backoffice) de zesde ster in het model van Tim Berners-Lee? En dan is crowdsourced data de zevende!
Doe bijvoorbeeld eerst eens een terugmelding op de terugmelding BAG of BRT, en doe daarna een edit op OpenStreetMap. Die eerste geeft een gevoel van goed burgerschap, maar bij die tweede geeft het echt een kick om jouw eigen edit na enige uren (in de diverse tiled lagen) op www.openstreetmap.org terug te zien.
Goed om te zien dat Kadaster druk bezig is met het verder uitnutten van de terugmeldfaciliteit. De resultaten van de pilot zijn hier te zien, de komende maande wordt gekeken hoe de terugmeldfaciliteit voor 't echie vorm kan worden gegeven. Ben benieuwd of dat een zes- of zeven sterren variant wordt!
zaterdag 15 maart 2014
Verbeteren of echt verníeuwen? Open data als aanjager voor de doe-democratie
Een poosje terug las ik de column van Marian Donner in NRC Next (lees 'm hier) de rake zinsnede "ooit droomden techneuten van bewoonbare ruimtestations, nu dromen ze van de snelste en leukste manier om cappuccino te bestellen.".
Heel erg herkenbaar, ook in "open dataland" waar we dankzij de vrijelijk stromende data gemakkelijker een WC of Wipkip vinden, nooit meer in het spoorboekje hoeven te bladeren op zoek naar de treintijden, en de melding "scheefstaande lantaarnpaal" of "kapotte stoeptegel" (of was het andersom) nog nooit snel richting de backoffice van de gemeentelijke organisatie hebben gekregen. (een combinatie van bovenstaande kan ook: de App "treintoilet" toont welke treinen wel of geen WC aan boord hebben).
Op zich allemaal nuttige toepassingen met vooral een hoog lifehacking gehalte: bestaande handelingen of processen een stukje gemakkelijker maken, een beetje verbeteren. Net zoals je tegenwoordig in ieder GIS-pakket met Python een scriptje in elkaar draait om die immer terugkerende routineklus met de spreekwoordelijke druk op de knop uit te kunnen voeren. En zoals de stofzuiger tegenwoordig zelf zijn weg door het huis vindt, in plaats van dat je -alsof je in een clip van Queen speelt- dat apparaat aan dehand stang mee moet nemen op zijn weg door woon- en slaapkamer.
Maar valt er met die open data nou niet méér te doen dan die verbeteringen? Kunnen er nou niet échte vernieuwingen mee tot stand worden gebracht? Werkt dat wellicht alleen wanneer open data een rol speelt in tweerichtingsverkeer, bijvoorbeeld in een crowdsourcing context? Zoals nu gebeurt met OpenStreetMap (OSM), waar de panden en adressen uit de BAG worden geïmporteerd, maar wel zodanig gecontroleerd dat OSM straks wellicht "een betere BAG dan de BAG" bevat. Open data als aanjager voor het actief krijgen van die burgers die nu alleen reactief melden dat het huisvuil weer eens niet is opgehaald. En zo steeds meer opschuiven van informeren, inspraak en burgerparticipatie naar burgerinitiatief, zelfbeheer en meer van dat moois. Als je er zo naar kijkt is open data hét middel om tot een compacte overheid te komen, maar dat zie ik in weinig liberale gemeentelijke verkiezingsprogramma's terug.
Voor de geo-beroepsgroep én voor iedereen die met open data bezig is kan ik het rapport "Deel je rijk" uit 2013 aanraden. De ondertitel "relevante trends voor overheidsinformatie" laat het misschien niet direct blijken, maar van de 37 gesignaleerde trends heeft zeker de helft een directe relatie met open data, user generated content, of met platforms voor samenwerking. En ofschoon geschreven vanuit de impact voor de Rijksoverheid is het rapport net zo gemakkelijk te projecteren op provincies en gemeenten.
Heel erg herkenbaar, ook in "open dataland" waar we dankzij de vrijelijk stromende data gemakkelijker een WC of Wipkip vinden, nooit meer in het spoorboekje hoeven te bladeren op zoek naar de treintijden, en de melding "scheefstaande lantaarnpaal" of "kapotte stoeptegel" (of was het andersom) nog nooit snel richting de backoffice van de gemeentelijke organisatie hebben gekregen. (een combinatie van bovenstaande kan ook: de App "treintoilet" toont welke treinen wel of geen WC aan boord hebben).
Op zich allemaal nuttige toepassingen met vooral een hoog lifehacking gehalte: bestaande handelingen of processen een stukje gemakkelijker maken, een beetje verbeteren. Net zoals je tegenwoordig in ieder GIS-pakket met Python een scriptje in elkaar draait om die immer terugkerende routineklus met de spreekwoordelijke druk op de knop uit te kunnen voeren. En zoals de stofzuiger tegenwoordig zelf zijn weg door het huis vindt, in plaats van dat je -alsof je in een clip van Queen speelt- dat apparaat aan de
Maar valt er met die open data nou niet méér te doen dan die verbeteringen? Kunnen er nou niet échte vernieuwingen mee tot stand worden gebracht? Werkt dat wellicht alleen wanneer open data een rol speelt in tweerichtingsverkeer, bijvoorbeeld in een crowdsourcing context? Zoals nu gebeurt met OpenStreetMap (OSM), waar de panden en adressen uit de BAG worden geïmporteerd, maar wel zodanig gecontroleerd dat OSM straks wellicht "een betere BAG dan de BAG" bevat. Open data als aanjager voor het actief krijgen van die burgers die nu alleen reactief melden dat het huisvuil weer eens niet is opgehaald. En zo steeds meer opschuiven van informeren, inspraak en burgerparticipatie naar burgerinitiatief, zelfbeheer en meer van dat moois. Als je er zo naar kijkt is open data hét middel om tot een compacte overheid te komen, maar dat zie ik in weinig liberale gemeentelijke verkiezingsprogramma's terug.
Voor de geo-beroepsgroep én voor iedereen die met open data bezig is kan ik het rapport "Deel je rijk" uit 2013 aanraden. De ondertitel "relevante trends voor overheidsinformatie" laat het misschien niet direct blijken, maar van de 37 gesignaleerde trends heeft zeker de helft een directe relatie met open data, user generated content, of met platforms voor samenwerking. En ofschoon geschreven vanuit de impact voor de Rijksoverheid is het rapport net zo gemakkelijk te projecteren op provincies en gemeenten.
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!
woensdag 17 oktober 2012
"Waar is de BAG, hier is de BAG!" : de BAG als ultieme geocache
Sinds de brede verspreiding van goedkope GPS ontvangers is geocaching een populair tijdverdrijf geworden: verstop een schat in een holle boom, gat in de grond of onder je deurmat, en geef wat aanwijzingen waarmee de schatzoekers op pad kunnen gaan. Die aanwijzingen kunnen de coördinaten van de vindplaats zijn, maar leuker en spannender is het als er tussendoor puzzels moeten worden opgelost, opdrachten worden vervuld en wat al niet meer.
Terzijde wat historisch besef: Kees van Kooten en Wim de Bie introduceerden het fenomeen in 1984 door een kistje met een duizendje (gulden!) bij de Pyramide van Austerlitz te begraven. Dat gaf 's nachts nogal wat reuring op de Utrechtse Heuvelrug, zoals het "Volksdagblad de Waarheid" de dag er na berichtte. Andere tijden!
Voor App bouwers die met open data aan de slag willen is een lijst met coördinaten van de Nederlandse adressen de ultieme heilige graal. Aangezien de rijksoverheid openheid en waardecreatie heel belangrijk vind is de basisregistratie adressen en gebouwen (BAG) als open data beschikbaar gesteld. Nou ja, je moest nog wel even 150 euro bij wijze van verstrekkingskosten bij het Kadaster achterlaten, en per maandelijkse update nog eens 10 euro betalen. Maar daar krijg je wel 8 miljoen adressen voor terug, dus per adres eigenlijk een schijntje.
Sinds medio juni kun je die 150 euro en dat maandelijkse tientje in de pocket houden door gebruik te maken van de gratis versie zoals aangeboden door de geomotor van Nederland: PDOK. Om het leuk en spannend te maken moet je ook hier wat raadsels oplossen.
Na je vingers blauw getypt te hebben aan de URL www.nationaalgeoregister.nl en vervolgens "adressen" als zoekterm te hebben ingevoerd verschijnt een lijstje van 18 hits. Eentje scoort een relevantie van 100%, de overige 17 0%. Dat zou je op het verkeerde been kunnen zetten, gewoon negeren is het beste. In de top 5 staan een "Inspire View Service PDOK voor (..) adressen (..)", "adressen", "adressen WMS", "Inspire adressen WFS", en op 5 de eerste commerciële aanbieder (BridGIS) met "adresservice".
Die "view service" en "WMS" (beide van de Rijksoverheid) blijken evenals de "adressen" van Kadaster services te zijn die alleen een plaatje opleveren, waarvan de URL die naar de webservice stuit op een "error 404 - not found". Vooruit, een aanwijzing: type "request=getcapabilites" achter die URL en je krijgt er wel allerlei inhoudelijke en technische informatie over.
Maar we willen echte data, dus die WFS lijkt wel wat. en inderdaad, na wat gepuzzle levert de URL http://geodata.nationaalgeoregister.nl/inspireadressen/wfs?request=getFeature&typename=inspireadressen&outputformat=JSON 4Mb aan download op. Helaas levert het PDOK motortje maximaal 15.000 objecten per request, dus om via deze weg heel Nederland bij elkaar te sparen moet je zo'n 1000 requests afvuren en daarbij bijvoorbeeld telkens een andere bounding box opgeven. Dat gaat 'm niet worden.
Nog even terug naar de NGR-hitlist dan maar, en verdomd, verstopt op nummer 7 staat daar een "Inspire Download Service van adressen (inspire adressen)". klikkerdeklik, dat leidt naar http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml Kijk, nu wordt het wat: complete BAG-n van een 4 tal datums, met als meest recente 8 augustus. Downloaden maar, en ja hoor, en stroomt 1.3 Gb naar binnen. Die kwantiteit is een goed voorteken! Na unzippen blijkt er naast 7 ZIPfiles een leveringsdocument-BAG-extract.xml in te zitten. Als ik daar in puzzel zie ik onder meer dat het draaimoment van deze dataset 8 augustus, half tien 's ochtends is.
(Wanneer de volgende zending komt is niet geheel duidelijk; er zat een regelmaat van 1x per maand in, na 8 augustus is de aanvoer stilgevallen. Als het goed is hoor ik binnenkort van het Kadaster meer over het leveringsplan)
Maar liefst 7 zipfiles heb ik nu. Eén met STA in de naam, een NUM, een PND een OPR een WPL, een LIG en een VBO. Dankzij Herko Coomans' onvolprezen "Hitchhikers Guide to the BAG" weet ik dat er nummers, panden, woonplaatsen, verblijfsobjecten, standplaatsen en ligplaatsen in moeten zitten, dus dat puzzeltje valt ook wel op te lossen.
Nog wel wat lastig dat die 7 zips soms weer uit meer dan één XML met de echte inhoud bestaan, omdat er een maximale grootte van 20 Mb per bestand is gehanteerd, dus dat weer even aan elkaar metselen. Gelukkig is er voor die technische puzzels uit de vorig alinea een kant-en-klare oplossing om het hele spul in een PostGIS database te prakken: nlextract.
Kortom, de geocache die BAG heet is gevonden. Champagne, ballonnen! Op nar de volgende geoschat, want zo'n inhoudeljke en technische geospeurtocht smaakt naar meer.
(voordeze usecase het verslag van deze "geocache" heb ik me onder meer laten inspireren door Erik Romijn's verhaal "De Weg Kwijt? De Zoektocht van een App Maker door Geo-informatiesystemen" op de OSGeo.nl dag op 28 juni in Velp en vele vragen op Twitter en LinkedIn van "neo-geo's die zich een slag in de rondte zochten naar de BAG.
Terzijde wat historisch besef: Kees van Kooten en Wim de Bie introduceerden het fenomeen in 1984 door een kistje met een duizendje (gulden!) bij de Pyramide van Austerlitz te begraven. Dat gaf 's nachts nogal wat reuring op de Utrechtse Heuvelrug, zoals het "Volksdagblad de Waarheid" de dag er na berichtte. Andere tijden!
Voor App bouwers die met open data aan de slag willen is een lijst met coördinaten van de Nederlandse adressen de ultieme heilige graal. Aangezien de rijksoverheid openheid en waardecreatie heel belangrijk vind is de basisregistratie adressen en gebouwen (BAG) als open data beschikbaar gesteld. Nou ja, je moest nog wel even 150 euro bij wijze van verstrekkingskosten bij het Kadaster achterlaten, en per maandelijkse update nog eens 10 euro betalen. Maar daar krijg je wel 8 miljoen adressen voor terug, dus per adres eigenlijk een schijntje.
Sinds medio juni kun je die 150 euro en dat maandelijkse tientje in de pocket houden door gebruik te maken van de gratis versie zoals aangeboden door de geomotor van Nederland: PDOK. Om het leuk en spannend te maken moet je ook hier wat raadsels oplossen.
Na je vingers blauw getypt te hebben aan de URL www.nationaalgeoregister.nl en vervolgens "adressen" als zoekterm te hebben ingevoerd verschijnt een lijstje van 18 hits. Eentje scoort een relevantie van 100%, de overige 17 0%. Dat zou je op het verkeerde been kunnen zetten, gewoon negeren is het beste. In de top 5 staan een "Inspire View Service PDOK voor (..) adressen (..)", "adressen", "adressen WMS", "Inspire adressen WFS", en op 5 de eerste commerciële aanbieder (BridGIS) met "adresservice".
Die "view service" en "WMS" (beide van de Rijksoverheid) blijken evenals de "adressen" van Kadaster services te zijn die alleen een plaatje opleveren, waarvan de URL die naar de webservice stuit op een "error 404 - not found". Vooruit, een aanwijzing: type "request=getcapabilites" achter die URL en je krijgt er wel allerlei inhoudelijke en technische informatie over.
Maar we willen echte data, dus die WFS lijkt wel wat. en inderdaad, na wat gepuzzle levert de URL http://geodata.nationaalgeoregister.nl/inspireadressen/wfs?request=getFeature&typename=inspireadressen&outputformat=JSON 4Mb aan download op. Helaas levert het PDOK motortje maximaal 15.000 objecten per request, dus om via deze weg heel Nederland bij elkaar te sparen moet je zo'n 1000 requests afvuren en daarbij bijvoorbeeld telkens een andere bounding box opgeven. Dat gaat 'm niet worden.
Nog even terug naar de NGR-hitlist dan maar, en verdomd, verstopt op nummer 7 staat daar een "Inspire Download Service van adressen (inspire adressen)". klikkerdeklik, dat leidt naar http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml Kijk, nu wordt het wat: complete BAG-n van een 4 tal datums, met als meest recente 8 augustus. Downloaden maar, en ja hoor, en stroomt 1.3 Gb naar binnen. Die kwantiteit is een goed voorteken! Na unzippen blijkt er naast 7 ZIPfiles een leveringsdocument-BAG-extract.xml in te zitten. Als ik daar in puzzel zie ik onder meer dat het draaimoment van deze dataset 8 augustus, half tien 's ochtends is.
(Wanneer de volgende zending komt is niet geheel duidelijk; er zat een regelmaat van 1x per maand in, na 8 augustus is de aanvoer stilgevallen. Als het goed is hoor ik binnenkort van het Kadaster meer over het leveringsplan)
Maar liefst 7 zipfiles heb ik nu. Eén met STA in de naam, een NUM, een PND een OPR een WPL, een LIG en een VBO. Dankzij Herko Coomans' onvolprezen "Hitchhikers Guide to the BAG" weet ik dat er nummers, panden, woonplaatsen, verblijfsobjecten, standplaatsen en ligplaatsen in moeten zitten, dus dat puzzeltje valt ook wel op te lossen.
Nog wel wat lastig dat die 7 zips soms weer uit meer dan één XML met de echte inhoud bestaan, omdat er een maximale grootte van 20 Mb per bestand is gehanteerd, dus dat weer even aan elkaar metselen. Gelukkig is er voor die technische puzzels uit de vorig alinea een kant-en-klare oplossing om het hele spul in een PostGIS database te prakken: nlextract.
Kortom, de geocache die BAG heet is gevonden. Champagne, ballonnen! Op nar de volgende geoschat, want zo'n inhoudeljke en technische geospeurtocht smaakt naar meer.
(voor
woensdag 18 mei 2011
Google Maps zit er ook wel eens naast
Op mijn nog redelijk nieuwe (per 1 april) werk bij de gemeente Den Haag staan de verhuisdozen klaar om op 6 juni de stap naar het nieuwe stadskantoor aan de Leyweg nummer 813 te kunnen maken. Mooi gebouw, maar is het ook te vinden?
Van de week wees collega Gert-Willem me er op dat dit adres in Google Maps op de verkeerde plek wordt weergegeven. Het adres is nog zo vers dat het niet in het bestand ACN van het Kadaster zit. Google Maps wil dat gemis oplossen door dan maar te kijken wat het dichtstbijzijnde nummer is en nummer 813 daar naast te prikken. Helaas gaat die vlieger hier niet op: de nummers 812 en 814 liggen door de enorm ongelijke nummering aan de even en oneven zijde van de Leyweg zo'n 500 meter bij nummer 813 vandaan.
Zie de kaart, nummer 813 ligt in werkelijkheid nog voorbij de Melis Stokelaan.
Ook 9292ov geeft me daardoor een verkeerd reisadvies. Als ik aangeraden wordt bij de halte met de prozaïsche naam "Zuidwoldepad" uit te stappen is het geen 11 minuten lopen naar mijn nieuwe werkplek, zoals de OV-reisinformatie inschat, maar blijkt het een wandeling van 20 minuten te zijn. En ook het klassieke "bestemming bereikt" van TomTom zal het niet worden: in ieder geval de online planner zet me aan het begin van de Leyweg af, maar die is 2500 meter lang, en nummer 813 ligt halverwege. Nu maar hopen dat de verhuizers wél op de juiste bestemming aankomen, want anders is het nog een flink eind sjouwen met die verhuisdozen.
Uiteraard is ons eigen Haagse Den Haag op de Kaart wel op onze actuele adresinformatie gebaseerd:
Daarom nog een aanwijzing voor de heren verhuizers (ja, sorry ik heb nog nooit een verhuisster gezien): We zitten aan de Leyweg tegenover nummer 1190. En ach, je ziet dit fantastische gebouw ook niet snel over het hoofd:
Update:
Leyweg 813 zit in de najaarslevering (oktober) van het ACN.
Overigens geeft Bing Maps 2 hits bij dit adres: een op de geinterpoleerde plek waar Google Maps 'm ook zet, en een op vrijwel de juiste plek. Handmatig toegevoegd? (dat hebben we voor Den Haag op de kaart tijden geleden ook al gedaan, met de stap naar de BAG zijn we nog bezig)
Van de week wees collega Gert-Willem me er op dat dit adres in Google Maps op de verkeerde plek wordt weergegeven. Het adres is nog zo vers dat het niet in het bestand ACN van het Kadaster zit. Google Maps wil dat gemis oplossen door dan maar te kijken wat het dichtstbijzijnde nummer is en nummer 813 daar naast te prikken. Helaas gaat die vlieger hier niet op: de nummers 812 en 814 liggen door de enorm ongelijke nummering aan de even en oneven zijde van de Leyweg zo'n 500 meter bij nummer 813 vandaan.
Zie de kaart, nummer 813 ligt in werkelijkheid nog voorbij de Melis Stokelaan.
Ook 9292ov geeft me daardoor een verkeerd reisadvies. Als ik aangeraden wordt bij de halte met de prozaïsche naam "Zuidwoldepad" uit te stappen is het geen 11 minuten lopen naar mijn nieuwe werkplek, zoals de OV-reisinformatie inschat, maar blijkt het een wandeling van 20 minuten te zijn. En ook het klassieke "bestemming bereikt" van TomTom zal het niet worden: in ieder geval de online planner zet me aan het begin van de Leyweg af, maar die is 2500 meter lang, en nummer 813 ligt halverwege. Nu maar hopen dat de verhuizers wél op de juiste bestemming aankomen, want anders is het nog een flink eind sjouwen met die verhuisdozen.
Uiteraard is ons eigen Haagse Den Haag op de Kaart wel op onze actuele adresinformatie gebaseerd:
Daarom nog een aanwijzing voor de heren verhuizers (ja, sorry ik heb nog nooit een verhuisster gezien): We zitten aan de Leyweg tegenover nummer 1190. En ach, je ziet dit fantastische gebouw ook niet snel over het hoofd:
Update:
Leyweg 813 zit in de najaarslevering (oktober) van het ACN.
Overigens geeft Bing Maps 2 hits bij dit adres: een op de geinterpoleerde plek waar Google Maps 'm ook zet, en een op vrijwel de juiste plek. Handmatig toegevoegd? (dat hebben we voor Den Haag op de kaart tijden geleden ook al gedaan, met de stap naar de BAG zijn we nog bezig)
zaterdag 29 januari 2011
Nog meer Open Data: Wat de BAG wel en niet vermag
Het heugelijke feit dat vrijwel alle Nederlandse gemeenten zijn aangesloten op de landelijke voorziening (LV) van de BAG zet de creatieve geesten in de geowereld aan tot het bedenken van vrolijke BAG toepassingen. Het weergeven van de groei van steden is dan een leuke toepassing.
Geodan brengt de ontwikkeling van Amsterdam in beeld (een thuiswedstrijd):
Het Groningse GEON doet dat voor van Rotterdam:
Sowieso leuk om de fimpjes qua vormgeving te vergelijken, maar als Amsterdammer ben ik wellicht bevooroordeeld. Ik vind daar de tijdlijn met 1901 (Woningwet) en 1940 (WO II) als markante punten prettig. En het in de loop der tijd verschijnen van gebouwen is veel indringender dan het vertalen naar een grid of het met behulp van een choropleet op basis van wijk- en buurtindeling weergeven van de bebouwingsontwikkeling.
Inhoudelijk vallen mij 2 dingen op. Ten eerste dat sommige gebouwen volgens de BAG veel ouder zijn dan volgens mijn inschatting: het AMC en winkelcentrum de Amsterdamse Poort (beide in in Amsterdam Zuidoost) ploppen al in 1900 tevoorschijn, in plaats van in de jaren tachtig van de vorige eeuw. Selectiefoutje? Of is het feit dat dit deel van Amsterdam nog heel lang gemeente Weesperkarspel is geweest de boosdoener? Leuk is wel dat door het in deze context te zien dit soort foutjes sneller in het oog springen.
Ten tweede loop je tegen een belangrijke beperking voor zo'n toepassing aan: de BAG bevat (nog) geen historie. Kijk bijvoorbeeld naar de ontstaansgeschiedenis van de hoofdstedelijke voetbalstadions. Jan Wils zijn Olympische creatie verschijnt keurig in 1928 in beeld, maar het tegenoverliggende Stadion uit 1914, dat in 1928 is afgebroken, komt niet in beeld. Zo ook met de Meer aan de Middenweg. Dit door Daan Roodenburgh ontworpen stadion is in 1934 geopend en in 1996, na Ajax' overstap naar de Arena gesloopt. De Arena zien we in 1996 verschijnen, maar de Meer is uit ons geheugen verbannen. *)
(Gelukkig maar dat met UAR (Urban Augmented Reality) het mooiste voetbalstadion van Nederland wél voor het nageslacht is vastgelegd.)
De Rotterdamse voetbalstadions hebben wat meer eeuwigheidswaarde, maar in "010" valt op dat de BAG het bombardement van 1940 niet als trednbreuk herkent. En ook het dorp Blankenburg, dat in de jaren zestig plaats heeft moeten maken voor de Europoort, zit niet in het BAG geheugen.
Nou ja, voor het historisch bewustzijn dus ook nog maar even kijken op de WatWasWaarKaart
*) om het compleet te maken moet ik hier ook de thuisbasis van de Volewijckers in Amsterdam Noord noemen: het stadion aan het Mosveld is in de jaren zestig ten prooi gevallen aan een toegangsweg voor de IJtunnel. Ook deze groenwitte historie vinden we niet terug in de BAG
Geodan brengt de ontwikkeling van Amsterdam in beeld (een thuiswedstrijd):
Het Groningse GEON doet dat voor van Rotterdam:
Sowieso leuk om de fimpjes qua vormgeving te vergelijken, maar als Amsterdammer ben ik wellicht bevooroordeeld. Ik vind daar de tijdlijn met 1901 (Woningwet) en 1940 (WO II) als markante punten prettig. En het in de loop der tijd verschijnen van gebouwen is veel indringender dan het vertalen naar een grid of het met behulp van een choropleet op basis van wijk- en buurtindeling weergeven van de bebouwingsontwikkeling.
Inhoudelijk vallen mij 2 dingen op. Ten eerste dat sommige gebouwen volgens de BAG veel ouder zijn dan volgens mijn inschatting: het AMC en winkelcentrum de Amsterdamse Poort (beide in in Amsterdam Zuidoost) ploppen al in 1900 tevoorschijn, in plaats van in de jaren tachtig van de vorige eeuw. Selectiefoutje? Of is het feit dat dit deel van Amsterdam nog heel lang gemeente Weesperkarspel is geweest de boosdoener? Leuk is wel dat door het in deze context te zien dit soort foutjes sneller in het oog springen.
Ten tweede loop je tegen een belangrijke beperking voor zo'n toepassing aan: de BAG bevat (nog) geen historie. Kijk bijvoorbeeld naar de ontstaansgeschiedenis van de hoofdstedelijke voetbalstadions. Jan Wils zijn Olympische creatie verschijnt keurig in 1928 in beeld, maar het tegenoverliggende Stadion uit 1914, dat in 1928 is afgebroken, komt niet in beeld. Zo ook met de Meer aan de Middenweg. Dit door Daan Roodenburgh ontworpen stadion is in 1934 geopend en in 1996, na Ajax' overstap naar de Arena gesloopt. De Arena zien we in 1996 verschijnen, maar de Meer is uit ons geheugen verbannen. *)
(Gelukkig maar dat met UAR (Urban Augmented Reality) het mooiste voetbalstadion van Nederland wél voor het nageslacht is vastgelegd.)
De Rotterdamse voetbalstadions hebben wat meer eeuwigheidswaarde, maar in "010" valt op dat de BAG het bombardement van 1940 niet als trednbreuk herkent. En ook het dorp Blankenburg, dat in de jaren zestig plaats heeft moeten maken voor de Europoort, zit niet in het BAG geheugen.
Nou ja, voor het historisch bewustzijn dus ook nog maar even kijken op de WatWasWaarKaart
*) om het compleet te maken moet ik hier ook de thuisbasis van de Volewijckers in Amsterdam Noord noemen: het stadion aan het Mosveld is in de jaren zestig ten prooi gevallen aan een toegangsweg voor de IJtunnel. Ook deze groenwitte historie vinden we niet terug in de BAG
Abonneren op:
Posts (Atom)