Eenmalig bulk aanpassen BAGID

[Jvitegem]

In het verleden is bij het importeren van objecten uit de BAG een voorloop 0 weg gevallen bij het BAGID
Inmiddels is dat probleem in de BAG import tool opgelost.
Wat is het probleem ? Volgens de definitie is een BAGID samengesteld uit de gemeentekode (van 4 digits) + een unieknummer van 12 digits, totaal dus 16 karakters.
Het probleem is dat sommige gemeentekodes met een 0 beginnen, b.v. Eindhoven is 0772.
Door een of andere oorzaak is in het verleden die eerste 0 weggevallen bij het importeren. Dit is een probleem als bv. een koppeling wilt maken met BAG viewer want deze vereist 16 digits voor een BAGID.
En bij het importeren van een nieuwe geometrie (bv. na een verbouwing) vereist dat extra handelingen omdat het BAGID nu wel met de voorloop 0 wordt geïmporteerd en dat is lastig.

Ik wil daarom een projectje opstarten om alle “foute” BAGID’s aan te passen.

Ik heb wat online onderzoek gedaan en ben gekomen tot de volgende procedure.

Implementatie voorloop 0 bij ref:bag

Het idee is omdat per gemeente te doen.
Hierdoor blijft het nog enigszins overzichtelijk.

1. Download het gebied in JOSM
2. gebruik een filter om alleen object met een ref:bag tag te selecteren en waar het BAGID begint met een gemeentecode zonder voorloop 0
   Voorbeeld: “ref:bag”~772.+ and -preset:“Relations/Multipolygon”
3. kopieer de selectie naar een aparte laag M
4. Selecteer alle objecten (dat kunnen dus alleen gebouwen zijn die in de BAG staan) op deze laag en voeg een FIX_ME tag toe, dit om action=‘modify’ toe te voegen aan alle objecten.
   Ik wil de tag FIX_ME is geen vergissing, ik wil de bestaande tag fixme niet gebruiken om te voorkomen dat bestaande opmerkingen verloren gaan.
5. Slaan de laag op in een .osm bestand.
6. Open het .osm bestand in een editor bv. notepad++
7. Vervang het BAGID met zoek = “<tag k=‘ref:bag’ v='772” en vervang = “<tag k=‘ref:bag’ v='0772”
8. Laad jet nieuwe bestand in JOSM
9. verwijder de FIX_ME tag
10. upload de wijzigingen

Wat denken jullie hiervan ?
Heeft iemand een ander / beter idee ?

[JeroenHoek]

Omdat om heel erg veel objecten gaat vraag ik me af of dat wel nut heeft.

Een BAG ID als 70100000316017 werkt in JOSM bijvoorbeeld gewoon als je via de shortcut die link volgt. Elke data-consumer die iets met de BAG ID in OpenStreetMap doet kan triviaal de voorloopnul erbij zetten immers.

In Python:

bag_id = '70100000316017'
print(f'{bag_id:>016}')

0070100000316017

Je lost dus een niet noemenswaardig probleem op, terwijl je wel massaal nieuwe versies van objecten creëert. Het is voor mappers erg fijn om aan de laatste bewerking van een object te kunnen zien wanneer die voor het laatst zinvol is aangepast. Bij een gebouw dat sinds 2014 niet is aangeraakt is het aannemelijker dat de luchtbeelden inderdaad op sloop wijzen, terwijl bij 2025 de kans groot is dat het pand in aanbouw is (of in ieder geval even een blik op de BAGViewer nuttig is). Dat ga je verstoren. De balans lijkt me dus een beetje zoek bij dit project.

[Jvitegem]

@JeroenHoek Je geeft aan dat

Een BAG ID als 70100000316017 werkt in JOSM bijvoorbeeld gewoon als je via de shortcut die link volgt

Welke short cut heb je het dan over?

Dat het programmeer technisch eenvoudig is op te lossen is mij bekent allen daar heb ik zo weinig aan als ik in JOSM werk.

Het is voor mappers erg fijn om aan de laatste bewerking van een object te kunnen zien wanneer die voor het laatst zinvol is aangepast

Vind ik niet zo een sterk argument, ik heb geen idee waarom een mapper dat zou willen weten. (ik ben zelf een mapper )…

Bij een gebouw dat sinds 2014 niet is aangeraakt is het aannemelijker dat de luchtbeelden inderdaad op sloop wijzen, terwijl bij 2025 de kans groot is dat het pand in aanbouw is (of in ieder geval even een blik op de BAGViewer nuttig is)

Daar gebruik ik source:date en start_date voor.

Als jij een manier weet hoe dat ik het kan aanpassen zonder een extra history record aan te maken dan hoor ik het graag.

[JeroenHoek]

[CasGroenigen (Cas van Groenigen)]

Ja, het zou ook gedaan kunnen worden door (gewoon) met de BAG Plug-in de geometry van de gebouwen te updaten, en dan komen daarmee ook de nullen er weer bij neem ik aan.

