|Status:||Draft (under way)|
|Definition:||Establish specific ids for POIs in OSM|
OSM has a flawed system that causes 2 related problems:
- Conceptual ideas reference physical objects
- Lack of permanent IDs for identifiable features.
- Create a Relation for every POI, place, or site whose existence and ID acts as its permanent identification.
- Conceptual tags can only be used on these relations
- Relations hold point and area members of a place (repeals One feature, one OSM element)
This clearly will change the purpose of relations and create 2 types of tag: virtual and physical.
Here is a typical tagging progression:
- A building has a name=John's Office tag on the node that represents the building.
- Another mapper comes around and deletes the node, creating a way as the building outline and adding the tags building=office and name=John's Office.
Here's the problem:
The node that represented the office was deleted. If a data consumer wanted to reference the office in a database, making sure it would remain there, even if the tags might be changed, they would reference the Node ID. Unfortunately, the node was deleted, and a new way with a different ID was created.
- When the original node was created, a Relation should be created along with it. The Relation should store the tag name=John's Office. It's okay if the node does not have any tags. Nodes are only concepts that don't have any 2 or 3 dimensional properties. They will always represent an area or volume other than themselves.
- Then, when the other mapper comes around, they can delete the Node, map the building outline, and add the building outline to the relation. The building will have the tag: building=yes The Relation will have the tags: office=yes and name=John's Office
- Every node, way, or area should only have the physical tagging referencing the 1 feature it represents. All other conceptual tags should be stored in a relation.
- A relation for a area such as building should also have a node that defines it's "center". This can help data consumers render maps of locations of POIs without having to render the entire building or calculate its center.
- The highest level tagged definition of a physical OSM element used in a relation should be its role in the Relation it is a part of. For example, a cycleway crossing Way that is part of a cycleway Relation called "Blue Route" should have the role "crossing".Note that the cycleway way has no tags like name=* but the Relation does(what this proposal does).
<way> <tag k="highway" v="cycleway"/> <tag k="cycleway" v="crossing"/> <nd ref="1"/> <nd ref="2"/> </way> <relation> <tag k="name" v="Blue Route"/> ... <member type="way" ref="234" role="crossing"/> ... </relation>
- Less repetitive tags being stored in elements (all shifted to relations)
- Permanent IDs
- Better relational indexing
- If a physical element's relation is needed to access it's conceptual tags, the API has to index for relations that have it as a member. This requires more processing overhead (I think this is the case? However, I don't know how RMDBSs work entirely so...)
- Streets (Relation:street)
Features not affected
- Boundaries (their member ways don't need tags and they are concepts themselves to begin with!)
These tags should be used only on relations:
OSM Wiki Standards affected
Editors will have to change their presets and validators to add conceptual tags to relations and keep them out of objects.
- Editor Implementation
- Copy conceptual tags from current physical elements to relations (automated).
- Break period of 1 year for data consumers to account for
- Editors automatically delete conceptual tags on physical elements that are manually edited.
Please comment on the discussion page.