Wiki: Swiss GWR Address Data Import Guide

Communities Switzerland
1

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:

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

  1. Preparation
  2. Data Cleanup:
    • Remove redundant or incorrect address tags (ways, nodes, entrances).
  3. Conflation Process:
    • Use the Conflation plugin in JOSM to match and merge data.
    • Review and manually validate matches.
  4. Handling Validation Warnings:
    • Review all warnings (e.g., duplicate house numbers, suspicious tag combinations).
  5. 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.

Further Reading

I’d appreciate any feedback, especially suggestions for:

  • Improving the workflow.
  • Identifying missing edge cases.
  • Streamlining the conflation and validation steps:
    • Can the information in the Conflation tooltip be displayed permanently in the conflation list?
    • Are there automated methods to select and zoom to select primitives one by one?

Thank you for your time!

3 Likes
2

Henne guet! Thanks for writing up that guide!

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?

3 Likes
3

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.

2 Likes
4

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.

1 Like
5

I clarified that this is a direct quote from the Tag:entrance=yes.

There are usually three (or four) different mapping styles for addresses:

  1. 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.
  2. 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.
  3. 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.
  4. 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?
6

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.

1 Like
7

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.

8

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

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.

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.

9

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 ?

10

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?

11

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.

12

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

13

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

1 Like
14

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
1 Like
15

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

16

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

1 Like
17

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:

  1. Imprecise Address Nodes:

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!

  1. 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?

  1. 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 yesterday
Address import improvement (= difference!) from yesterday1067×434 82.8 KB

18

At the Zürich OSM - Fondue meetup we touched a bit on the subject.

And not surprisingly we ended up discussing the old issue of what we should be entering for buildings: building footprint vs. roof outline.

Historically (that is before we had access to aerial imagery in any larger way) the rule used to be to use the building footprint (as good as that was possible). This has morphed to the roof outline (because it is simply that what you see from above) over the years creating tension between both ways of mapping, particularly in those areas where we have used the building footprint (for example in the Canton Berne).

I’ve suggested this before, but I’m fairly sure that the way forward is to retain both and use rough 3d tagging to combine the two. This would give enough context for mappers that are just seeing the aerial views what is going on, and net give us better data.

The consequence would be that imported building outlines should not replace the roof outline but be combined (we have a rough number of levels from the GWR, so we can use that).

I want to test this out, probably somewhere in Berne to see if this would work in practice, or naturally somebody else can try that out. It is clear that in very may cases this will require improving the roof outlines as they tend to rather old and date back to when Bing was the only reasonable quality source.

19

How do you map the roof outline together with the building footprint with 3D tagging? building:part=roof? Is there an example somewhere? It doesn’t seem to be straightforward.

Comparison OpenData-AV with swissBUILDINGS3D 3.0
Comparison OpenData-AV with swissBUILDINGS3D 3.0

An import of building footprint outlines is straightforward, with the availability (terms of use) and download links documented here: Karte :: Amtliche Vermessung :: geodienste.ch. Additional data could be added from the GWR: the type of building, construction year, and number of levels, which could be imported at the same time to enrich the building footprint.

Importing both building footprint and roof data from swissBUILDINGS3D would be less straightforward due to the inclusion of the third dimension. Positive: The footprint is mostly a bit less complex.
swissBUILDINGS3D - roofs, facades and floors as face objects
swissBUILDINGS3D - roofs, facades and floors as face objects

My view: Focus on improving the coverage, location, and outline of the building—in that order—whether it’s the roof or the footprint. Personally, I wouldn’t mind if someone changes the footprint from AV data back to the roof outline—as long as it has the correct location and isn’t based on outdated imagery.

In some cantons, such as Fribourg or Basel-Landschaft, the GWR dataset contains a significant number of minor building addresses, which I generally did not import. For example, see the missing address data for Crésuz FR: Crésuz FR Missing geojson.

In contrast, in other cantons like Zurich, minor buildings are often tagged as 1.1, 1.2, etc., which @SimonPoole has been removing already. However, Zurich is not entirely consistent in following this majority tagging approach. For instance, there are several examples where deviations from the 1.1, 1.2, etc., structure occur, especially visible in the missing geojson for Zurich. Example.

Most of these minor buildings are categorized under buildingClass 1274, which includes Schrebergärten (garden huts without residential use) and municipal structures like bus stops, public toilets, and washhouses. Additional building classes to consider include:

1274: Schrebergärten, bus stops, public toilets, washhouses, etc.
Examples from Crésuz: 1, 2, 3, 4, 5, 6
1251: Industrial buildings like factories, workshops, assembly halls, etc. Example: Link.
1271: Agricultural operational and storage buildings such as barns, stables, sheds, and other agricultural auxiliary structures. Example: Link.

Would it make sense to exclude all buildings classified under 1274 entirely from both the import process and the QA dashboard, or is there value in retaining addresses for structures like vineyard huts?
As for the other classifications, I’m less certain.

Edit (Quoted from the following post link):

There’s no real harm in having non-address house numbers.

20

See my comment here Address and Street Data Updates - #4 by SimonPoole on Zürich (city).

1 Like