Proposal:AssociatedAddress (new)
Jump to navigation
Jump to search
| associated_address | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | LLlypuk82 |
| Tagging: | type=associated_address (member roles: address, object) |
| Applies to: | 
|
| Definition: | Flexible and simple way to add an address information in non typical cases (and, by the way, typical too) |
| Statistics: |
|
| Rendered as: | none |
| Draft started: | 2016-03-02 |
| RFC start: | 2016-03-03 |
| Vote start: | 2016-04-08 |
| Vote end: | 2016-04-22 |
Usage
Atypical and other complex cases
1. Two or more different addr:housenumber and addr:street tags referring to one object (i.e. building polygon or especially node-POI) It happens when building is located on the street intersection. For example it can be a shopping mall or just a house.
2. Multiple buildings and POI-nodes with the same addr:* tags. In this case we have to assign redundant address tags to every object or to include all objects within a single bounding envelope of building with an address (all objects like POIs will inherit their address from bounding building polygon during data conversion, which requires spatial queries).
Solution
I propose to create a relation type=associated_address with following members and roles:
- polygons (multipolygons) or/and POI-nodes (role=object)
- address nodes (with addr:* tags) (role=address)
Further profit
- it is not necessary to process geometry to locate proper object center for correct address label rendering (especially in cases with non-trivial geometry)
- it can be used for easy (without geometry processing) creation of interactive points which allow pop-up windows with full address information
- so we have in fact a table with list of POIs and associated address/addresses.
Practical examples
Note: there can be any number of members (role=address or role=object)
Editors
- Editors could provide a function, where the user selects the address object as also all relevant POI objects and then clicks a button to automatically create a relation with all the selected elements in it (like plugin Relation Toolbox do it for associatedStreet in JOSM)
How to
See also
Please comment on the discussion page.
Voting
Voting closed
Voting on this proposal has been closed.
It was rejected with 4 votes for, 11 votes against and 1 abstention.
I approve this proposal. --LLlypuk82 (talk) 13:43, 8 April 2016 (UTC)
I oppose this proposal. --J-wills (talk) 14:07, 8 April 2016 (UTC)- I approve this proposal. But only as addition to current system --Keder (talk) 14:12, 8 April 2016 (UTC)
- I oppose this proposal. The proposal is too vague; I don't know what I'm voting for. The idea behind it seems solid though, so with a bit of polish, this could be something I would accept. --Kelerei (talk) 14:30, 8 April 2016 (UTC)
- I oppose this proposal. We have GEOdatebase WTF (without geometry processing) --FreeExec (talk) 17:48, 8 April 2016 (UTC)
- I approve this proposal. Added some cases I know, and couldn't yet find anything that couldn't be modelled, and I find it better than various addrN-schemes, when it brings added value in addition to the multiple addr:-nodes inside the geometry. Alv (talk) 19:09, 8 April 2016 (UTC)
- I oppose this proposal. reason --Waldhans (talk) 21:55, 8 April 2016 (UTC)
- I oppose this proposal. With examples one house can have different addresses, address not equals to house. However two addresses for same house can be calculated with house geometry if this geometry exists. Same addresses grouping can be applied by geometry for mall. --Tbicr (talk) 06:15, 9 April 2016 (UTC)
- I oppose this proposal. The atypical and compex cases you describe have already been solved by other means. For equivalent addresses on one building, use addrN (for which there are already 3 proposals: one two three). For multiple POIs within a building, set the address tags on the building. For multiple buildings, set the address tags on the parcel or use a multipolygon, site or cluster relation. In general, we should try to avoid relations wherever we don't need them, because long relation lists in the editor make OSM increasingly unmaintainable. I agree with FreeExec that it's not our task to care about data processing. That's the task of applications. And geometry processing is easy anyway. --Fkv (talk) 06:23, 9 April 2016 (UTC)
- I oppose this proposal. I can see no use for that. In the first example, the relation adds no information. In the second, the relation will never be maintained. --JB (talk) 21:32, 9 April 2016 (UTC)
- I approve this proposal. The proposal is useful. But I don't like the relation's name. --Surly (talk) 04:26, 11 April 2016 (UTC)
I have comments but abstain from voting on this proposal. This looks like a better alternative to addrN, but this proposal is sparse on details. With more details and examples of when and when not to use this relation it would most likely be something I'd vote yes for. Perhaps voting was opened too early. --Peter Mead (talk) 08:35, 11 April 2016 (UTC)- I oppose this proposal. there was nearly none discussion on tagging list or in wiki --Hakuch (talk) 11:01, 12 April 2016 (UTC)
- I oppose this proposal. the scheme do not solve any unsolved yet problem of current object tagging Smollett (talk) 10:27, 14 April 2016 (UTC)
- I oppose this proposal. As mentioned above by JB the relation will never be maintained --Wowik (talk) 20:07, 16 April 2016 (UTC)
- I oppose this proposal.I think is better to write the street to the node/way than using relations for this --Sven Anders (talk) 15:39, 18 April 2016 (UTC)
