A route is a customary or regular line of passage or travel, often predetermined and publicized. Routes consist of paths taken repeatedly by people and vehicles: a ship on the North Atlantic route, a car on a numbered road, a bus on its route or a cyclist on a national route.

A route (or variant) may belong to a route master relation. A route master contains all the directions, variant routes and information for that route. It permits OSM to distinguish the two routes of a two-way trip.

Note that a road sometimes has more than one number. Numerous major European "E" routes share ways (sometimes exactly the same ways) with national numbered routes.

The route is operated by this authority, company, etc; e.g., Stagecoach Cambridge, Eurostar.

state

? Optional

proposed / alternate / temporary / connection

Sometimes routes may not be permanent (i.e., diversions), or may be in a proposed state (e.g., UK NCN routes are sometimes not official routes pending some negotiation or development). Connection is used for routes linking two different routes or linking a route with for example a village centre.

Whether or not the route start and ends at the same place; i.e., after traversing the route once, one is has returned to the start.

Members

Way/node

Role

Recurrence

Discussion

<empty>/route

!1+

The ways making up the route.

forward/backward

If a route should be followed in only one direction for some or all of its length, the role can indicate this for some or all of the constituent ways. forward means the route follows this way only in the direction of the way, and backward means the route runs only against the direction of the way. Rendered on the cycle map (example).

north/south/east/west

In North America, numbered route signs include a posted travel direction (north, south, east, west) that should be conveyed in the route's relation.

A bus stop or train halt, on the route. The order of the members in the relation should be identical to the order in the timetable. The number is not needed to preserve the order of stops. It is only a guide to help mappers finding missing or misplaced stops. You can use stop instead, if you like.

stop

?0+

A bus stop or train halt/station, on the route. The order of the members in the relation should be identical to the order in the timetable.

forward:stop:<number>, backward:stop:<number>

?0+

A bus stop or train halt, on the route, which is to be used only in one direction. The direction is related to the direction of the way. It has nothing to do with toward or away from any bus station or terminus. The order of the members in the relation should be identical to the order in the timetable. The number is not needed to preserve the order of stops. It is only a guide to help mappers finding missing or misplaced stops. You can use forward:stop or backward:stop instead if you like.

forward:stop, backward:stop

?0+

A bus stop or train halt on the route that is used only in one direction. The direction is related to the direction of the way. It has nothing to do with toward or away from any bus station or terminus. The order of the members in the relation should be identical to the order in the timetable.

platform:<number>

?0+

A bus or train platform belonging to the route. The order of the members in the relation should be identical to the order of the stops in the timetable. The number is not needed to preserve the order of platforms. It is only a guide to help mappers finding missing or misplaced platforms. You can use platform instead if you like.

platform

?0+

A bus or train platform belonging to the route. The order of the members in the relation should be identical to the order of the stops in the timetable.

Railway routes (light rail, metro, mainline, monorail, etc.)

Main article:Railway
Railway routes can be used to describe both a particular part of the infrastructure that is known by a distinct name (for example East Coast Main Line) or a railway service that is identified to the public with a particular identifier or name (such as the Orient Express). Discussion on tagging for different purposes is taking place on talk transit (Aug09).

If the trains on the route are equipped with ramps or elevators for wheelchairs. Note that, even if the trains are equipped, not all stations on the route may be suitable, or not all platforms may be accessible.

Historic routes, such as horse-pack trails used for postal routes, ancient roads, etc. Often parts are lost. Please include an appropriate historic=*-value.

Please add here

How to map

Multiple routes sharing the same ways

Especially with bicycle routes, often multiple routes run along the same ways for a far distance. There exist so many different bicycle route networks that are operated by different entities that it is not unusual that some of these networks overlap. The EuroVelo routes, for example, use the existing infrastructure in many countries. There are two practices at the moment, if segments of multiple routes share the same way.

Add the ways to all relations of the routes that they belong to.

Split the routes into part relations and make super relations (relations that don’t contain ways but instead other relations). Then add the segment that is shared by the routes to all of them.

Both practices each have advantages and disadvantages.

Adding the ways to multiple route relations

When many routes share one path, it can be a lot of work to map a new part of the route, because you have to add the ways to all relations.

People might not see that the path also is used by other routes and might forget to apply their changes to all relations. Thus the data may become inconsistent.

This is probably the easier way, as it is somewhat hard for beginners to split relations into parts and to find out which part they have to edit.

Relations might become very big, which makes it hard to work with them (analyzers need more time to process them, drawing them into the map will take a lot of JavaScript CPU time).

If you don’t use super relations at all, you also have to add alternative routes and excursions to your relation. This makes it hard for analyzers and tools to understand the route. Role=excursion and role=alternative have been suggested, but they still don’t say which way belongs to which excursion (if there are multiple ones).

It is the purpose of relations to group objects. When two primary roads share the same street at some section, we don’t create two ways that share the same nodes. So we shouldn’t create two relations that share the same ways.

Creating super-relations for routes

Current renderers (like the CycleMap) don’t support super-relations, so they don’t show the ref and the network tag of a super-relation. Currently, all these tags have to be added to all part relations, which is a lot of work (especially as the parts need to have the different refs of all the routes they belong to).