Mogelijk dat we dan sommige woonplaatsen voorrang kunnen geven op anderen door te kijken waar de meeste nullen missen.

[roelant]

Voorloopnullen en object-/bron-history

Ik deel Jeroen’s mening dat de toegevoegde waarde van het bijwerken van panden voor alléén de voorloopnullen weinig toevoegt (anders dan dat het fijn is om het kloppend te maken), terwijl er wel applicaties/gebruiken zijn waarin de laatste wijzigingsdatum een belangrijke indicatie of selectiecriteria vormt en niet gekeken wordt (of kán worden!) naar dedicated velden als start_date, source_date of check_date. Los van het feit dat het dan altijd maar weer de vraag is welke beschikbaar is (soms de een, soms de ander) en of die van toepassing is voor jou doel.

Andersom, als voorbeeld, als je naar source en source:date kijkt met het doel te vinden wanneer de BAG-informatie voor het laatst is bijgewerkt, kom je er soms ook bedrogen uit. Het komt vaak genoeg voor dat iemand die velden nadien heeft bijgewerkt om een andere reden. Bijvoorbeeld omdat we in Nederland een amenity op de adresnode zetten. Dus voeg je een winkel toe n.a.v. een survey is het niet onlogisch om de source bij te werken (source=survey - en als het netjes gebeurt met een check_date of survey:date, maar dikke kans dat gewoon source:date is bijgewerkt).

Wat dat betreft zou het netter zijn om dat uit elkaar te trekken en voor BAG source:addr en source:geometry met hun bijbehorende :date keys te gebruiken voor de BAG-sourcedata. Als toch besloten wordt te gaan mass-editten, zou ik er overigens wel voor pleiten om dit dan gelijk ook om te zetten.

En dan negeer ik bewust even de discussie die bestaat over of source-info op het object of op de changeset hoort, die ook al jaren loopt, want dan wordt het wel een heel ingewikkeld verhaal.

Bijwerken met de Bag-tool?

Bijgewerken met de BAG-tool zou vervolgens een goede optie zijn, maar als we structureel dingen gaan bijwerken met de BAG-tool is er wel meer (en in mijn ogen: belangrijker) werk te verzetten.

Ik ben ooit met BAG begonnen omdat ik erachter kwam dat in bepaalde plaatsen na de initiële import nooit meer iets bijgewerkt is, gewoon blok voor blok de geometrie bijwerken. Als je naar de top20 kijkt van woonplaatsen op basis van ontbrekende objecten…

… is er genoeg te doen. En dit kijkt alléén naar ontbrekende objecten, nog niet eens naar gewijzigde of verwijderde objecten - want dat zijn er nog véél meer.

Dat bijwerken vind ik zelf belangrijker dan het juiste aantal nullen in de ref:bag, want het zijn daadwerkelijk ontbrekende of niet-meer-kloppende kaart-elementen, maar dat is persoonlijk natuurlijk.

[JeroenHoek]

Het is ook vrij zinloos omdat je in dit soort gevallen altijd defensief programmeert als je de data inleest. Immers, waarom zou een data consumer die iets met het BAG ID doet niet eerst eventueel ontbrekende voorloopnullen erbij doen? Je weet dat zulke data kan bestaan in de OpenStreetMap-database, en zelfs al plak je bij elk gebouw in Nederland die nullen ervoor, dan nog is het aannemelijk dat sommige mappers zo’n ID neerzetten zonder die nullen. Bijvoorbeeld omdat een gebouw uitgebreid wordt met building:part en de outline op een ander object komt te staan.

Als Kadaster zo graag deze ID echt als een fixed length opaque identifier in had willen zetten, hadden ze er simpelweg een B of zo voor moeten zetten. Dan stript niemand de voorloopnullen, en ziet niemand het per ongeluk als een numerieke waarde die je in een long of zo op kan slaan. Dit zal bij meer toepassingen die iets met de BAG doen spelen.

[CasGroenigen (Cas van Groenigen)]

Is het ergens mogelijk om te zien waar deze nullen nog missen en waar niet?

[JanWandelaar]

Als de BAGID als string gedefinieerd is bij de API naar de BAG database lijkt het mij zinvol om de voorloopnullen toe te voegen.

[goedegazelle]

Het heeft meer zin om te kijken waar gebouwen ontbreken dan louter voorloopnullen.

Eigenlijk is het zo dat iedere bewerking die automatisch kan worden uitgevoerd door ons niet hoeft te worden uitgevoerd.

Applicatiebouwers zijn programmeurs. Als ervaren programmeurs zeggen dat dit niet nodig is, dan is dit niet nodig.

Ik kan mensen òf hun enthousiasme ontnemen over voorloopnullen, òf toekijken hoe ze hun tijd verspillen.

[Sander_H]

Hier iig de aantallen per lengte:

Grotere lengtes waren in mijn ervaring verklaarbaar doordat bij samenvoegen van panden meerdere Id’s samengevoegd zijn.
De kortere zijn wat vreemde waarden:

