Wiki: Swiss GWR Address Data Import Guide

spalinger · 2024-11-17T22:23:22.009Z

Hi everyone

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:

Usage of cadastral websites of a canton to map OpenStreetMap
Frage zu Adressen
Vaud: Améliorer nos villages

“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?

lonvia · 2024-11-18T10:06:48.192Z

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.

Karpose · 2024-11-18T10:33:09.891Z

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.

spalinger · 2024-11-18T11:06:28.280Z

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 with entrance=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 with building=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?

habi · 2024-11-18T11:22:30.208Z

lonvia:

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.

That makes very much sense, thanks for the clarification.
Then it’s also good that this is stated as such in @spalinger’s Wiki page.

SimonPoole · 2024-11-18T11:54:25.482Z

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.

lonvia · 2024-11-18T13:31:47.151Z

SimonPoole:

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.

Can you elaborate? For whom does it make things more complicated?

SimonPoole:

[…] but lots of the POIs have addresses anyway

That is not what I see in the data.

Asking taginfo about the number at addr:housenumber tags on shop nodes tells us that 23% of shop nodes have an address. Things are slightly better-looking in Switzerland where 38% of POIs have an address.

SimonPoole:

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.

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.

imagoiq · 2024-11-18T19:10:14.862Z

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 ?

SimonPoole · 2024-11-19T19:18:17.962Z

lonvia:

Can you elaborate? For whom does it make things more complicated?

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?

jerem0808 · 2024-11-19T20:59:24.122Z

spalinger:

es nodes outside

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.

spalinger · 2024-11-19T21:42:53.054Z

I’ve added screenshots. Does this help, or is further explanation needed? Let me know if any areas require more clarification.

jerem0808 · 2024-11-21T19:55:33.379Z

It helps yes. Maybe adding a small comment on the “subject only” part. Anything to do with it?

spalinger · 2024-11-24T21:59:16.799Z

jerem0808:

Maybe adding a small comment on the “subject only” part.

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.

Post-Import Improvements for Grüningen ZH

Municipality	Matching	% Matching	Missing	Different or Missing Postcode	Different or Missing City	addr:street Instead of addr:place	Non-GWR	Warnings Total
Grüningen before Import	529	56%	404	15	9	29	360	396
Grüningen after Import	933	100%	0	0	0	0	43	44

SimonPoole · 2024-11-25T08:54:14.048Z

spalinger:

Response to Comments on Grüningen ZH Import

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.

Simon

Piz_Pachific · 2024-12-05T10:55:28.617Z

Hi everyone

I don’t have much time these days, but although I welcome the opportunity to increase address coverage, I’m not sure about the way it is recommended here.

I see that @spalinger puts a lot of time into the automated import, but unfortunately I’m not very happy about it. On the one hand, because very precise and manual mapped addresses on buildings are being replaced on a large scale by sometimes very imprecise address nodes somewhere in the landscape and, on the other hand, because I personally find these address nodes without a reference point (building outline/entrance) not very practicable (see e.g. above regarding duplicate addresses at POIs). Is there a consent about it I missed?

And yes, I’m also interested into an answer about the handling of duplicated addresses on POIs. In relation to a database (which OSM actually is), these duplicates are very unfavorable. That’s why I’m also team building outline for addresses with node(s) for entrance(s).

Is there a way to reach an agreement before hours of work are wasted on a large scale?

Thank you very much and happy mapping

spalinger · 2024-12-05T14:02:00.768Z

Thank you for your opinion!

I focus on areas where no or almost no effort has been made to map addresses, as shown in the attached statistics. I no longer replace manually mapped addresses on buildings on a large scale, as I did, for example, in Rüschlikon.

I plan to edit the Wiki as follows:

In areas with substantial existing coverage (addresses already mapped), keep addresses on buildings (e.g., Wichtrach BE, most changes due to associatedStreet though).
In cases where address quality is poor (e.g., nodes not positioned at entrances), avoid importing nodes.
Additionally, I will include guidance on importing addresses onto existing building outlines.

Maybe a differentiation between cities (address nodes) and the countryside (addresses on detached houses/Einfamilienhäuser) would be a better approach?

Regarding your points:

Imprecise Address Nodes:

Piz_Pachific:

very imprecise address nodes somewhere in the landscape

I mostly, if not exclusively, encounter buildings placed incorrectly rather than imprecise address nodes. However, if you have specific examples, I’d be happy to review them. I truly do my best to avoid such issues!

Minor Buildings (e.g., 1a, 1b)

What’s the community’s stance on importing minor buildings addresses? In the Canton Bern import, these were mostly included. Is this the preferred approach?

Practicability/“Very precise and manual mapped addresses on buildings”

What exactly makes address nodes impractical, aside from their appearance? As far as I know, we are not importing EGID/EDID data which could link them —correct?
How do you measure the “precision” of “very precise and manual mapped addresses on buildings,” especially when official address numbers are assigned to house entrances?

Address import improvement (= difference!) from yesterday1067×434 82.8 KB