A relation is an element with at least the tag type=* and a group of members which is an ordered list of one or more nodes, ways and/or relations. It is used to define logical or geographic relationships between these different objects (for example a lake and its island, or several roads for a bus route). A member of a relation can optionally have a role which describes the part that a particular feature plays within a relation.
Important : a relation has to have members with geometry elements (at least one node or one way) or, if not, to have a relation as a member with this same rule or, if not, to be a child of another relation with this same rule: this is mandatory. In another way of speaking, if you consider a relation with all its direct children (its children, the children of these children, the children of the children of these children and so on) and all its direct parents (the parents, the parents of these parents and so on), at least one of these objects has to have geometry elements. If not (meaning that there are only relations of relations), all these relation(s) will be invisible because they are not attached to anything concrete on the map.
For example, if you are using ID, if you have a relation A with one member = a relation B with one member = a node, if you delete the node, there will be no more geometry element in these objects and, to prevent bad data (relations ultimately empty of geometric elements) from entering OSM, ID will automatically delete the 2 relations A and B.
Relations are used to model logical (and usually local) or geographic relationships between objects.
They are not designed to hold loosely associated but widely spread items. It would be inappropriate, for instance, to use a relation to group 'all footpaths of England'.
It is recommended not to use more than about 300 members per relation. Reason: the more members are stuffed into a single relation, the harder it is to handle, the easier it breaks, the easier conflicts can show up and the more resources it consumes on the database and server. There is a technical limit of 32,000 elements in a relation.
If you have to handle more than that amount, some recommend creating several relations and combining them in a Super-Relation (a good concept on paper but software support is poor).
A role is an optional textual field describing the function of a member in the relation.
For a waterway relation of a river (a relation with all the waterway=river of the river and optionally of its tributaries), main_stream on a way will indicate that this is the main part of the river while side_stream is for a branch which will come back in the main stream.
Multipolygons are one of two methods to represent areas in OpenStreetMap. While most areas are represented as a single closed way, almost all area features can also be mapped using multipolygon relations. This is needed when the area needs to exclude inner rings (holes), has multiple outer areas (exclaves), or uses more than ~2000 nodes.
For example, for a lake with an island, you will map this as a multipolygon with 2 ways, one way (with no tags) with the role "outer" for the outer border of the lake and one way with the role "inner" for the island (which could have some tags like natural=bare_rock if the island is a rocky area).
The first members in the route relation are the nodes representing the stops with the role 'stop'. These are ordered in the way the vehicles travel along them. Then the ways are added and will form an ordered sequence along the stop nodes. The ways don't get roles.
- Relation:boundary to define different kind of boundaries (administrative, protected areas, etc.)
- Relation:restriction to describe a restriction such as 'no left turn', 'no U-turn' etc.
- see Types of relation and Category:Relations for more
- iD: 
- JOSM/Advanced_editing#Relations: to work with relations in JOSM
- Potlatch 2/relations: to work with relations in Potlatch
- Show a relation: Example id=11
- Show history of a relation: Example id=11
- Rendering a relation: Example id=11
- Relation Analyzer (ra.osmsurround.org) - to analyse a relation (e.g. show gaps in route relations) or to look for a relation by name, type, operator...
- Mapki's Deep Diff - to analyse: e.g. show role changes individual members, show modifications of the memberlist via object history view for each object version
- Relation Diff - to compare relations
- Create a gpx file from a relation - for example to visualise the relation on a map
- Rel2gpx - to filter ways of a relation
- OSM Inspector (Geofabrik) - PTv2 route relations errors on ways - for checking gaps and member list disorder of PTv2 relations
For example, some bicycle routers prefer to route on roads with existing bicycle route (as indicator of cycling usability). An application may also follow a pilgrimage=* route relation or, more generally, try to route along the minimum number of numbered road routes.
- Main article: OSM XML
<relation id="13092746" visible="true" version="7" changeset="118825758" timestamp="2022-03-23T15:05:48Z" user="" uid=""> <member type="node" ref="5690770815" role="stop"/> <member type="node" ref="5751940550" role="stop"/> ... <member type="node" ref="1764649495" role="stop"/> <member type="way" ref="96562914" role=""/> ... <member type="way" ref="928474550" role=""/> <tag k="from" v="Encre"/> <tag k="name" v="9-Montagnes de Guyane"/> <tag k="network" v="Agglo'bus"/> <tag k="not:network:wikidata" v="Q3537943"/> <tag k="operator" v="CACL"/> <tag k="ref" v="9"/> <tag k="route" v="bus"/> <tag k="source" v="https://www.cacl-guyane.fr/wp-content/uploads/2021/01/PLAN-RESEAU-URBAIN-AGGLO-BUS-1.pdf"/> <tag k="to" v="Lycée Balata"/> <tag k="type" v="route"/> <tag k="website" v="https://www.cacl-guyane.fr/lagglo-au-quotidien/se-deplacer/transport-urbain-2/"/> </relation>