A relation is a group of elements. To be more exact it is one of the core data elements that consists of one or more tags and also an ordered list of one or more nodes, ways and/or relations as members which is used to define logical or geographic relationships between other elements. A member of a relation can optionally have a role which describes the part that a particular feature plays within a relation.
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 in East Anglia'.
It is recommended to use not 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. 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 of the relation. For example, in North America, east indicates that a way would be posted as East on the directional plate of a route numbering shield. Or, multipolygon relation, inner and outer are used to specify whether a way forms the inner or outer part of that polygon.
- Main article: Types of relation
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 inner and outer roles are used to specify whether a member way forms the inner or outer part of that polygon enclosing an area. For example, an inner way could define an island in a lake (which is mapped as relation).
Each variation of a bus route itinerary is represented by a relation with type=route, route=bus and ref=* and operator=* tags. The first members in the route relation are the nodes representing the stops. These are ordered in the way the vehicles travel along them. Then the ways are added. In PT v2 the ways form an ordered sequence, along the stop nodes. The ways don't get roles. If they form a continuous sequence this is apparent from the continuous line along them (in JOSM's relation editor).
- Relation:boundary to exclusively define administrative boundaries
- Relation:restriction to describe a restrictions such as 'no left turn', 'no U-turn' etc.
- see Types of relation and Category:Relations for more
- JOSM/Advanced_editing#Relations: Work with relations in JOSM
- Potlatch 2/relations: 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 search for a relation by name, or to analyse: e.g. show gaps in route relations
- 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 Check
- Relation Diff
- Relation lists
- Visualise a relation on a map
- Geofabrik - OSM Inspector - PTv2 route relations errors (map area Tokyo) - 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.