Since the GWR switched to including all buildings and not just those with a postal address a couple of years ago I’ve filtered out addresses of the form NN.N from the overall statistics (they are available in the files that contain “all” entries) as these are not “real” addresses, I’ve further refined that now by ignoring buildings with the category values 1010 and 1080 see GWR | Eidg. Gebäude- und Wohnungsregister
The changes and the update has reduced the overall count of relevant addresses in the GWR from 2’407’343 to 2’367’012 and the number of these missing in OSM from 732’394 to 698’960, the largest change probably being in Zürich which lost ~4’000 (Zürich is one of the municipalities that historically assigned any kind of building a regular house number, including for example the platform roofs at Altstetten station). The overall number of buildings (not addresses) in the GWR went up from 3’239’916 to 3’264’326 over the half year period since April.
I would note that it could be argued that the non-building buildings in the category 1010 should be included in the statistics, but there are only roughly 2’300 nation wide and even less with valid house numbers.
So the platform roofs at Bhf. Altstetten have their own housenumber? Wow, I didn’t know that…
In the specific case of Switzerland should we then always tag addr:housenumber on building=* polys or on entrances (barrier=gate/wicket_gate , entrance=*)? How do we keep track of phantom housenumbers like those you mentioned belonging to roofs etc.?
Per GWR house numbers are assigned to (building-)entrances in Switzerland so neither to the plot or the building.
However there are a couple of things to note:
not all cantons and municipality have all the necessary data (yet) in the GWR. For example the canton Ticino. In such cases the house number(s) are located on the building centroid.
there continue to be buildings that should have a full address assigned, but which only have a place/street value, typically farms.
and yes I could point out that swisstopo has managed to muddy the waters more than they already were, but lets ignore that.
There’s no real harm in having non-address house numbers. Matter of fact I have historically added them in Zürich because there are a fair number of cases where the ancillary buildings have a non-suffixed number (42) and the residential building is suffixed (42a) and it is then very confusing if you don’t map the non-suffixed number.
In any case lots of cantons and municipality didn’t assign house numbers to ancillary buildings before 2019 and they now use numbers with a dot in them (NN.N), with other words these are easily detectable.
I just spot checked Ticino and yes we still have the issue that the GWR has addresses on the building centroid and swisstopo uses AV data that has them correctly located (we discussed this on the mailing list back in April actually this was in May 2023 Re: [talk-ch] GWR Addressdata Update - talk-ch - openstreetmap.ch).
This is not a good state of affairs and maybe there should be consequences (hahaha)?
In any case I’ll probably add in the swisstopo entrance coordinates there is already some special casing for these cases but I was hoping that BfS and swisstopo would come to their senses and this could be dropped, no such luck.
replace the old count based coverage % (this goes back to the days before we actually matched addresses and was always just a rough estimate) with a coverage % based on actual matching.
various small bug fixes.
Note that the criteria we use to determine ancillary buildings are not perfect and there will be some slop. The shape files currently still contain all data except those with dots in the house number, that will be fixed as soon as I rerun the extract process.
One thing I might get around to this week is seeing if we can use the GWR building description attribute in any reasonable way (example addr:housename for buildings that don’t have a house number).
I’m interested in contributing by importing data from the GWR. While I’ve done my best to review available resources on the guidelines and best practices, I still have some questions. If anyone is available for a brief chat — ideally via video call with screen sharing — to walk me through some of the finer points, I’d appreciate the help.
I’ve made a start, and my initial changes are live here. Any feedback on these changes would also be welcome.
Thanks in advance to anyone who can provide some guidance.
Ah, simple issue: the daily generated statistics and files include only buildings with status 1004 (in use), so for example the files with unmatched/missing addresses and the statistics are correct*. Unluckily the one time per data update generated files just looked at building category and class and contained “too much” data. Thanks for catching that.
I’m re-running that extract of the static files as I type and they will be updated in half an hour or so. I suspect this isn’t a big problem in the first place due to it likely only affecting buildings that have been torn down since the GWR exists in most places.
* caveats wrt detecting ancillary buildings naturally still apply.
As a follow up to the discussion about multi-lingual places, I investigated a bit closer why Biel/Bienne had gone down in address coverage compared to the original stats from a couple of years back.
The reason is the GWR entrance data (at least in the CVS format) is denormalized and contains multiple entries for the same address (one per language), this doesn’t stop the matching from working but did leave bogus unmatched entries that would count against the totals.
I now renormalize the data (aka create one entry per entrance) for the statistics and for the generation of “missing” addresses data which brings things more in line with what they should be. It should be noted that
OSM address entries that are missing language variants of addr:street and just have a combined addr:street entry will not matched.
the “full” extracts of the GWR data currently continue to have duplicate entries, but that shouldn’t be an issue as obvious.
I strongly suspect that this mainly affects Biel/Bienne and Murten.
I haven’t made up my mind yet what exactly to do with them, in some cases there might be something that is usable as a addr:housename value, but that needs some investigation that I haven’t done yet (officially every building should have a house number, but that is “real life” vs. “amtlich”).
Here’s an example of a municipality where most addresses primarily consist of house names: Changeset 159517495 on OSMCha. In your dataset, these house names are represented as addr:place. Should I change the representation of these house names to addr:housename in this case?
That would be a definite “no”, addr:housename would never be derived from the street level localisation, but, just possibly, from the GWR GBEZ field. As I said, this needs investigation, as this would have to be dependent on other fields and heuristics (for example missing house number), excerpt from the raw GWR data for GBEZ:
Abri PC (souterrain)
Mühlemattweg 3
Selva Piana
Romain
Annesso laboratorio
manège
EFH mit Doppelgarage, Sonnenkollektoren
AUTO-UNTERSTAND MIT GERAETERAUM 1 STOCK
Haus 72
Casa di vacanze
batiment A548
Le Chicotin
Egli Erben
Bergrestaurant Bussalp
Verbindungsbau Süd (Bibliothek)
EFH -A mit Carport
Alpstublistall
Produktionshalle Schwarzhorn
Î Remointze
Les Palettes
Grillhouse
Wohngebäude mit Gewerbeteil
altes Spritzenhäuschen
Liegehalle und Kälberstall
Chalet Delphin
Palazzo Bonetti
Hotel Roi Soleil / TS 133 Stahlbad
Villa 12
EFH G16
Alphütte 2 von Tannen
Seestrasse 111c
Understood, I’ll keep these as addr:place. My concern was the absence of a distinct place node. Edit: As a result, they also appear in the missing roads list: http://qa.poole.ch/ch-roads/SZ/1363.html
After a quick look, the GWR data doesn’t include a GBEZ field in Illgau.
Well the place nodes/areas are missing https://qa.poole.ch/ch-roads/SZ/1363.html It should be noted that while Nominatim corrects for this internally, it is questionable if we should rely on such a mechanism.
As promised I’ve given the GWR addresses with missing house numbers another look.
There’s a total of 22’265 buildings with a number that have a non-empty gbez (“Gebäude Bezeichnung”) field and are otherwise legit (status in use). Spot checking these would indicate that for most of them gbez is not really useful, but if you narrow it down to hotels and similar there 239 entries that are potentially useful see https://qa.poole.ch/addresses/GWR/no_number_1211_1212.txt (yes there are some obvious misclassifications).
Given that most of the GWR entries without a number don’t seem to be useful I’ll remove them going forward from the daily stats and files. Not today though. If I find any other class of buildings for which gbez is useful, I’ll generate extracts for them, but I kind of doubt that there is much more.