Address changes because of municipality fusions, 2025

[joost_schouppe]

There are big municipality fusions planned, going into effect on 1/1/2025. You can get an idea of all the things we have to do by looking at the project page for the previous fusions. There’s a page for the new fusions as well. Let’s use that page to define the steps & keep track of status. Let’s use this thread to discuss the topic.

The biggest job is updating the address and streetnames. Over 300 streets will change names, and thousands of addresses will be affected, often including up to the house number level.

I would like to split the job in two parts:

• simple things we can automate
• online spreadsheets to keep track of the harder tasks

I’ve started with the bulk work: preparing the streetname changes. Last time, we used this tagging for the preparation phase:

   name=Original Name
   proposed:name=New Name
   fixme:name=WikiProject_Belgium/Municipality_Fusions/2025

If we get that ready by December 31st, we can do a very simple edit on new years eve where we filter all the objects with the fixme:name and change their name to old_name and their proposed:name to name

Because it’s quite a lot of streets, and there is relatively little that can go wrong, I made and tested a script that does the following steps:

• download the staging files (real data but not finalized yet)
• only keep the old streets that change into a single new street
• create an overpass query to download all the streets of a single municipality, export to Level0 and save as a text file (manual)
• load that text file and add the extra tags
• save back to Level0 and apply the change there

Let me know if you see any issues in the logic!

I would suggest to also script the update of address, but only where all the housenumbers of a street remain the same.

Then finally, we can make a list of all streets where manual intervention is needed and share the workload on those. It will be easier to wait until after 1/1/2025, because then the GRB background and LARA will show the new situation.

We can also use your help listing all the things that need to happen (e.g. update the ref:INS codes, update province boundaries near Antwerp, …) and take on some of those tasks as well!

[juminet]

Hello Joost,

Thanks for taking the lead of this.

I can manage the fusion of Bastogne-Bertogne, to be effective on the 2nd of December.

I’ll have a look on what will be the implication of this fusion on OSM, following the guidelines on WikiProject Belgium/Municipality Fusions/2019 - OpenStreetMap Wiki.

I’ll look after and ask around if addresses are to be changed.

juminet

[M_dgard (Midgard)]

@joost_schouppe

Let me know if you see any issues in the logic!

Code review!

Serious issues

• You’re exporting to DUPLICATE_streetname_changes_<municipality>.txt from an unfiltered table, so each of those files will have an Overpass query for the streets in all municipalities.
• No list is generated of street names that weren’t found in OSM data. This is not defensive enough.

Potentially serious issues

• You’re passing the street name as part of a grepl pattern. By default grepl interprets the pattern as a regex, which will cause problems if any of the old street names contain characters that have special meaning in regexes. Use fixed = TRUE as a parameter to be safe.
• If the way already contains proposed:name or fixme:name you’ll be generating duplicate keys, which has the potential to cause undefined behaviour, but perhaps Level0 would refuse that? Did you check?

Improvements

• The script writes an Overpass query to file, then looks for the file you put there and probably crashes. You then run the script again. Correct? You could also, just before the current line 71, read one line from stdin (“standard input”, on the terminal) to wait for the user to press enter. Or read the Level0 code directly from stdin (you would then paste it into the terminal).

[joost_schouppe]

@M_dgard

• You’re exporting to DUPLICATE_streetname_changes_<municipality>.txt from an unfiltered table, so each of those files will have an Overpass query for the streets in all municipalities.

I meant to collect all the weird cases in one file, so just the filename was wrong.

@M_dgard

• No list is generated of street names that weren’t found in OSM data. This is not defensive enough.

Good suggestion. It made me see a bigger issue. Because I didn’t manage to run this before Jan 1st, the old municipalities do not exist anymore. So I cannot select streets in Kruibeke, because the only Kruibeke that still exists is the old admin_9. And obviously I cannot use the new municipality name, because many of the name changes are exactly because they are not unique within the new municipality. I don’t see a simple solution with my script. I’m afraid we’ll have to use a geometric approach instead. But I’m thinking at that point it’s defeating the purpose and we better just go through them case by case (and also do the addresses in the same run)

@M_dgard

