Hello, I’ve created a proposal to add support for tagging multiple addresses on one object: Proposal:Alternate addresses
Any feedback is welcome, please discuss in the talk page on the wiki.
I’m also looking for more examples where this tagging may be useful, from various different regions. If you have an example you think would be good to have listed please let me know. You can ping or message me in the OSM Discord with @joelkoen.
Having multiple addresses is occurring here for many POIs, the typical situation is POIs having several housenumbers on the same street (I usually map all individual addresses (which are on the entrances) and also add a range to the addr:housenumber of the POI, admittedly it is not completely undisputed), but ocassionally there are entrances on different streets involved (mostly with corners, more rarely when internal plots have access to several streets).
There is no clear convention yet when different streets are involved, so I appreciate the proposal.
Here’s an example of a POI with 2 addresses, both mapped in the same standard keys and separated by a semicolon: Node: Bar sotto il mare (4228917345) | OpenStreetMap
Here’s an example of 2 housenumbers mapped with individual keys (the other one addr:housenumber2): Way: 15 Moosburgstraße - Via Moosburg (281011974) | OpenStreetMap
Here is an example of 3 streets associated with an object: Way: Istituto Tecnico Industriale Giuseppe Omar (356305649) | OpenStreetMap (uses addr:street, addr:street_1, addr:street_2)
My guess is, as there is no clear rule yet, quite often people would simply omit the alternative addresses, or add them to the description or note.
On the other hand, in your houses-with-several-addresses-examples, like here:
Please dont - The current state of affairs is already complex enough. There is no problem in just dropping multiple nodes with their respective self contained dataset. Mixing this up just opens a TON of worms. There is no need for this.
Flo
Checking the proposed key by looking at the current global usage numbers for addr:street variations, without digging deeper how they came into life, I see these numbers:
addr:street2 3516
addr:street_1 1730
alt_addr:street 1347
addr:street_2 323
alt:addr:street 51
addr:street1 35
addr:street:1 9
addr:street-1 0
addr:street:2 0
The addr:street:n syntax is among the least used, strangely, addr:street2 has much more uses than addr:street1 (or any other variant).
I tried to get information about addr:street2 with ohsome, but it seems overloaded. @tyr_asd provides a nice tag usage history tool which seems to confirm that usage is organic (at least partially, there are some jumps but it is not just a single import or project):
I agree there is likely no need for this for addresses as features (it is either or) but there is for addresses as properties: POIs having several addresses (in particular with different streets involved).
Thank you for the examples, the school with three streets is interesting - I think in this case it probably makes more sense for the address to be kept on the entrances. Is the tagged address (12) the main entrance?
Do you know to which objects the authorities assign the addresses in the area in question?
Here in Queensland Australia, addresses are assigned specifically to land parcels. The location/dot of the address is just the center of the land parcels. I’m not sure exactly how addresses are assigned beyond that, but I think that might answer your question?
I’ll admit it’s quite strange given there aren’t entrances that map to these numbers, but it’s very common on corners here.
it should be tagged on the entrances, each individual address, and the POI (school in this case) could / should get all of them (as properties), there is no either or (or could get the ones that they “use” themselves).
There is no problem in just dropping multiple nodes with their respective self contained dataset.
Sure, that may be valid in your area, but did you read the first part of the proposal, which gives some problems with this approach?
There’s demand for a way to tag addresses like this, so I don’t see how trying to standardise it is a problem.
Yeah, to me that sounds like a good use case, especially if there’s no other way to associate those entrances with the POI?
Also, the example you first linked is great, thank you.
how do authorities communicate this to the plotowner (or: how is it registered in the land registry?), are they alternative addresses which the owner can choose as they wish? If there isn’t even an access to the alternative street required, I can imagine the situation of multiple addresses is quite common? Is there a “main” address and secondary addresses, or is the decision which one will be put in “addr:street” and which in “addr:street:1” completely arbitrary?
Let me try (quoting from the proposal):
- by tagging addresses as separate nodes, addresses are no longer meaningfully associated with a specific object, and it becomes unclear what address nodes actually refer to other than a specific location.
By now, all data consumers have learned that they must do geospatial analysis to reliably associate one or more POIs with a plot/building/area. Addresses are no exception, so taking them out of the equation does not relieve them from doing that.
Even if the proposal gets accepted, xkcd 927 still applies. Thousands of objects shall not be retagged to the new scheme anytime soon, so the data consumers will have to continue supporting the dreaded multiple-points-per-area approach. (That has served us well all those years, warts and all.)
- separating multiple addresses that refer to a single feature is against one of OSM’s best practices: One feature, one OSM element
That’s the most misapplied OSM principle ever, and quoting it invariably denotes not much more than “I don’t like this”, so I’m unimpressed by default. Whenever the principle is pulled in a discussion, I’d like to hear a use case where it does make an actual problem.
- it is not possible to tag one of the address nodes as a “primary” address, and the others as “alternative”.
It is not indeed, but is it really a problem? The primary use of addresses is forward geocoding (finding a location of an address). If you have a POI or something at that location, you can tag the primary addr information to its point. If there’s not a POI (i.e. it’s just a house), who cares?
Not connecting addresses and POIs is mostly not an issue when going to a place, but it leads to incomplete reverse geocoding results, and if the POIs use the addresses arbitrarily you might think there is 2 of them when there is really just one which has 2 alternative addresses. Why shouldn’t we strive for a coordinated way of adding alternative addresses, if they actually exist in reality?
So, what’s the use case where this could pose an actual problem? 
I’m not suggesting that’s an incorrect way to tag addresses. Tagging a house with multiple addresses directly is simpler to reason with, and arguably more correct if that house does in fact have two addresses, but that’s probably more of a “local mapping style” thing.
Even if the proposal gets accepted, xkcd 927 still applies.
I think you’ve taken this proposal the wrong way. It’s not competing with the style you have, it’s not saying it’s wrong to tag as multiple separate nodes. There are situations where real mappers are reaching for some way to tag multiple addresses on the same object, and there is currently no standard for this - this proposal is trying to fill that gap.
*Also, do you link to this for every proposal?? You’re not really raising a point here that’s specific to this proposal.
It is not indeed, but is it really a problem? The primary use of addresses is forward geocoding (finding a location of an address). If you have a POI or something at that location, you can tag the primary
addrinformation to its point. If there’s not a POI (i.e. it’s just a house), who cares?
Sure, for forward geocoding you could say it’s not a significant issue, but there are still other problems as mentioned directly under that proposal. Mappers have no control over how address nodes are displayed or chosen when they’re lumped together like this.
After doing some research, every property’s road names and numbering are managed by the local government authority for that area. For alternate addresses that are on their own street, yes being next to the street is required. It looks like these alternative addresses are supposed to be for additional entrances, but are assigned regardless of whether there is actually an entrance there or not (though this varies by local government).
I’ve also come across some addresses where the government assigned “primary” address does not match the address a house uses on the ground. Both addresses are still valid addresses though, which is part of why I’ve started this proposal.
Another example I should probably add is when a building is built across two land plots, inheriting both addresses. Only one address is used in practice, but both are still valid.
Every gap-filling is generally a double-edged sword: if you invent a new tag/scheme to make life easier for mappers, you will make life more complex for data consumers. Nowadays, they probably do not expect and do not know how to resolve addr:2:*, so many of them will have to adapt their code, or risk misbehavior of their search engines.
No. Personally, I don’t like to be a “party-killer” and usually abstain from commenting on most proposals I don’t know/care about. But every proposal that aims to resolve a multiple-standards situation (such as synonymous tags) must take into account xkcd 927, and propose a way forward how to resolve ambiguous situations, deprecate unwanted schemes, and end up in an overall improvement of the model and its consumers. Just adding a new tag or two to resolve corner-cases does not cut it, sorry.
you have several lists of POIs, and in one list the POI has address 1 and in the other it has address 2, and in your way of mapping you cannot tell for sure if they are the same or 2 distinct objects.
yes, this happens in many places which assign addresses to plots (I am familiar with it in Germany), and it is very common in places which assign addresses to entrances (or even potential entrances like shop windows, as is mandatory in Italy). If the street is the same, you can list several housenumbers in the addr:housenumber tag of the feature, and add individual addresses to the parts where they are assigned to (e.g. place=plot in your case). Note that the plot tag, as currently written in the wiki, should not be used for imported plot boundaries, but is reserved to situations where the plot boundaries are appearently recognizable from looking at it.
Every gap-filling is generally a double-edged sword: if you invent a new tag/scheme to make life easier for mappers, you will make life more complex for data consumers. Nowadays, they probably do not expect and do not know how to resolve
addr:2:*, so many of them will have to adapt their code, or risk misbehavior of their search engines.
Ok. This proposal specifically suggests that existing data isn’t merged until popular software has support.
Furthermore, this proposal could even be backwards compatible by simply converting the extra tags into address nodes as a step before ingesting new data. If they don’t have support for the primary/alternate part of this proposal, that would functionally be the same thing. It also wouldn’t be complicated to do.
Yes, adding multiple numbers to addr:housenumber does currently work, but it isn’t possible to specify one address as primary/for display.
