ik zie wel mogelijkheden voor een update script. ik zeg niet dat ik het ga maken :) maar het is wel mogelijk.
groet, floris 2011/8/29 Martijn van Exel <m...@rtijn.org>: > I2011/8/29 Oliver Heesakkers <o...@heesakkers.info>: >> Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >>> 2011/8/28 Nico Witteman <n...@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 > > _______________________________________________ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl > _______________________________________________ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
