Laat ik eerst voorop stellen dat ik niet anti-BAG-import ben, maar vanuit mijn betrokkenheid bij eerdere imports en vanwege het feit dat ik werkzaam ben in het geo-veld heb ik wel de nodige bedenkingen.
Dat hoeft ook niet, maar neem vooral de tijd daarvoor 
Het is wel duidelijk dat jullie nog in de ontwikkel-/testfase zitten, maar ik mis nog een aantal fasen die ervoor plaats zouden moeten vinden. Ik ben zelf ook een techneut, dus ik weet als geen ander hoe verleidelijk het is om in de techniek te springen, maar je moet wel leren wat het goede moment daarvoor is. De BAG roept zoveel issues op dat hier goed over moet worden nagedacht. eker aangezien het ontwikkelproces uit trial & error bestaat. Dat levert ongetwijfeld situaties op die later opgeschoond moet worden. Je noemt zelf ook “onderhoud en controle”. Dit zijn zaken die je integraal moet benaderen, niet uitstellen tot t.z.t. Van uitstel komt afstel.
Stel een wiki-pagina op, maak een plan(ning), organiseer een meeting, nodig mensen uit om mee te denken (mits constructief), etc. Natuurlijk is dat niet zo leuk dan wat testjes importeren, maar om een BAG-import in OSM geaccepteerd te krijgen, is dat wel nodig. Een import moet goed worden gedocumenteerd, goed doordacht zijn en steun hebben van de Nederlandse community. Anders krijg je bijv. de DWG + iedereen die vindt dat hij er iets van moet vinden over je heen.
Bij de AND-import en bij andere imports is vaak besloten om de ID’s te houden, om er “later nog wat mee te kunnen doen”. Dat gebeurt hoogst zelden. ID’s zijn gewoon tags in OSM, dus die kunnen geëdit worden. In Nederland zijn bijv. veel wegen die aan elkaar geplakte ID tags hebben, bijv. 123;456;789, omdat de oorspronkelijke ways aan elkaar geplakt zijn. Aanvullende controles zijn nodig. Dat kan bijv. door periodiek OSM-data in een database te laden en (ruimtelijke) queries uit te voeren om het met een recent BAG-extract te vergelijken.
Als een Duitser iets serieus met Nederlandse data wil doen, dan zal hij daar vroeg of laat zelf wel achter komen dat er iets als de BAG bestaat. Ik weet niet exact hoe het zit met Europese regelgeving, zoals Inspire, maar ik geloof dat BAG en andere basisregistraties mede in het kader hiervan onderhouden worden. De scope van OSM is wel vrij breed (zeker meer dan een wegenkaart), maar het lijkt mij niet realistisch te verwachten dat OSM maar alle publieke datasets moet souperen. Daarvoor is de community te divers en de kern van degenen die dit tot stand zouden kunnen brengen en onderhouden te klein (long tail effect).
V.w.b. de zinnen “Als straks alle data vrij is, dan zou er geen centrale OSM database meer zijn. Iedereen combineert maar wat ie zelf wel. Lijkt me geen goed streven.”: dat is het ultieme doel van open data! Niet dat OSM dan geen nut zal hebben. Sterker, ik denk dat er altijd behoefte is aan een crowd sourced geodataset (OSM is op een aantal terreinen en in een aantal gebieden de meest complete dataset), maar het is mede dankzij OSM dat open data tegenwoordig zo hoog op de agenda staat! Als veel datasets open zijn, dan kun je juist meer uit de datasets halen door ze op allerlei mogelijke manieren te combineren. Het geheel is groter dan de som der delen. En ja, dat geldt ook door verschillende databronnen in OSM te importeren, mits je de consequenties even buiten beschouwing laat.
Dat kan ook door bijv. een WMS-server met BAG-data in JOSM onder de OSM data te hangen. Daar zijn allerlei manieren voor.
Dat vereist een grote update-actie. Als je dat voor alle 7 miljoen BAG-panden in Nederland wil doen (of hoeveel het er ook zijn), dan worden de sys-admins en anderen hier heel zenuwachtig van! Ik word het ook als ik dat voor een paar duizend objecten zou moeten doen. Technisch is heel veel te doen, maar de vraag is of je dat zou moeten willen.
Het opschonen-argument hebben we ook voor 3dShapes gebruikt, dus ik kan zeggen dat dat wel werkt Toch heeft ook dat meer voeten in de aarde, zoals wij door schade en schande achterkwamen. Zie bijv. de discussie over toponiemen op talk-nl afgelopen maart. Verder hebben we de fout gemaakt door de namen van waterwegen in 1e instantie over te nemen op alle 3dShapes vlakken die daar onderdeel van uitmaakten. We wilden immers geen informatie verloren laten gaan. Toen we achterkwamen dat dat niet handig was, hebben we of aparte ways gebruikt (waterway = stream/river/canal, als centerline), of de resterende lineaire AND water ways intact gelaten. Zie o.a. hier een relatief vroeg voorbeeld. Weliswaar een extreem voorbeeld, maar geeft wel duidelijk het probleem aan. Er zijn veel gebieden die ik niet heb opgeschoond. Niet omdat ik het niet wil, maar omdat ik dat niet meer kan opbrengen. Die 3dShapes import heeft mij behoorlijk afgebrand, dat wil je niet weten… Het had ook geen changeset langer moeten duren! Dat gevoel heb ik nog steeds 1 1/2 jaar na afloop.
V.w.b. het verwijderen van bestaande data: voordat je dit doet, probeer zoveel mogelijk in contact te komen met lokale users die redelijk wat bijgedragen hebben. Dat is en blijft een heikel punt, omdat sommigen er niet van gediend zijn dat je in hun achtertuin gaat wroeten. Het is lastig aan te geven wat een goede grens is. Soms denk je dat je wel de instemming hebt van de meeste mensen in een gebied, maar blijkt iemand die jaren geleden een paar wijzigingen in OSM heeft gemaakt en sindsdien niet meer actief is, opeens in de pen te klimmen om zijn ongenoegen te uiten.
Onderschat het hele gebeuren niet! Niemand verplicht je om volgende week al OSM met de BAG te “vullen”!