Relation

Relations are structured collections of objects – nodes, ways and other relations. Along with nodes and ways, they are one of the three core data elements of the OpenStreetMap data model.

A relation element must have at least the type=* tag, 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 forming a bus route). A member of a relation can optionally have a role, describing the function that it plays within a relation. Tags describing the collection as a whole should go only on the relation (e.g. wikidata=*, destination=*, ...), except for the name, if any, which should go in the relation members, too.

As of March 2024, OpenStreetMap contains over 12 million relations.

On tag description pages, multipolygons are treated as areas rather than relations , since the same tags apply to both closed ways and multipolygons. See FAQ.

Usage

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'. See Relations are not categories.

The most common, simple relations contain only members of geometric types (nodes or ways). Relations may also contain other (child) relations, in which case they are informally called "super-relations". It is not usual for a relation to contain both geometric members and child relations, but it is not forbidden.

To be useful, a relation tree should eventually contain geometric members; otherwise, it would be basically invisible, because it is not attached to anything concrete on the map. An empty relation is permitted to exist in the database, but it is not very useful, except maybe as a placeholder for a future expansion. iD editor automatically deletes empty relations obtained by removing members, since they are in most cases inadvertent.

Size

There is a technical limit of 32,000 elements in a relation. It is recommended not to use more than about 300 members per relation: 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. 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).

However, having large relations is sometimes inevitable. For example, boundary relation for Russia, the largest country in the world, has over 4500 ways as outer members.

Roles

A role is an optional textual field describing the function of a member in the relation.

For example, in a multipolygon relation, outer and inner are used to specify whether a way forms an outer or an inner part of that multipolygon.

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.

Examples of relation

Multipolygon

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.

In the multipolygon relation, the outer and inner roles are used to specify whether a member way forms an outer or an inner part of that area.

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

Bus route

Each variation of a bus route itinerary is represented by a relation with type=route, route=bus and some recommended tags like name=*, ref=*, from=*, to=* and operator=*.

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.

Other examples

• 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

Tools

• iD: [1]
• JOSM/Advanced_editing#Relations: to work with relations in JOSM
• Potlatch 2/relations: to work with relations in Potlatch
• Relatify: simple edition of bus and tram routes (in Public Transport v2 (PTv2) standard)
• 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
• Public Transport Network Analysis - for checking gaps, order of ways, one-way rules and inconsistent data between route and master in Public Transport v2 relations (also basic support for PTv1 routes).

Navigation on relations

OSRM and Valhalla can use certain route relation roles to influence guidance instructions when a route represents both directions of travel.

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.

OSM XML

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>

See also

• Relations are not categories
• Empty relations
• Video Examples