In the location you referenced, the manual mapping of addresses to entrance=yes nodes by @datendelphin contains three (or possibly four, if you include the recessed entrance) errors in entrance positions, highlighted in yellow.
Yes, at Moosstrasse 2 I seem to have totally failed. I just went there and had a look again. I actually mapped the auxiliary entrance, because the house number is attached there. The main entrance is not well visible from the street, but of course there is a broad path to it which I should have recognized. I wish this embarrassment wasn’t so public.
More seriously, the nice thing to do in such a case would have been to ask me to check again. The state now is in my opinion totally unhelpful. The address node is in the right vicinity, but the entrance is in the wrong place. An ideal implementation would take entrance nodes into account and point the user to the wrong side of the building. And in actual life nobody would notice any of it because no one looks at the navigation to find the entrance in that particular case.
With my deep shame out of the way, I find it hard to continue this discussion. You repeat your arguments in a fundamental fashion, oblivious to any other perspective. The arguments you ask for have been mentioned here and also verbally. There is no more merit in weighing pros and cons when all arguments get swept away by you by some arbitrary precision and clearness standard.
Just pointing out one dissonance in your argumentation, almost the same that Sarah already did. You made this comparison before and after. The right most pane of that struck me as “blatant fabrication” because I vividly remember doing the addresses of the residential buildings there for an introduction to OSM presentation. So let me share a different view of that, from achavi:
achavi - Augmented OSM Change Viewer [attic]
Even though in your comparison it looks like there were no addresses, this seems more like a bug in that particular renderer. Because there were addresses. And have a look at the four buildings with green outlines in a row from middle top to bottom right. They had entrances at the side. Which is actually correct. Here the data from GWR is missing that detail. How would you know without being there? No idea. Each discrepancy can go in both directions. But by overwriting the existing data, we are deprived of one independent data set.
Clarification on Address Conversion and Data Deletion
The most valuable asset OSM has is its mappers that actually go to a place, because that generates truly unique (or independent) data. And the only thing we volunteers get in return is a good feeling. As I experienced myself, moving the data from an outline to a node, or moving it from a node and entering it with a new node, disconnects my work, the “history” from the current state on the map. This is psychological, but very powerful. At the risk of being selfish, we need to take care of those community members, and I weigh that a lot higher than an arbitrary precision argument. Grudgingly embracing Simons observation:
We have whole countries in OSM that use “address node in building outline” throughout and it hasn’t led to the downfall of western civilisation.
That also means such imprecisions that you pointed out are of no consequence either.
So my view for a compromise is: We can import free floating missing addresses. But do not touch already mapped ones. No matter what low opinion you have of basic mappers. We don’t even need to agree if that is irrational or well founded, the damage to the community is just too great.
And as a final remark: hard balling with arguments is quite taxing. This reply cost me 3 hours, and it is still too flippant, too emotional, too attacking unfortunately
