Ik heb nog niet op al je vragen een antwoord maar laat ik maar van wal steken.
Wat ik en nog een paar anderen aan het doen zijn moet je maar zien als een testcase. We zijn nu e.e.a. aan het invoeren en gebruiken die ervaring om te kijken wat het meest pragmatische weg is om de data verantwoord OSM in te krijgen. Het is dus vooralsnog veel trial & error. Voordeel is wel dat OSM er niet op achteruit gaat als de oude 3dShapes vervangen wordt door BAG data maar uiteraard is het verstandiger op een dusdanige manier de data in te voeren dat er tzt ook nog e.e.a. aan onderhoud en controle gedaan kan worden.
Hoe er precies omgegaan gaat worden met updates etc is mij nog niet bekend maar het is dus de bedoeling de data zo in te voeren dat daar mogelijkheden voor blijven (juise ID’s). Ik kan me echter niet voorstellen dat het technisch een groot probleem moet zijn om verschillen tussen BAG en OSM data op te sporen als beide data te matchen zijn met ID’s. Als er een keer een verbouwing is aan een huis (verandering van vorm oid) dan lijkt me dat niet een erg groot probleem als dat niet meteen wordt gefixt. De juiste adressering vind ik wel een groot pluspunt van het invoeren van BAG data.
Ik geloof graag dat het technisch mogelijk is om BAG data en OSM los van elkaar te houden en samen te voegen voor eigen applicatiedoeleinden maar ook dat heeft wel een aantal nadelen. Hoe moet een Duitser die iets met NL OSM data wil doen weten dat hij voor juiste adressen maar een BAG extract moet converteren en samenvoegen met OSM data? Het is toch juist de bedoeling van OSM om 1 dataset te hebben waar alles bij elkaar komt. Straks worden er nog wegen uit OSM gehaald omdat er ergens een extract te krijgen is van alle nederlandse wegen en we niet op 2 plaatsen onderhoud willen. Misschien wat gechargeerd maar als straks alle data vrij is dan zou er geen centrales OSM database meer zijn. Iedereen combineert maar wat ie zelf wel. Lijkt me geen goed streven.
Een voordeel van invoeren van BAG data is ook dat je nogal eens fouten tegenkomt. Wegen die niet goed zijn gepositioneerd en opeens dwars door een gebouw heen lopen bv.
Verschil in tagging lijkt me ook technisch goed op te lossen mits er wel het zelfde BAG id gebruikt wordt. Als er bij een update besloten wordt om bv toch de addr:city tag of addr:country op te nemen terwijl die nu ontbreekt dan moet dat te doen zijn lijkt mij.
Tot op heden is inderdaad gebleken dat het overzetten van tags het meeste werk is. Dat bied overigens ook weer de kans om de boel op te schonen en dat is mooi meegenomen. Oude panden verwijderen en nieuwe BAG toevoegen gaat relatief snel. Desondanks is het wel heel veel werk maar … vele hande maken licht werk.
Ik denk dat we er best goed over nadenken maar we zullen ongetwijfeld e.e.a. vergeten zijn of bij moeten stellen. Het plan is om over een tijdje met een voorstel te komen. Dan mag er naar hartlust op geschoten worden.