Don't render house numbers for `amenity=car_sharing`

[dreua]

Expected behavior

It has been decided to not render car sharing (#1891) so I'd expect it to not render anything.

Actual behavior

amenity=car_sharing with an address shows up as a house number on the street. This is expected to be the address of a building close by so it is very unlikely to add any value and much more likely to cause confusion. In any case it looks bad.

Screenshots with links illustrating the problem

https://www.openstreetmap.org/node/9141226027

We have quite a few of those in Mainz: https://overpass-turbo.eu/s/1EmC

[HolgerJeromin]

Perhaps this information should be a ref instead of an addr:housenumber. Not sure about this...

[dch0ph]

Yes, this seems a misuse of addr:housenumber. It's not a question of whether amenity=car_sharing is rendered (it isn't). Basically any node with addr:housenumber will show up with an "address".

This doesn't seem to be a ref number, just a duplication of the closest genuine address onto another feature (which would be poor/incorrect tagging). Or perhaps this is the way these sites are labelled locally?

[HolgerJeromin]

Same with postboxes (at least in Germany):

https://commons.wikimedia.org/wiki/File:12-04-21-wildparkstrasze-ebw-by-RalfR-11.jpg

[dreua]

Thanks for the input, I'll check whether we can fix that by tagging differently.

[imagico]

An additional note for clarification: The way we render housenumbers relies on the application of the One feature, one OSM element rule w.r.t. addresses. This is widely the case, but not universally, in particular the whole SEO sector is adamant at adding address information to each and every business under a certain address even if the building already has this or there is a separate address node. This does not show visually in the map as long as we render the feature in question (shop, office, etc.) in some way, because the housenumber labels have lower priority. But for those features we do not render which have a duplicate address information tagged it shows up of course.

Now we could try to de-duplicate those (though it would be fairly expensive - with an additional spatial query for every address). But the thing is that this tagging is inherently ambiguous, because it uses exactly the same address tagging for the actual address (the plot/building/building entrance that the address is verifiably assigned to, where the postal service would try to deliver a letter to that is posted with that address) and for features where the address data is just piggy-backed on to indicate the feature belongs to that address somehow. In other words: In case of duplication of the same address there is no distinction between the declarative use of the address tags (this feature represents that address - which is the consensus use among mappers) and the referential use (this feature belongs/is related to that address). Trying to hide this inherent ambiguity in tagging practice through some heuristics in de-duplication of addresses would not be in support of our mission.

See also #1746.