[OSM-talk-nl] BAG (Was: Diverse vragen)

Martijn van Exel m at rtijn.org
Mon Aug 29 20:42:29 UTC 2011


I2011/8/29 Oliver Heesakkers <osm2 at heesakkers.info>:
> Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel:
>> 2011/8/28 Nico Witteman <nico at wittyman.nl>:
>> >(...)
>>
>> > 2.       Zijn er plannen om de huisnummers van BAG-viewer
>> > http://bagviewer.geodan.nl/index.html te gaan importeren?
>>
>> Zie het mailinglijst-archief, er zijn volgens mij geen concrete
>> plannen om de BAG-huisnummers te importeren.
>> Ik ben er geen voorstander van. Bij een import moet je ook nadenken
>> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt
>> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol
>> als je ook die mutaties opneemt. Maar hoe moet dat dan met
>> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt?
>> Dat zijn moeilijke vragen.
>>
>
> Is er sinds die discussie / call to arms eind mei uberhaupt nog iets
> ondernomen op dit gebied?
>
> Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De
> nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien zijn
> het juist de regelmatige updates die deze informatie waardevoller maken dan
> 3dShapes.
> Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu
> al gruwelijk achterhaald.
> Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar
> juist BAG-data voldoet aan een basis wens voor de moderne navigatie-gebruiker,
> namelijk plaatsbepaling op huisnummerniveau.
>
> Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates
> aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door
> de community aangebrachte wijzigingen zo respectvol mogelijk behandelen.
> Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een
> soort werkgroep opgezet moeten worden om deze uit te werken en een import zo
> soepel mogelijk te laten verlopen.
> Ook bestaan er wellicht nog enkele vraagtekens omtrent het licentie-vraagstuk,
> maar dat zou het ministerie / de gemeentes definitief moeten kunnen
> beantwoorden.

Het is niet alleen een kwestie van nut voor de eindgebruiker. Als
iemand een navigatie-app wil maken of een website met een
routeplanner, kan hij prima 'best of breed' datasets combineren. Dat
betekent nog niet dat al die data in OSM hoeft te zitten. Bij een
import moet je volgens mij op de eerste plaats uitgaan van het nut
voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker.
Die ken je immers niet - wat voor de ene groep gebruikers een heel
nuttig thema is, is voor een andere categorie volstrekt irrelevant.

Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten aflezen:
1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld
bijdragen aan een beter publiek gezicht van het project. De
3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid
daarvan kunt zetten (zie hieronder), heeft een mooiere kaart
opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart,
aantrekkelijker door geworden.
2. Nut voor de OpenStreetMap als gemeenschap: een import kan een
impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een
eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit
aangetoond, dat de AND-import en ook de TIGER-import hier in de VS
daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers
liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit
misschien ook -- dan vanuit een blanco vel. Weet iemand van een
onderzoek dat dit argument ondersteunt of ontkracht?

Naast deze criteria is volgens mij het 'data bij de bron'-argument
heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij
de organisatie die verantwoordelijk is voor de productie.

Wat mij betreft is voor wat betreft de BAG-gegevens het laatste
argument doorslaggevend: het betreft hier een landsdekkende, complexe
databron met maandelijkse mutaties. Wat haal je je op de hals als je
deze data in OSM importeert? Je kunt dat bijna alleen maar éénmalig
doen, wat betekent dat het merendeel van de BAG-data in OSM langzamaan
zal verouderen, terwijl bij de bron (het Kadaster) elke maand frisse
data te halen is. Bedenk je eens wat dat betekent voor de kwaliteit
van OpenStreetMap over een jaar of drie. Op de korte termijn is het
een leuke winstpakker, maar op de lange termijn brengt het schade aan
het project toe.

>
> Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven,
> want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron
> doen.

We kunnen natuurlijk wel allerlei andere dingen met de BAG-gegevens
doen. We kunnen tools maken die kijken waar we straten missen. We
kunnen tools maken die ons erop attenderen dat er in een bepaald
gebied veel nieuwe adressen zijn bijgekomen: tijd om er eens langs te
gaan met een mapping party.
-- 
martijn van exel
schaaltreinen.nl




More information about the Talk-nl mailing list