Proposal:Relation:feature

POI/place/site
Proposal status:	Draft (under way)
Proposed by:	Lectrician1
Tagging:	type=feature
Applies to:	Relations
Definition:	Establish specific ids for POIs in OSM
Statistics:
Draft started:	2020-12-23

Proposal

Create a relation with tag type=feature when mapping an Area or Way where there is already a Node or vice-versa with the node at the center of the feature.

OSM has a flawed system that causes 2 related problems:

• Conceptual ideas reference physical objects
• Lack of permanent IDs for identifiable features.

Solution:

• 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.

Problem/Solution Examples

Here is a typical tagging progression:

1. A building has a name=John's Office tag on the node that represents the building.
2. 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.

Solution:

1. 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.
2. 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

Tagging

• 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".

  <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>
  

  Note that the cycleway way has no tags like name=* but the Relation does(what this proposal does).

Pros

• Less repetitive tags being stored in elements (all shifted to relations)
• Permanent IDs
• Better relational indexing

Cons

• 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...)

Features affected

• Streets (Relation:street)
• Buildings

Features not affected

Yay!

• Boundaries (their member ways don't need tags and they are concepts themselves to begin with!)

Tags affected

These tags should be used only on relations:

• name=*
• operator=*
• opening_hours=*
• government=*
• wikidata=*
• addr=*
• ...

OSM Wiki Standards affected

• One feature, one OSM element
• Relation
• Relations/Relations are not Categories
• Elements

Editor Implementation

Editors will have to change their presets and validators to add conceptual tags to relations and keep them out of objects.

Implementation timeline

1. Editor Implementation
2. Copy conceptual tags from current physical elements to relations (automated).
3. Break period of 1 year for data consumers to account for
4. Editors automatically delete conceptual tags on physical elements that are manually edited.

Comments

Please comment on the discussion page.