User:Kmpoppe/RANC Rewrite

From OpenStreetMap Wiki
Jump to navigation Jump to search

Relations have been invented to create a grouping of objects that share a geographical connection and a common theme. They are not intended to be used to categorize objects, that have no geographical connection to each other and where this connection can be sufficiently described by using a single value in a tag.

Differences between OSM and a Wiki

In Wikis, pages without a category are the exception and are "cleaned up" rather quickly by other contributors. In OpenStreetMap, objects being part of a Relation is the exception, and they do not need to be.

Most Wikis (regardless of the software they are running on) must use categories to create a tree-like view of the relation of pages to each other because there is no other way of knowing. Therefore it is common to have a wiki page carry the information what categories it belongs to and use this as a means to traverse through all information on the same topic.

OpenStreetMap on the other hand is a spatial database; this means that it has intrinsic knowledge about the location of objects. Nowadays (2024, when rewriting this page), the global use of boundary=*-polygons even allows to accurately describe the boundaries that surround an object without putting these information onto each and every object (historically, is_in=* has been used for that purpose).

Why is this important ?

As stated above, Relations in OpenStreetMap carry more information than what members they have, but also their role and the order of these members. This is especially useful (and needed) when describing a public transport route where a stop position is followed by the streets/tracks a vehicle uses towards the next stop position.

If, at any point in time, the order of these objects changes (or members are added or removed), a new version of the relation is saved to the database to preserve the history. Adding and removing members can also happen unintentionally, i.e. if a street needs to be split into two different ways because one part has become speed-limited while the other part hasn't.

While this behaviour is welcomed and needed to retain the meaning of a Relation when the order of its members is important, it is far less helpful (but also not avoidable due to the design of Relations) when the members do not share a geospatial connection but only a logical one.

Known problems

While using a relation for a public transport route is hardly debatable (the route operator insists that drivers use a specific set of streets/tracks to reach the stop positions in the correct order as the timetable says - temporary diversions notwithstanding), a purely logical connection between objects always carries the risk of being incomplete.

One contributor can have a completly different opinion on what objects should be part of such a Relation than another contributor, inevitably leading to a disagreement (or worse) between two or more parties.

Additionally, incomplete information may also be the result of a contributor simply not knowing about the existence of any Relation that would be deemed suitable for the objects they were editing.

What to do instead ?

Most logical groupings of objects can be achieved by using the correct tags for every object. When looking for all ATMs (cash-machines) that are operated by HSBC, asking the database to find all Nodes that are tagged with amenity=atm+operator=HSBC in relation Great Britain makes for a quick and easy Overpass Query.

Always remember that data consumers (Apps on your phone, websites) are capable of doing these requests in the background (i.e. before even displaying anything) dynamically - keeping with the ATM example, dynamically changing which operator to show - without the need of a Relation keeping all those objects together and without the user/visitor of a website needing to do these queries.

A good example for a valid and useful grouping is the "route" relation, where multiple ways are connected to form a cycle route or a walking route or something else; a way may be part of any number of routes so this cannot be solved by tagging the way with "route=xxx".