Replies: 1 comment 3 replies
-
|
I strongly advise against adding amenity data to address nodes. The main reason being, it will be easy to lose this address when the amenity is closed or moved. There is an issue open just about that. Conserving address data is more important. OSM database is not normalized, there are no duplicates between different object types. E.g. see names on road segments. |
Beta Was this translation helpful? Give feedback.
-
You advise against this, but it makes this app unusable within some communities. Which is too bad. The rationale for a single address node can be debated. I don't understand why the app cannot be adapted to a convention instead of the reverse. |
Beta Was this translation helpful? Give feedback.
-
|
If you invoke a community instead of a single person, please reference the wiki page or another written document that codifies this mapping practice. |
Beta Was this translation helpful? Give feedback.
-
For example when editing Netherlands addresses, local editors will have to do extra work; their mapping convention is to tag the address node, duplicating the address node if there are more separate amenities on that address. You can read this on their wiki (have to translate): https://wiki.openstreetmap.org/wiki/Welkom_op_OSM and on their forums: https://community.openstreetmap.org/t/waar-poi-informatie-plaatsen-op-poi-node-bag-node-of-het-gebouw/76969 you practically make the app unattractive to users in that community as they will at least advise against using it, because it adds cleaning up. |
Beta Was this translation helpful? Give feedback.
-
How can an existing address node be updated to add an amenity instead of having the app create (duplicate) a new node derived from an existing address?
Some territories by comvention need this behavior of adding amenities to existing address nodes.
Beta Was this translation helpful? Give feedback.
All reactions