I propose to define and tag addresses more clearly as a POI category. The idea is to introduce a category/feature tag (e.g. address_feature=yes) just like all other categories have it (e.g. amenity=restaurant for restaurants).
Reasoning
With the OSM tagging schema, it’s currently very difficult to decide what places fall into the address category. You need to check whether addr:housenumber=* is present and make sure that the place is not in any other POI category. This part is difficult as OSM has a lot of categories and new ones are introduced regularly.
In practice, this often leads to places that actually aren’t addresses being displayed as such. The problem is e.g. quite prominent on CycleOSM as the map style does not support many shop categories, but it’s also present in other styles like OSMCarto or CoMaps.
In general, the problem is that when addr: tags are used, it’s not clear whether the place is an address POI or whether the addr: tags are just an attribute of a POI with a different category.
Therefore, I propose to tag addresses in a way that’s more consistent with how all other categories are tagged and make the OSM data easier to use for data consumers.
Tagging Details
The idea is that every address is mapped exactly once as an address feature with address_feature=yes. (So when there is an address node and a restaurant node with the same address, only the address node should be tagged with address_feature=yes. When the address is not mapped on a node, but on a building, only the building should be tagged with address_feature=yes.)
In countries where it’s uncommon to tag addresses separately, the address_feature=yes can be combined with other categories (like e.g. shop=*).
Compatibility with Current Tagging Schema
No breaking changes are introduced, data consumers that ignore address_feature=yes can use the OSM data the same way they did before.
I appreciate that this proposal would address (hah) perhaps the most common case of homonymous keys. It would be a lot easier to explain that addr:*=* are always attributes. The challenge of course would be getting to that point, since there are already so many free-floating address points. Similarly, highway=traffic_sign was introduced long after mappers started putting traffic_sign=* on standalone points, so at least there’s precedent.
Instead of the fairly verbose address_feature=*, could we commandeer the long-deprecated address=* or formalize addr=*, which classifies addresses as “main” or otherwise?
But also a gargantuan effort to get to that point. Get an approval through. Get the major editors on board. A bot or two to make some of the changes automatically. Are you up to spearheading such a long term endeavor?
I would be very much be in favor of using addr=*. Could be addr=yes/main/other useful options.
Whilst I cannot fault your ambition, I suspect that retagging literally anything with an address is a big ask.
Perhaps try doing that locally to you (you say that it shouldn’t break anything; it’d be good to say that demonstrates and what the extra data allows data consumers to do)?
I found address= seems to be treated as a synonym/mistake of addr:full= by some applications. So addr=main should be what’s considered. I don’t like the opposite contact:*= method for address-as-attributes, which redefines and pushes away the original use for correspondence addresses with no replacement.
I do think we should have a dedicated top-level address feature type with its own identifying tag.
I also think allowing that identifying tag to coexist with any other top-level identifying tags would be a mistake that undermines the utility of a movement around this.
In the common case of buildings, e.g. detached homes, that have have one and only one, unique, address (as appears to be the case in your changesets), per 1F1E the address can simply be tagged directly on the corresponding structure, no need for a separate element for the same feature
If an apartment building has the address 100 Main Street which contains units 1-4, the building way would be tagged addr:street=Main Street + addr:housenumber=100, while individual units would get their own address nodes addr:street=Main Street + addr:housenumber=100 + addr:unit=1, etc.
A typical duplex with housenumbers100 and 100A would have its building way split and the appropriate addresses tagged on each semidetached_house.
Conversely, e.g. if a “condo” style house has different housenumbers (as opposed to units) for different levels, or different parts of the building (that are not clear from the outside), the addresses would be tagged as nodes(with level=*, if known) and no address tagged on the building.
If an apartment complex has one housenumber for the entire complex, with individual buildings within it each containing various unit numbers (as is the case where I live), generally recommended practice is to tag the overall address on the perimeter of the site (i.e. landuse=residential + residential=apartments + name=ABC Apartments + addr:street=Main Street + addr:housenumber=100). For the individual units, the wiki suggests also tagging addr:housenumber=* and addr:flats=* on each building in this case, but the way I’ve usually seen it this handled in the US (and the way I’ve handled it myself, as is also closer to your mapping practice) is individual address nodes with addr:unit=*, ideally placed roughly where the unit is in the building and with level=* if known, which provides additional information and precision over building-level tagging.
When the answer to “How do I map an address?” could (should) simply be “Make a node and put address tags on it”
re: “One feature, one element” - that’s a general best practices guideline, not a rule; and even if it were, we’re conflating two concepts: an “address” as a feature, and an “address” as an attribute.
The “one element” for the “one feature” of an address should just be a node with only addr:*=* tags (and metadata like refs to source datasets if relevant) and no other identifying fields like building=* or amenity=* etc.
The rest of the addr:*=* tags on nearby elements (buildings, POIs, entrances, whatever) are attributes. It’s a trade-off of mapper burden (in the sense of both tagging it in the first place and maintaining alignment if something changes) to data consumer ease of use (in the sense of not needing to check other elements for which address is associated with the given feature).
@Lumikeiju: Maybe it’s time we propose use a new identifying tag for address features?
Then it’s easy to query for thisIsJustAnAddress=yes (or whatever) or to find objects with that tag and any non-addr:*=*-or-ref:*=* tags for QA.
So we would have the same address as a dedicated node/on the outline and once as the POI?
How about multiple buildings sharing the same address? I don’t see much of a need to add address_feature=yes to a buiilding=*. Where is the difference on filtering?
What would be your definition of “Places fall into the address category”? Aren’t you actually looking for something like poi=shop/amenity/... so you can filter for poi=*?
I’m a bit confused by the proposal, but do you mean to add a address=main type of tag to nodes that consist with only addr:*=* tags? Meaning it wouldn’t be used on nodes/ways that contain address tags along with other tags, i.e. building? Or maybe add there another address=*tag to differentiate from the “address-only” node? Which would pretty much eventually associate the “Address” preset of iD with an actual tag directly and not just an empty point?
I’m a little uncertain about the original proposal as whole, but I’m really not following this part. Does that mean, then, for nations where buildings are assigned addresses (e.g. the US, more or less), in addition to tagging the address on the “on the ground” feature its actually assigned to (i.e. the building way) as is general convention, you’d also need to create a separate address node with ? Likewise, in e.g. those European states where it is doors (entrances) that are assigned addresses, in addition to tagging the address on the actual door (entrance=*), you’d need to create some nearby floating node with the duplicating the same information? Plus in addition to both of those, address tagging on any POIs at that address (assuming they are separated, which seemed to be the general consensus of previous related discussion)? Or are you proposing no longer tagging the address on things its assigned to, and requiring consumers to guess?
I’m also not exactly clear on the concrete benefits justifying this constraint. Could you perhaps explain further?
It can make mapping much more complex than what we have now, particularly in Germany (as in your example), where the Federal law requires building plots to be numbered, but the details can be set by the Länder, and these typically leave the details to the municipal level, as in your example: https://stadt.muenchen.de/rathaus/stadtrecht/vorschrift/310.pdf
Today, everybody can just map a housenumber they see, without having to bother about its extent. If there are POIs, you can also add their addresses, and if several addresses are the same (housenumbers), you know they somehow belong together and the address is valid on all these spots or areas. If on the other hand you want to map a unique official address you will also want to map it to the “object” it was assigned to (could be an entrance, a building or a building plot, or whatever), and to do it you will have to know what is was, it will not be sufficient anymore to just see a number posted near the entrance door, maybe the address is assigned to the door but maybe it is assigned to the whole plot and you’d have to map the plot to represent this well.
Just to add that we would need to define what’s the lowest addr-level is. Is it the house number or the unit? Like the whole mall might be addr:housenumber=42 and each shop in there would have additional addr:unit=*. What would be now “main” address-objects? One per unit and one for the mall?
I understand the issue is, that renderer use the addr:housenumber as substitute if there is no name on a object with addr:housenumber (for example shop=vacant) which looks “ugly”. On the other hand those addresses on a residential building (which also come with no name) are welcome. In order to avoid the renderer needs to exclude amenity/shop/... this tag should allow kind of the opposite. Only render addr:housenumber as a substitute for name if that tag is present.
Seems to me like a renderer could simply only render addr:housenumber on ways/nodes with a building=* tag, and on ways/nodes with no tags other than addr:* and source*? There would be some false negatives, but a rather small amount.
If the only issue is rendering, same street and housenumber addresses could be deduplicated in preprocessing, their collective centre calculated and rendered just once. The guiding rule for mapping since the beginning is that mappers shouldn’t do manually what a machine can do automatically. If the aim is to add the addresses where they were actually assigned to, we’d have to map lots of building plots/parcels in many places.
That’s not a reliable approach, it will break as soon as e.g. a new tag for matching addresses to an official address database is added to OSM (so a tag like e.g. ref:linz:address_id=*). The Any tag you like approach of OSM makes it very hard do decide which tags are attributes and which specify the POI category.
