I2011/8/29 Oliver Heesakkers <[email protected]>: > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> 2011/8/28 Nico Witteman <[email protected]>: >> >(...) >> >> > 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 _______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl
