Talk:Proposed Features/addrN

From OpenStreetMap Wiki
Jump to: navigation, search

(Early vote moved here from proposal page. --Fkv (talk) 11:50, 15 January 2015 (UTC))

  • I oppose this proposal I oppose this proposal. There are better solutions already used in such places, like placing multiple address nodes within the building, and they are already supported by software because they don't introduce any new tags. The example with a conscription number doesn't need addr2: either as conscription numbers are also already supported by Nominatim, for example. Andrew Shadura 11:19, 15 January 2015 (UTC)
The first paragraph of the proposal explains why address nodes won't always work: They cannot be associated with shop nodes etc.
Conscription numbers may be already supported by Nominatim, but this proposal is NOT about conscription numbers, it's about combining multiple addresses one of which may be a conscription number. The given example cannot be tagged with addr:city=Kaltenleutgeben + addr:street=Wilhelms-Straße + addr:housenumber=4 + addr:conscriptionnumber=263, because the address containing the conscription number must not include a street. If you send a letter to an address containing street and conscription number, it will certainly be returned as undeliverable.
--Fkv (talk) 11:50, 15 January 2015 (UTC)
This argument isn't valid, as they already work with shops etc. An address node inside a building can be extrapolated to the whole building, and addresses of shops can be derived from it; as far as I know Nominatim does precisely this thing. --Andrew Shadura 16:22, 15 January 2015 (UTC)
Extrapolating and then deriving is much more complex than taking the attributes from the feature directly. Ironically, the more complex approach is less precise. It's a "best guess" approach. An address node has no defined scope. It may be valid for the whole building, or for part of the building. Applications can just look up nearby nodes and guess that they may belong together. That's what Nominatim does with place nodes. Maybe it does the same for address nodes. That does not mean that this is a satisfying approach. It's just a hack to cope with poor data. --Fkv (talk) 20:50, 15 January 2015 (UTC)
Also, it's not true what you're saying regarding the conscription number. It is possible to use both street and conscription number in an address, this actually works. --Andrew Shadura 16:24, 15 January 2015 (UTC)
Maybe it works in your country. I can tell you that it does not work in my country. I worked at a postal office for some months. --Fkv (talk) 20:50, 15 January 2015 (UTC)

I think there needs to be some support for multiple addresses, particularly in the common scenario of a business preferring a PO Box for mail (or, in my use case, veterinary mail related to disease testing), and that of houses turned into apartments. Valerietheblonde (talk) 18:44, 28 June 2016 (UTC)

is there real difference between this and previous proposal?

Old proposal located here AddrN. Xxzme (talk) 14:11, 15 January 2015 (UTC)

No real difference in content. The difference is that the 2 old proposals are just drafts, and nobody cared to finish them, and nobody replied to my comments on the talk pages. I don't want to take over half-done work of someone who does not respond. That's why I started a new proposal. --Fkv (talk) 20:20, 15 January 2015 (UTC)
okay, just don't forget to set |=status to abandoned/obsolete/... in old proposals, otherwise it will be confusing. Xxzme (talk) 20:53, 15 January 2015 (UTC)
I don't know if that's necessary. If you believe it is, why don't you do it? --Fkv (talk) 21:48, 15 January 2015 (UTC)
We should, if nobody cares to update them Proposal#Abandoned.2C_Canceled.2C_Obsoleted.2C_Undefined. I didn't because I don't know if Proposed_Features/addrN will be accepted or rejected. So we have to set different status (Abandoned vs Obsoleted) based on new proposal results. Xxzme (talk) 21:53, 15 January 2015 (UTC)