It is said to be good mapping practice to keep relations one way. So alternative routes and excursions need to be put into a different relation. So you often need a super-relation even without splitting the route into parts.

Tools and analyzers (like the OSM Relation Analyzer, especially the GPX export function) don’t support super-relations yet. This makes it hard to analyze a route as a whole (which is important, for example, to calculate how much of a route already has been mapped). (Note: OSM Route Manager supports subrelations)

There is no documented convention on how to handle super-relations. On first glance it appears simple--just take over all tags to all members--but it is not. There are tags where this makes no sense or which change the context and meaning when handed over to a member relation; e.g., distance or note. The same applies to roles other than in base relation, e.g. forward/backward.

Super-relations can become very confusing when a relation belongs to multiple super-relations or a way belongs to multiple relations. In that case it is no longer deterministic from which relation a certain relation or way will receive its tags.

When someone maps a new route, they might have to split other routes that share ways with it. People editing these other routes might get confused when the number of subrelations keeps changing the whole time.

Current editors miss advanced relation editing features, such as “Split relation” (and also super-relation rendering). Things can get very confusing when one route consists of hundreds of small part relations.

One motto of OSM is "Don't map for the renderers". If it is considered the more natural way of mapping to create super-relations, then the missing support in the renderers and tools should not stop us from doing so.

Consider that super-relations are not necessarily included when requesting a set of data from the server. So depending on whether or not super-relations were included, the data is interpreted differently. As you cannot tell from a way or relation whether it is member of another relation, you never are quite sure whether you are seeing all the relevant data.

It is common sense to create super-relations if one complete route is part of another route (like the German D6 is with EuroVelo EV6). If EV6 now shares only a part of another way in another country, we will have to create segments anyway (else we end up with a relation that contains both sub-relations and ways). We should either use the one method or the other.

People need to know only the route that they are mapping. When someone maps the German D6 route, he doesn’t even need to know the EuroVelo network (as EV signs might not exist in his area), because, as with a super-relation, his part of the route gets added automatically to all parent relations. This fits the OSM concept better: When everyone maps the places and things he knows, a complete map of the world evolves.

At the moment it seems to be practice to create part-relations, if the shared segment is relatively big compared to the total length of a route. For a national bicycle route, 20 km might be a good limit. For shorter parts the single ways might be added to all relations they belong to. (Of course this is only a rule of thumb. Nothing of this is the official way of mapping.) It also might be important how many different way objects a segment consists of in OSM. It might be not very useful to create segments, if the route consists of motorways (as they only contain of a few, long ways), while bicycle routes often go through cities and residential areas where many ways would have to be added if there were multiple relations.

Another point when deciding which tagging method to use is to find out if the routes use the same ways only by coincidence. Thus, if one route is changed, the other route likely still will be using the old way, so using part-relations would not be appropriate.

Size

Common practice is not to create route relations with more than 250–300 members. If you need to create bigger relations, which could happen easily, make several reasonable-sized relations and unite them in a super-relation as mentioned above.
Reasons:

Keep the relations editable.

Avoid conflicts. The bigger the relation the more likely it is that two users are working on it at the same time.

Bus routes and roundabouts

Bus routes passing through roundabouts are mapped in one of these two ways:

The whole roundabout is included in the route relation.

The roundabout is split and the part used by the bus route is included in the route relation.

There is no consensus among the OSM community regarding which method is recommended. The choice of method 1 or 2 has no effect on Garmin devices because split roundabouts are re-joined by mkgmap. It is also possible to re-join split roundabouts in Mapnik although this is not done for the rendering of the main map. Software developers should note that if the precise route is required and method 1 has been used, the details will need to be deduced from the positions of the entry to, and the exit from the roundabout; and also from the position of a stop, if the bus serves a stop on the roundabout. (In some cases a bus may make more than one full circuit of a roundabout.)

Step by step guide

How to create a new route (it is slightly different if you want to add ways to an existing route).

Potlatch

Ensure all ways that the route runs along exist and are appropriately tagged (e.g., highway=footway)

Select the first way and click on the second symbol on the right side, which looks like two chain segments.

Select a relation from the drop-down menu, if there is an existing relation in this area that is appropriate. If the existing relation you want to choose is far away, use the search function. Otherwise, select Create a new relation and click Add.

Add a type tag with the value route.

Add additional tags as needed. (Use the + button)

Click OK.

The relation has been added to the way. The grey box to the right of the relation details and to the left of the X is the input field for the way's role within the relation. See the Members section above for details of roles within the route relation type.

Repeat steps 2–4, selecting the appropriate relation (the one just created) in step 3.

JOSM

Ensure all ways along which the route runs exist and are appropriately tagged (e.g., highway=footway)

Make sure the relation pane (Alt+Shift+R) is open

Select New in the relation pane to create a new relation

Fill in the appropriate tags in the dialog that pops up, adding at least type=route and preferrably name as well with a name for the route

Click OK

Now select some or all of the ways you would like to add to the relation using the normal select (S) tool, then click Edit in the relation pane with your relation highlighted. The relation editing dialog will pop up

Click Add selection in the relation dialog to add the selected ways to the relation.

Navigation on relation:route

Please list applications here that are able to navigate on an existing relation:route.