With the recent updates on address statistics and comparison with GWR data, I thought this would be a good opportunity to help improve address coverage in Switzerland. To this end, I’ve written a detailed Wiki guide proposing a step-by-step process for importing addresses from the Swiss Federal Register of Buildings and Dwellings (GWR) into OpenStreetMap (OSM) using JOSM.
This guide is intended to assist mappers looking to improve address data, such as in cases like these:
“Un objectif à plus long terme serait de numéroter les bâtiments, mais c’est un travail long et fastidieux tant qu’il n’y a pas une solution simple d’import des adresses.”
This guide simplifies and streamlines the process of importing GWR address data. After applying the guide in Zug and Cham, address matching rates on qa.poole.ch increased from 52% to 99% and 71% to 99% respectively. The warnings total decreased by 444 warnings in Cham and 1332 in Zug.
Overview of the Guide
The guide covers the following key steps:
Preparation
Data Cleanup:
Remove redundant or incorrect address tags (ways, nodes, entrances).
Conflation Process:
Use the Conflation plugin in JOSM to match and merge data.
Review and manually validate matches.
Handling Validation Warnings:
Review all warnings (e.g., duplicate house numbers, suspicious tag combinations).
Upload
Benefits of the Guide
Consistency: Ensures a uniform approach to importing address data, avoiding discrepancies between imported and existing data.
Accuracy: Ensures address data is placed precisely at building entrances.
Sustainability: The use of nodes instead of ways simplifies future updates.
Efficiency: Speeds up the import process.
What’s Missing in the Wiki?
Removal of associatedStreet relations:
This should be addressed in the guide, as it will likely come up during the conflation and validation steps. Discussion: Forum post.
Visual Aids:
Adding more screenshots for better visualization of the workflow.
List of Imported Municipalities:
The list on qa.poole.ch shows a matching percentage. If this is over 97%, any import is usually unnecessary.
Building Geometry Updates:
The GWR address data sometimes places nodes outside improperly aligned or missing building ways. In such cases:
Missing buildings need to be added.
Misaligned buildings must be moved to their correct locations. This ensures that address nodes align with the actual building entrances.
I was wondering about “The house number should be added at another node in the building or at the building itself, not the entrance.” in the Data Cleanup section.
I always assumed that adding the address data to nodes tagged entrance=yes helps for pedestrian navigation.
Why do you think that the address data should not be added to entrance nodes?
Why do you think that the address data should not be added to entrance nodes?
I’d have a slight preference for the address on the building (preferably still with a entrance=yes node on the building outline) when the building has exactly one address. This gives the clear message “Everything inside this building shares the same address data”. Quite useful for POIs inside buildings.
When the address is on the entrance, then you need to make some guesses about the address of the POI. Something along the lines of: POI is inside a building outline → building outline has only one entrance with address → inherit address from entrance to POI.
I’m asking the same question about how we handling the POIs inside the buildings, without an answer until now. At the moment I’m also preferring the address on the building and don’t understand the advantages of the address on the entrance node. See: Frage zu Adressen - #6 by Karpose. I’m very happy with a clarification.
I clarified that this is a direct quote from the Tag:entrance=yes.
There are usually three (or four) different mapping styles for addresses:
Address on the entrance node withentrance=yes. According to the wiki, this method is incorrect. The import process typically places/moves the address node very close to the entrance node.
Address on the building outline or way withbuilding=yes. It doesn’t provide the same level of precision as a dedicated address node. It can be useful for associating POIs with missing addresses within the same building. However, for buildings with multiple addresses, this approach often requires splitting the building outline, even if it is a single, structurally unified building. The JOSM data validator, by default, does not include POIs in duplicate address detection. However, this can be enabled in the settings.
Address on a node that is part of the building way. In this approach, the address is added to a specific node from the building’s way, such as one located near an entrance.
Address in a separate address node. This is the method I recommend in the guide. It offers advantages over method 2, such as higher accuracy (as address nodes can precisely mark building entrances), better consistency, and easier updates in the future. However, there may be technical drawbacks if the address node is not linked to the building, other than by proximity?
For your typical single address residential building (by far the majority of all addresses) it doesn’t make anything simpler to add the tags to the outline and then add an non-address entrance node, actually it makes things more complicated. But I wouldn’t change existing tagging in this case without some clear additional benefit.
For multi-address residential buildings without POIs if you don’t use address tagged nodes, you have to create additional building polygons. Not only is this more complicated, often the additional buildings don’t actually exist and are totally imagined.
For single address buildings containing a POI it removes some redundancy and makes it easier to associate the POI with the “building address”, but lots of the POIs have addresses anyway and as you need to handle the case with addresses on an node inside the outline in any case (see below), you are really only getting marginal gains.
Multiple address/entrance buildings with one or more POIs, only thing that “actually works” is tagging the POIs with addresses plus some heuristic to handle non-address tagged POIs.
There is currently an unresolved issue with entrances (with or without addresses) that are not on the building outline as visible on aerial imagery. Currently I tend to not create entrance nodes for them, but some kind of consensus on how to handle this case would be nice.
I don’t see how that relates to the single-address building case. The heuristics you’d need to use for the multi-address case are not applicable. Or rather, they could be used but it would be a pain because these heuristics are fairly expensive to compute. Single and multi-address buildings will always need to be handled differently. So you might as well encourage tagging for the single-address case that’s simpler on the data user side.
Thanks for the guide. I always wanted to try to import addresses, but I was a bit afraid regarding all the procedure. One question remains though, where should we announce the import ? I guess in this forum. One thread per Canton, or a specific thread for all the addresses ? Or it’s considered as a specific and known import and we can ignore this requirement ?
Simply having to tag two objects given that the building typically already exists. Note that I’m not claiming that this should be universal policy, just that in Switzerland given what data we have available it would seem to make sense.
In any case the problematic cases are not residential buildings it literally doesn’t matter outside of potentially getting slightly better routing, they are the ones with POIs.
My point there was more that while tagging the address on the building and adding entrance nodes work for the POIs in a building with a single address case, it falls flat on its face for everything else regardless of entrance tagging or not. I could bore everybody with tons of examples, but here is just one OpenStreetMap
And just eyeballing it there, it would seem that there is an order of magnitude more POIs in multi-address buildings than the simple case. So should we simply lay down a rule (I know very funny in an OSM context) that POIs in multi-address buildings need to have addresses? Or what would you propose?
Hi
I appreciate a lot this guide. As i’m a newbie to JOSM it’s a great intro with a real world example (I understand to be very careful to not do a bulk update without proper checking).
As a small improvement I would do is in the section “review matches”. I would prefer to clearly split the paragraph into the three categories (matches, Reference-only cases and subject-only cases). As I don’t know exactly what they are, it would make, IMO, a better description.
I have reorganized the “Data Cleanup” section for better clarity and added a step to only select ways with address data where no POIs or names are present.
I added information on how to handle “Subject Only” cases.
Response to Comments on Grüningen ZH Import
I have made several imports in the past few days, focusing on areas with less than 60% address coverage. I’d like to address comments regarding my import for Grüningen ZH: Changeset #159514858.
Official Abbreviations in Switzerland
Is there a consensus in Switzerland about using official abbreviations as listed in the Amtliches Verzeichnis? In Grüningen ZH, abbreviations like “Binziker-Str.” reflect official records and local signage.
“Strassennamen sind mit der offiziellen Schreibweise (gemäss dem amtlichen Verzeichnis der Strassen) zu beschriften.”
(Source)
At the same time, the OSM Wiki recommends:
“Von den o.g. Regeln abgesehen, solltest du den Namen immer so eintragen, wie er auf den Straßenschildern steht, aber sei dir im Klaren, dass Schilder auch Fehler haben können.”
(OSM Wiki: DE:Abkürzungen)
Proposed Solution if Official Abbreviations Are Not Preferred
If the official name is not desirable in addr:street, alternative tags could be used:
alt_name: Common alternative names in use. (0.4% usage with addr:street in Switzerland)
short_name: Abbreviated name (e.g., “Binziker-Str.”). (0.04% usage)
official_name: Official name from the registry (e.g., “Binziker-Str.”). (0.01% usage)
Feedback on these approaches is welcome to define a consistent workflow for such cases.
In general there’s a preference to not use abbreviations in the name tag, exceptions noted.
Further, the official spelling as in the “amtlichen Verzeichnis der Strassen” is kind of problematic, not only is the “amtlichen Verzeichnis der Strassen” very young and even if the municipalities would actively be changing the signage (which they are not doing) you are likely talking about decades till this would be complete. The other thing is, it isn’t as if swisstopo is naming the streets, the municipalities are doing that with all the inconsistencies and errors that involves.
Just to illustrate the madness of trying to be completely consistent, in Wettingen there’s the
Alberich Zwyssigstrasse
The name in the GWR and “amtlichen Verzeichnis der Strassen” is Alb. Zwissigstrasse, signposted is Alb.-Zwyssigstrasse and Alb.-Zwyssigstr. naturally nobody will expand the Alb. correctly, so using the abbreviation is absurd (Swiss should btw know who Alberich Zwyssig was).
From a technical (aka geocoding/search) POV the addr:street / addr:place localisation value needs to match one of name, official_name, alt_name, local_name or short_name (and some others that are not relevant in this example). I would typically use the GWR / “offical” value in the address, and make sure that that value turns up in one of the street name tags.