• You’re passing the street name as part of a grepl pattern. By default grepl interprets the pattern as a regex, which will cause problems if any of the old street names contain characters that have special meaning in regexes. Use fixed = TRUE as a parameter to be safe.

Thanks, adapted!

@M_dgard

• If the way already contains proposed:name or fixme:name you’ll be generating duplicate keys, which has the potential to cause undefined behaviour, but perhaps Level0 would refuse that? Did you check?

Yes, Level0 has blocked me from stuff like this in the past. But I’ll double-check.

@M_dgard

• The script writes an Overpass query to file, then looks for the file you put there and probably crashes. You then run the script again. Correct? You could also, just before the current line 71, read one line from stdin (“standard input”, on the terminal) to wait for the user to press enter. Or read the Level0 code directly from stdin (you would then paste it into the terminal).

Nah, I just run the script step by step for now. It would be more efficient to split the logic as such: write clean and finished overpass queries to txt and stop. Then manually run and save the files, and run the process on all the output files.

[M_dgard (Midgard)]

@joost_schouppe

the old municipalities do not exist anymore

Can’t you query by deelgemeente instead?

Or else, you could put [date:"2024-12-31T00:00:00Z"]; at the beginning of the Overpass query to travel back in time, but that will of course also go back in time for the streets which could be a bit dangerous because they are likely to have been modified in the mean time.

[joost_schouppe]

Can’t use deelgemeente because the old municipalities have just been deleted in many cases. I based my whole approach on the idea of doing most stuff quick and dirty before Jan 1st. Now that that has passed, I think I’ll change my entire approach:

• download wegenregister (which already has the new data)
• select streets by new name & new municipality based on change list
• create a record for each new street
• classify the type of change: are addresses along this street just changing street or also housenumber
• compare the record to OSM data: does the old street name still exist in the neigborhood (on a highway or as addr:street)?
• keep the cases where an old street name still exists
• save to maproulette and go over the records manually.

Yes, that means going over the 350 changes manually, but in a single go, all 8000 addresses should be fixed

[driesverlinden]

Can we do something to help with the streets?

[joost_schouppe]

I intend to set up a task in MapRoulette to make the changes easier. Feel free to already start, my new script will detect if you miss a spot.
You can download the list of changes at https://www.vlaanderen.be/digitaal-vlaanderen/onze-diensten-en-platformen/gebouwen-en-adressenregister/heradressering-bij-vrijwillige-gemeentefusies

[joost_schouppe]

Allright, MapRoulette task is up!
Every task will show you an entire street as derived from Wegenregister. Click on it to learn more about the task. It includes an Overpass query that should give you all the relevant roads and things with an address in the area. Change the name of the affected streets and the addr:street of affected addresses.
You can use GRB as a background map and use https://lara.vlaanderen.be to doublecheck.

Do not blindly trust the provided data. While building the script, I found an error where a street from the neighboring municipality was changed by mistake! Also there are 24 cases in the change-documentation that do not exist in Wegenregister. I expect feedback soon to see what is happening there.
When you see a mistake, please leave a comment on the task or report it here.

Don’t just choose open in editor, but click on the task!
Most importantly, it will show an overpass query. Copy it to overpass-turbo.eu, then export to JOSM for easy editing. All affected addresses should be included. This will help you find cases that are “almost fixed” (but folks forgot mini segments) and might even allow using “select all” in some cases.

Some more info
On the street, please keep the old name as old_name.
When you see new_name_exists=TRUE, it means someone already applied some of the changes to OSM already. In fact, in almost half of the cases, someone already took care of all the needed changes!
You should only see cases where old_name_exists is also TRUE, meaning that they did not update all affected streets. There is a classification of changes (based on the official data, addresses might not be mapped yet in OSM). Values:

• rename only: the addresses change streetname, but the numbering remains the same
• renumbering only: all addresses change both name & number
• renumbering: both cases exist
• no addresses affected (the stree has no housenumbers)

I can re-run the script after a while, so that new cases that have been fixed outside the MapRoulette disappear automatically. Conversely, if people have marked things as fixed, but missed a few details, the task ill be re-opened.

[joost_schouppe]

Just a remark: it turns out the data you see in GRB and the sata I used to create the task outlines is not completely finished. In principle, https://lara.vlaanderen.be should be more up to date.