Niet officieel, het is wel eens eerder ter sprake gekomen op het forum, en het is geen rocket science. De tools die gebruikt worden liggen voor de hand.
Woonplaats grenzen
De BAG data uit de PDOK Atom feed wordt in een PostGIS database geladen met NLExtract.
De woonplaats grenzen worden vervolgens naar OSM formaat geƫxporteerd met ogr2osm i.c.m. een custom translation wat aangeroepen wordt via een API op mijn server.
De BAG geometrieƫn zijn gesloten ringen, deze worden opgeknipt m.b.v. de Split Way functie op de nodes waar boundary ways kruisen. De nodes op kruisingen worden eerst gemerged met de Merge Nodes functie zodat de bestaande node in OSM dezelfde coƶrdinaten heeft als de nieuwe welke onderdeel is van de boundary way uit de BAG.
Voor het updaten van de boundary ways wordt de Replace Geometry functie van UtilPlugins2 gebruikt. De tags voor de relation waarvan veelal alleen de start_date gewijzigd is, worden gekopieerd van de relatie in de BAG layer naar relatie in de OSM layer.
Om te bepalen welke woonplaatsen aangepast moeten worden, wordt de BAG en OSM data vergeleken. De OSM data uit de Geofabrik extract voor Nederland wordt met osmosis in een PostGIS database geladen.
Vervolgens wordt de start_date tag gecontroleerd van de boundary relations, indien de waarde ouder is dan in de BAG (begingeldigheid attribuut) moet de grens geupdate worden. Hiervoor gebruikt ik een Perl script wat de custom osm_woonplaats tabel bijwerkt in mijn BAG database waarin de status (uptodate of outdated), start_date, en OSM object type en id worden opgeslagen voor elke BAG woonplaats identificatie.
Deze tabel wordt gebruikt in de MapServer en MapCache configuratie voor de WFS/WMS/WMTS services om de status van de woonplaatsgrenzen op een kaart te kunnen tonen.
Gemeentelijke indeling
De jaarlijkse gemeentelijk indeling wijzigingen worden in oktober door CBS gepubliceerd.
Bij het fuseren van gemeentes wordt de admin_level tag van de tussenliggende boundary ways van 8 naar 10 aangepast, en de relation voor de opgeheven gemeentes worden verwijderd.
Wanneer gemeentes komen te vervallen omdat deze worden opgenomen in een bestaande gemeente, worden de outer members van de te verwijderen relatie opgenomen in de relatie van de gemeente die blijft bestaan, en de tussenliggende boundary ways welke nu niet meer tussen de gemeentes liggen worden uit de relatie verwijderd.
Voor nieuw te vormen gemeentes worden nieuwe relations gemaakt met de betreffende boundary ways als outer members en de place node waar het stadhuis gevestigd is als admin_centre.
Deze wijzigingen zet ik veelal in december vast klaar nadat de laatste BAG update van het jaar in OSM is verwerkt. De OSM data voor de betreffende gemeentes wordt hiervoor uit de lokale PostGIS database opgehaald en in OSM XML files opgeslagen, deze OSM files per gemeente worden gemerged met osmium-tool waarna deze in JOSM bewerkt wordt.
De OSM file wordt vervolgens met Oud & Nieuw weer in JOSM geladen en geupload zodat de gemeentelijke indeling per 1 januari ook als zodanig in OSM te vinden is. De upload is niet geautomatiseerd omdat in de tussentijd wijzigingen gemaakt kunnen zijn aan de objecten in kwestie waardoor merge conflicts optreden. Een jaar waarin geen wijzigingen zijn zoals 2020 en 2024 zijn mooi meegenomen zodat ik dat jaar niets hoef te doen tijdens Oud & Nieuw.
