Proposal talk:Multiple addresses
I oppose this, those addresses should be put on different nodes, which can be collected into one object with the building by using a site relation. This is the mechanism we have, even though it sounds more complicated. But then, for any tools working with the objects, differing tags for one and the same thing are even more complicated. Robert Kaiser 13:03, 12 August 2012 (BST)
- Well, if you believe that a relation together with a myriad of nodes are less complicated than just a few tags, I will not be able to convince you. Do you also make nodes and relations for alternate names? --Fkv 07:40, 15 September 2012 (BST)
I oppose this. It's not backward compatible and adds no real value. How does this scheme make it less pity for applications? It makes it more complicated with the need to look for n-dimensional list of tags.
- It does work for name:<language> already. --Fkv 07:40, 15 September 2012 (BST)
Most applications will work on existing schemes and ignore this.
- This is a fate for all new tags. Should we stop making proposals? --Fkv 07:40, 15 September 2012 (BST)
multiple addr* tags on an area are misleading and it's impossible to assign an address to the correct entrance or side of a building
- There's no correct side of the building, because an address pertains to the building as a whole. --Fkv 07:40, 15 September 2012 (BST)
The correct algorithm to find address for a building is to do a spatial search of addr nodes inside the building polygon. A site relation is an option but error prone and overkill. User:Apo42 13:03, 14 August 2012 (BST)
Different spelling and different addresses are not the same. There is needing index for street\housenumber too.
For example house on the corner.
Basic address:
addr:housenumber=5/8
addr:street=First street/Second street
We also want pure addresses. On the first street it will be the same with different spelling, but on the second it will be different address.
addr:2:housenumber=8
addr:2:street=Second street
addr:street:2=First street
addr:housenumber:2=5
And we may even want to find spelling of crossroad from the second street
addr:2:housenumber:2=8/5
addr:2:street:2=Second street/First street
Without second index we can't add spelling. If you'll try to add spelling in my example even without spelling of crossroads you will need repeat housenumber for every spelling.
--Scondo 20:28, 21 September 2012 (BST)
- I don't get what you are trying to say. Are "5" and "8" independent housenumbers, or is one of them just a staircase number or something? If they are independent housenumbers, why would we want to merge them in one value? What do you mean by "pure addresses"? What has all of this to do with spellings? 5 and 8 are different numbers, not just different spellings of the same number. --Fkv 11:02, 26 October 2012 (BST)
I prefer by far the solution of using separate nodes attached on the building way, or even better, on the house entrance. Have a look in Paris, France or Strasbourg, France to see that major cities are using this scheme without problems. --Pieren 21:29, 21 September 2012 (BST)
- I am happy for the people in Paris and Strasbourg if they have exactly one entrance per housenumber and vice versa, and no conscription numbers. Unfortunately, things are not that easy in the rest of the world... --Fkv 11:02, 26 October 2012 (BST)
- If it's not by entrance, then it can be by post box. Any way, the "one node:one address" model is much simpler to map and tag for contributors. Your model is easier for data consumers but we shall always promote the easiest way for mappers, not for software. --Pieren 10:09, 4 December 2012 (UTC)
- So you think that maintaining a myriad of nodes is easier than tagging the address on the building? It's fewer objects and fewer tags with the new approach - see [example] --Fkv 16:49, 4 December 2012 (UTC)
- I think that one node per address is much easier to undertand, read, interpret, compute, etc than your miriad of tags on a single OSM element. I don't want to be cruel but your proposal has been used by 2 users (one being yourself) on 11 ways for "addr:1:street" in 7 months... --Pieren (talk) 17:49, 20 March 2013 (UTC)
- In view of the lack of editor support and propaganda, it's no surprise that this tagging scheme has hardly been used so far. If it were already in use, we wouldn't need a proposal in the first place. Features that are in use may be documented in map features etc right away. And looking at Dkiselev's taginfo link below, we see that addr2:* (which is just a different syntax for the same goal) is used 6488 times by now. That indicates an actual demand for multiple address tagging. --Fkv (talk) 21:39, 18 May 2014 (UTC)
- I think that one node per address is much easier to undertand, read, interpret, compute, etc than your miriad of tags on a single OSM element. I don't want to be cruel but your proposal has been used by 2 users (one being yourself) on 11 ways for "addr:1:street" in 7 months... --Pieren (talk) 17:49, 20 March 2013 (UTC)
- So you think that maintaining a myriad of nodes is easier than tagging the address on the building? It's fewer objects and fewer tags with the new approach - see [example] --Fkv 16:49, 4 December 2012 (UTC)
- If it's not by entrance, then it can be by post box. Any way, the "one node:one address" model is much simpler to map and tag for contributors. Your model is easier for data consumers but we shall always promote the easiest way for mappers, not for software. --Pieren 10:09, 4 December 2012 (UTC)
We already use simmilar scheme in Russia. http://taginfo.openstreetmap.org/keys/addr2%3Ahousenumber except we use addr[2,3,4,5..]: instead of addr:[2,3,4,5..]: http://wiki.openstreetmap.org/wiki/AddrN Dkiselev (talk) 11:30, 2 March 2014 (UTC)
- This seems to be essentially the same as the Proposed_features/addr2 proposal. The drawback of that syntax is that it does not support default values. If there's an address with addr:country/state/city/postcode etc. and the alternate address only differs in addr:street and addr:housenumber, then you need to copy all of the other addr:* tags to addr2:*. This may become unhandy and prone to copy&paste errors, but on the other hand, that scheme's simplicity makes it more comprehensive than the default values logic. --Fkv (talk) 21:39, 18 May 2014 (UTC)