I support the reverts from @Taktaal, as it reverts many addreses from “flying” points back to the outline.
As a database aware user (and yes, OSM is primarily a database) I have a preference for setting addresses whenever possible to the outline of the building (mainly to prevent duplicates). I’m investing hours to improve OSM as well as I can and with your automated imports my work is (in my point of view) corrupted in minutes. This is frustrating and demotivating and is even visible in my edit activity:
I would very much welcome it if we could achieve a situation in Switzerland where it is clear how we whish to map addresses correctly. I see two camps (points vs. outline) and it is quite frustrating to see changes in both directions (mapping war).
So my question is: what is the best way to get this best practice? Since thousands of addresses already simply imported as nodes, a pure number comparison already drifted.
I would be much more motivated again if I would know the “right” way…
I honestly don’t even mind the discussion between “addresses as tags on buildings” and “addresses as a node in the building” that much. I understand that different people (and regions) have different preferences, and we have bigger issues than to get all angry about one of those mapping styles.
But I would insist that if one wants to map addresses in the second way, that the address has to be inside the building, not outside. If addresses are mapped like this then it becomes really messy to assign the correct address to the correct building.
@Taktaal, regarding your earlier changeset comment on changeset/165959110 about a “52% error rate”: Could you clarify how this was determined? Was it based on visual rendering, like the Horgen example where the ‘a’ suffixes weren’t displayed, or are there other specific data errors you found in that changeset?
A 52% error rate as in this case is not acceptable for an automated report.
@Piz_Pachific Please revert any of my changesets in areas you map if you notice a significant negative impact. I’ve stopped mapping in regions where there are active address mappers and many addresses placed on building outlines, so hopefully this makes things easier for you and helps maintain your motivation.
My observation has often been that these “flying points” (my precise entrance nodes) highlighted pre-existing inaccuracies in building outline placements.
For example, the work @Taktaal did to correct building outlines is appreciated (even though address entrance position data is lost):
I believe my correctly placed address nodes actually helped identify these areas where building outlines needed improvement. Once outlines are correct, the entrance nodes should align properly.
Assigning addresses to buildings is necessary when POI nodes lack addresses. Am I missing any other use cases besides appearance?
You deleted 52% of manually edited addresses in that area to instead replace it with your automatically imported ones. The other 48% did not involve a deletion but created new address that didn’t exist before. But among those 48%, quite a few (maybe a quarter?) was badly placed and should’ve been manually corrected.
As you can see from the examples you provided, the address placements I added were not wrong, and the accusations about systematic errors have not been substantiated. I spent many hours carefully reviewing conflicts and made numerous manual corrections where necessary.
Since November 5th, I have actively sought community feedback - including at OSM meetups (starting November 11th) - specifically to ensure a transparent and well-discussed approach.
Therefore, I would appreciate it if you refrain from repeating claims that these were “automatic” or “undiscussed” imports. Repeating those statements does not make them more accurate.
For context, here is a summary of differences before (7.2.2025) and after (9.5.2025) your reverts:
Municipality
OSM Total
OSM Buildings
OSM Nodes
Matching
% Matching
Matching ancillary
Missing
Different or missing postcode
Different or missing city
Distance more than 50 m
addr:street instead of addr:place
addr:street/ addr:place missing
Not official
Non-GWR
Warnings total
Baar
-471
2123
-2594
-576
0
17
582
80
85
8
45
22
-8
34
175
Dielsdorf
-726
289
-1015
-694
-49
-6
596
92
153
3
1
0
-95
7
57
Eglisau
-639
545
-1184
-654
-32
10
627
220
267
4
15
1
-28
27
272
Einsiedeln
-1958
1774
-3732
-1819
-31
-1
1690
107
149
20
46
5
-122
99
187
Horgen
-741
2668
-3409
-983
-6
117
956
206
215
1
35
21
-30
96
323
Neuheim
14
170
-156
-18
11
18
18
5
5
2
18
0
0
9
19
Niederglatt
-665
244
-909
-757
-70
-3
754
106
139
3
0
50
-3
18
203
Oberägeri
-184
1038
-1222
-233
-7
1
228
8
10
0
3
18
-5
5
31
Rüschlikon
-453
808
-1261
-454
-26
-31
434
6
7
6
0
1
-15
56
53
Stadel
-461
200
-661
-467
-59
9
465
38
85
1
0
0
-3
4
85
Steinmaur
-324
411
-735
-310
-32
-6
284
17
179
0
6
0
-14
8
158
Unterägeri
50
968
-918
-3
8
5
8
3
2
8
8
-3
0
67
81
Walchwil
20
644
-624
7
7
0
3
5
8
1
2
0
1
19
29
Wil (ZH)
-316
265
-581
-323
-49
6
319
34
59
0
11
0
-4
4
59
SUM
-6854
12147
-19001
-7284
-28.5
136
6964
927
1363
57
190
115
-326
453
1732
You deleted 6854 addresses and added back a significant amount of flawed data to the database. I’m fine with your reverts (aside from the inaccurate claims), as long as you are aware of the consequences and the fact that some missing or incorrect address data may remain uncorrected and missing for years.
i.e. on this edit Changeset: 161248861 | OpenStreetMap did you manually place 1140 nodes in the editor, then submitted it? Or did you import them from another database?
Sorry for just suspecting you of automated importing, it just seemed extremely unrealistic that someone would manually add more than a thousand objects in the editor without saving at least once in the middle, then do it again 30 minutes later. That’s an object added every two seconds and I don’t think any human works that fast.
For each such import (including Liesberg I manually reviewed the data of the whole municipality before uploading. Every conflict with existing mapping was checked and resolved by hand. I cross-verified with multiple sources (cantonal GIS, aerial imagery, etc.), and fixed many errors in the process - some even present in Google Maps.
For the Liesberg changeset, I also addressed numerous JOSM Validator warnings (e.g., splitting ways to add covered=yes, ensuring buildings exist for as many addresses as possible, correcting locality names and landuse areas, and moving buildings for better accuracy). Importantly, based on previous feedback, I made sure not to overwrite manually placed addresses on building outlines.
Describing this as “just an automatic import” doesn’t reflect the considerable manual validation and local corrections involved. I’m always open to constructive suggestions on how to further improve the process. If address-nodes are not wanted in the community, I would try to adjust that.
