Martin, bedankt voor de kans die jullie mij geven.
Ik zal mij beperken tot het muteren verbeteren van de door mij ingebrachte fouten en deze verbeteren.
Teven zal ik de in de BAG gegenereerde nieuwe adressen in Staphorst bijwerken in Openstreetmap, zodat er een actueel adressenbestand blijft bestaan. Waar nieuwe pandcontouren komen zal ik ook muteren.
Ik weet niet of er automatisch nieuwe pand en adrespunten worden ingebracht vanuit LV-BAG, dan is handmatige mutatie waarschijnlijk overbodig
Ik weet niet wat je hier precies mee bedoeld, maar het is de bedoeling dat panden en adressen vanuit de BAG geïmporteerd worden en zo min mogelijk met de hand worden bijgewerkt. Soms moet dat als de BAG achter loopt, maar BAG import blijft prevaleren. Dit om te voorkomen dat er een chaos ontstaat en het niet meer duidelijk is, wat nu wel en wat nu niet is geïmporteerd.
Voor BAG import wordt een plugin van JOSM gebruikt. Helaas is deze momenteel niet beschikbaar door een imcompabiliteit tussen JOSM en de plugin. Een nieuwe versie van de plugin is in ontwikkeling en momenteel in testfase.
Zie je fouten in de adresnodes of in de pandcontouren of wil je nieuwe panden erbij hebben, dan is er een sticky topic, Verzoek Bag-import, waar je een aanvraag voor BAG import kunt doen. Een van de mappers, die de nieuwe versie van plugin test, zal dan je aanvraag behandelen.
Nog even kleine aanvulling. Zie je fouten in de BAG, dan moeten die aan de BAG terug gemeld worden. Er zijn hier een aantal BAG experts, die dat eventueel voor je kunnen doen. Er moet zoveel mogelijk overeenstemming blijven tussen de bron (BAG) en het doel (OSM)
Je volgt blijkbaar niet de gebruikelijke procedure door een BAG-import te verzoeken, zoals boven in dit forum als sticky vermeld, maar je doet het zelf. Daar zal je dan je reden wel voor hebben.
Echter, bij de imports die je maakt voeg je meestal de key-valuecombinatie “STATUS=Pand in gebruik” in.
Deze key, noch de value is geen OSM term, en bovendien Nederlandstalig, en kan en mag je dus niet zomaar mee-importeren!
Zou je van alle imports waar je dit gedaan hebt deze tags willen verwijderen en dit ook bij toekomstige imports niet meer willen mee-importeren.
Nog een kleine aanvulling op de opmerking van Martin:
De voorloop nul(len) in ref:bag laten we bij de BAG import weg. Dat is conventie die we destijds bij de introductie van de BAG import hebben afgesproken. Ze kunnen verder geen kwaad, maar als je ze weglaat, sluit je aan bij de rest van het land.
Ik vind dit geen goede zaak.
Laat de BAG import nu aub over aan de mensen, die met de plugin bezig zijn. En ga niet zelf panden importeren.
Dat leidt weer tot allerlei wildgroei en straks ongelijkheden.
Als je panden wilt hebben, gewoon een import verzoek doen.
De sourcedate is ook verkeerd, daar missen streepjes in. Het is bij jouw imports jjjjmmdd en het moet zijn jjjj-mm-dd
Dat is weer het eeuwige probleem.
Als je nu eens een keer eerst goed had gekeken, welke tags er bij een BAG import worden gebruikt en in welk formaat, was er niks aan de hand geweest, maar voor de tigste keer ga je weer eigen tags en eigen formats verzinnen.
Conformeer je nu eens een keer aan de gangbare zaken.
Dat had ik even gemist, persoonlijk vind ik die ontbrekende nullen irritant omdat je zo de bag id niet kunt gebruiken met copy en paste om een pand even snel op te zoeken in de bagviewer.
De identificerende sleutel van de BAG Panden bestaat uit 4 karakters “0000”. Deze gemeentecode is de voorloper in het ID. Als je converteert en je blijft in “Karakter” zullen deze nullen mooi blijven staan. Ga je in conversie over naar Nummeriek gaan deze voorloopnullen verdwijnen. Hierbij de gemeentecodes http://www.bprbzk.nl/dsresource?objectid=4789&type=org
NB Voordeel kleinschalige import van Panden en Adressen is dat je de omgeving ook meteen kunt actualiseren. “als je er toch bent”. Dat heb je niet met Bulk import van BAG
Beste Escada, ik denk toch dat je hier even de plank misslaat, of begrijp ik je verkeerd?
Natuurlijk mag iedereen mappen, maar als we in NL conventies gemaakt hebben aangaande bijvoorbeeld de BAG-import, dan is het niet meer dan netjes om je exact aan die conventie te houden!
Wil je wat anders, dan stel je dat vooraf in het forum voor en ga je niet op eigen houtje je eigen microconventies definiëren.
Bij de huidige BAG importverzoeken gaat het vrijwel nooit over bulk imports, maar kleinschalige imports. Soms zelfs 1 pand.
En ik kan prima de omgeving actualiseren, zonder zelf panden in te tekenen. Die vraag ik gewoon even aan en dan komen ze.
Loop het BAG import verzoek topic maar eens door.
Ik weet wel dat Gerrit zich niet altijd aan de conventies houdt, maar daar heb ik het niet over.
H is misschien een stap te ver, maar ik kan me niet van de indruk ontdoen, dat een perfect getagged huis zonder bag tags een fout is volgens die import conventies. En dat hoort niet niet volgens mij. BAG-tags zijn extra’s die enkel nodig zijn om een import/update aan de praat te houden, niet omdat het nuttige informatie is voor OSM.
Inderdaad berusten de juiste BAG tags op een onder de BAG-importers algemeen geaccepteerd systeem dat, wellicht later, updates mogelijk en makkelijk maakt.
Natuurlijk mag je een huis tekenen zonder enige BAG tags, maar imho, áls je een BAG import doet, houd je dan aan de conventies. Je hebt dan namelijk bewezen dat je een input kunt uitvoeren, dus zo moeilijk moet het dan toch niet zijn om het juist te doen?
Nog even wat achtergrondinformatie: De BAG import in Zwolle is gedaan met de allereerste versie van de plug-in. De tags voldeden toen niet aan de huidige conventie. ref:bag (toen nog ref:bagid) had daarom in Zwolle nog wel een voorloop 0 en de source:date waarde (toen nog bag:extract) in Zwolle had nog geen koppeltekens. In dat licht was de tagging van Gerrit een stuk beter dan de meeste overige panden in Zwolle.
Om wildgroei te voorkomen zijn we toen met een groep mappers bij elkaar gaan zitten om een uniforme tagging voor de BAG af te spreken. Toen is ook na een lange discussie afgesproken om de voorloopnullen in ref:bag weg te laten.
Tot voor kort was het er nog niet van gekomen om de oude tag bij te werken. Nu we bezig zijn met het vergelijken van BAG data met wat er in OSM staat, wordt het belangrijker om een inhaalslag te maken. Daarom ben ik net gisteren begonnen met het omzetten van de oude BAG tags naar de huidige standaard op de plekken waar dat nodig is. De regio Zwolle heb ik inmiddels bijgewerkt. Nu ben ik bezig in Amersfoort waar de BAG import nog gedaan is met een script dat een voorganger was van de plug-in.