Die kunnen wel eens nagelopen en gecorrigeerd worden.

[JeroenHoek]

Via de TagInfo-database die je kan downloaden is het makkelijkst.

[JeroenHoek]

Het gaat inderdaad om miljoenen objecten (het merendeel van de BAG-gebouwen trouwens). Dat levert geen winst op behalve „Oh, nu klopt het”.

Voor de normale gebruiker maakt het sowieso niks uit. Voor ontwikkelaars van applicaties die iets met de BAG ID doen ook niet, want je kan het ontbreken van de voorloopnul niet uitsluiten (dus houdt je er toch al rekening mee).

[Jvitegem]

@JeroenHoek

Via de TagInfo-database die je kan downloaden is het makkelijk

Ik zie dat de tag ref:bag ook in het buitenland voorkomt …
Die wil ik niet mee tellen … Volgens het CBS staan er in nederland “maar” 9,5 miljoen BAG objecten.
Ik zou graag een overpass_turbo query maken maar kan niet vinden hoe dat moet.
Maar volgens mijn statische voorspelling gaat het om 3/4 van alle BAG objecten dus grof weg 7 miljoen.

[JeroenHoek]

Hoef je niet te doen. De bulk van de ref:bag zijn gebouwen in Nederland. De rest is statistisch niet interessant voor deze discussie. Dat het om zo’n 7 miljoen objecten gaat hebben we al vastgesteld immers.

Dit krijg je met Overpass Turbo niet voor elkaar voor heel Nederland. Die weigert zo’n grote opdracht.

sqlite> select count(*) from tags where key = 'ref:bag' and value regexp '^[0-9]{16}$';
4101987
sqlite> select count(*) from tags where key = 'ref:bag' and value regexp '^[0-9]{12,15}$';
7189885
sqlite> 

[CasGroenigen (Cas van Groenigen)]

Heb net geprobeerd in 1x heel Schiermonnikoog te updaten, hiervoor moesten ~1700 gebouwen door de BAG tool heen. Na ongeveer 10 minuten stond hij op 250 en heb ik hem geannuleerd omdat het te lang duurde.

Ik denk dat 7 miljoen gebouwen aanpakken te veel werk is voor deze minimale winst. wss beter om het gewoon op natuurlijke wijze langzaamaan te laten verbeteren als de gebouwen veranderd zijn en een nieuwe update aan de geometry nodig hebben.

[JeroenHoek]

@CasGroenigen

Ik denk dat 7 miljoen gebouwen aanpakken te veel werk is voor deze minimale winst. wss beter om het gewoon op natuurlijke wijze langzaamaan te laten verbeteren als de gebouwen veranderd zijn en een nieuwe update aan de geometry nodig hebben.

Sowieso moet een BAG update met aandacht voor de uitwerking op de kaart gebeuren. Blind importeren in een actief beheerde kaart levert namelijk fouten op. De meeste mappers die importeren uit de BAG controleren hun werk ook, maar bij zo’n bulkactie kan dat niet.

[JeroenvanderGun (dr.ir. Jeroen van der Gun)]

@JeroenHoek

Voor ontwikkelaars van applicaties die iets met de BAG ID doen ook niet, want je kan het ontbreken van de voorloopnul niet uitsluiten (dus houdt je er toch al rekening mee).

Ik neem aan dat het doel van dit voorstel is dat je dit voortaan wel uit kunt sluiten. Na deze wijziging zouden er ook geen nieuwe BAG ids zonder voorloopnullen meer moeten verschijnen, tenzij iemand met de hand iets heel raars doet.

De BAG Viewer accepteert het in elk geval niet als je voorloopnullen weglaat in een zoekopdracht.

[JeroenHoek]

@JeroenvanderGun

[…] tenzij iemand met de hand iets heel raars doet.

Exact. Dat kun je niet uitsluiten — niet op meer dan 10 miljoen objecten — dus zou je aan de data-consumer-kant wel heel naïef bezig zijn als je niet met een regel code de voorloopnullen ervoor zet als je ze nodig hebt. Dat probleem blijft dus.

Dit is net als met postcodes uit de OpenStreetMap-database. Ja, die doen we doorgaans met de vaste notatie van 1234AB, maar als je de data uitleest ga je 1234 AB of 1234ab niet fout rekenen. Die zet je met een regel sanitising of twee om naar de gewenste vorm.

Of je schrijft je software zo dat het altijd werkt als de voorloopnullen ontbreken, of je accepteert dat je soms (of met enige regelmaat) voorkombare fouten hebt.

Dit is een ingrijpend voorstel met neveneffecten voor een niet-bestaand probleem.

[Jvitegem]

@JeroenHoek

sqlite> select count(*) from tags where key = 'ref:bag' and value regexp '^[0-9]{16}
```;
4101987

Waarin doe je dit ? (SQL is mijn 2e taal )