Proposal:Hierarchies route=bicycle

From OpenStreetMap Wiki
Jump to navigation Jump to search
Hierarchies route=bicycle
Proposal status: Proposed (under way)
Proposed by: Axelos
Tagging: route=bicycle

Draft started: 2017-12-20
RFC start: 2018-12-30

The proposal is under discussion here : [ dead link ]


Bike routes are represented on OpenStreetMap as relations. There are many official routes that are already present in the base, and more will come. They can represent different types of itineraries: local, regional, national and even international.

That said, international routes are often based partly on national routes, which in turn are based on regional / local routes. Sometimes the regional ones are based on the locals. Clearly, with the system of flat relations, at least up to 4 itineraries can share the same physical path. In case of modification of this path (for example, a new 2-km cycleway along the road formerly used by the route), all the 4 relations have to be updated!

The concept of hierarchical relations makes it possible to avoid this edition nightmare, so that one single relation has to be modified, and this modification is automatically applied on the other 3 routes.

Paradoxically, this hierarchical process can complicate the management of bicycle routes when they are dense. Its use is therefore reserved mainly for itineraries covering long distances, several hundred kilometres.
It is still possible, and often even advised, to continue to create several parallel relations when routes meet over short distances, 10, 20 or even 30 km.

Look here for others explications.

How to? From Theory...

The concept of hierarchies is mainly based on the system of parent / child relations. In fact, this system is already partially used, in particular to split the long national and international cycle routes, into chunks in order to avoid 1000+ member relations ... For example the EuroVelo6 contains a child relation for each country crossed.

The concept of hierarchies therefore only increases the possibilities offered by the system of parent-child relations. To do this effectively, you will need a powerful editor: JOSM.

... to Pratice

We are going to take an existing case, where two national cycle routes intersect and partially share the same path, both operating on a regional route. The national routes are V50 and V52, and the regional route Boucle de la Moselle.

For clarity, we assume that the two cycle routes V50 and V52 do not share any other local or regional path to their respective destinations (Apach, Strasbourg, Lyon, Paris). In reality the V52 is also part of an international network ... but we omit this information to keep the case simple.

Hierarchies route bicycle.png

Thanks to the map, we see that:

  • Segment A is used by two routes: Boucle de la Moselle, and V50
  • Segment B is used by three routes: Boucle de la Moselle, V50, and V52
  • Segment C is used by two routes: Boucle de la Moselle, and V52

Segment names are indicative, they don't have to be named in relations.

We start with the relation representing the cycle route of the lowest level, in our case it is the Boucle de la Moselle. We will tackle cycle routes 50 and 52 later.

Relation La Boucle de la Moselle

The Boucle de la Moselle is therefore made up of 5 relations in total:

Each of them must use exclusively the tag network = rcn, the same ref = * and roundtrip = yes because it's a loop. No from = * and to = * because there is no point of departure or arrival (this differs depending on the case, some tourist loops have, example).

On the other hand the name can be different on each of these relations. Of course, we will use name = La Boucle de la Moselle on the parent relation, but it is possible to describe the child relations. Example name = Boucle de la Moselle: Toul - Pompey or name = Boucle de la Moselle: Pompey - Laneuveville.

Replace in the parent relation of the Boucle de la Moselle type=route by type=superroute

Now we are ready to make use of the hierarchies concept by integrating directly the children relations into the parent. The end user will see only the single parent relation (as if it was a flat relation) while the system will use the children to use the route properly.

Relation Véloroute 50

The V50 consists of 5 relations:

Expect the two relations reused from the Boucle de la Moselle, the remaining three must use exclusively the tags network = ncn, ref = V50, from = Apach and to = Lyon. As before, we will use an explicit name for the parent relation name = Véloroute 50, and preferably descriptive names for its two child relations: name = Véloroute 50: Apach - Pompey, name = Véloroute 50: Richardménil - Lyon.

Replace in the parent relation of the Véloroute 50 type=route by type=superroute

Note: Véloroute is the name for French long-distance cycling route.

That done, children relations using network = ncn in their parents will make the relations using network = rcn visible, both itineraries being displayed, including shared parts several times, but the relations remain independent.

Relation Véloroute 52

The principle is the same as for the V50, so it consists of 5 relations:

Except the two relations coming from the Boucle of the Moselle, the other three children must use exclusively the tags network = ncn, ref = V52, from = Paris and to = Strasbourg. As before, we will use an explicit name for the parent relation name = Véloroute 52, and preferably descriptive names for its two children relations: name = Véloroute 50 : Paris - Toul, name = Véloroute 50 : Laneuveville - Strasbourg.

Replace in the parent relation of the Véloroute 52 type=route by type=superroute


In the table below, the whole tree structure of the constituent relation is represented in the segment 1 of the Paneuropa-Radweg cycle route. It is about 1500 km long, segment 1 representing the French part is about 500 km long. It operates almost all along the Véloroute 52 Paris - Strasbourg, which uses multiple smaller routes.

icn icn child ncn / icn child-child ncn child rcn / ncn-rcn child lcn / rcn-lcn child others ncn / icn
relation Paneuropa-Radweg (PAN) (type=superroute) relation PAN Segment 1 : French Paris – Strasbourg/Kehl (type=route) relation Véloroute 52 (V52) : Paris – Strasbourg (type=superroute) relation V52 : Paris 1er - Paris 19e (type=route) relation V52 : Paris 1er - Place de la Bataille de Stalingrad EV3



2 variantes

relation V52 : Place de la Bataille de Stalingrad - Rue de Crimée via Quai de la Loire

relation V52 : Place de la Bataille de Stalingrad - Rue de Crimée via Quai de la Seine

relation V52 : Rue de Crimée Paris 19e EV3
relation Piste cyclable du canal de l'Ourcq EV3
relation V52 : Claye-Souilly – Crouttes-sur-Marne (proposed) No
relation V52 : Crouttes-sur-Marne – Trélou-sur-Marne/Dormans (proposed)
relation Véloroute de la Vallée de la Marne
relation V52 : Condé-sur-Marne – Recy (proposed)
relation Voie Verte du canal latéral à la Marne
relation V52 : Moncetz-Longevas – Sermaize-les-Bains (proposed)
relation V52 : Sermaize-les-Bains – Fains-Véel (proposed) V16
relation Voie Verte de la Vallée de l’Ornain
relation V52 : Saint-Amand-sur-Ornain – Void-Vacon (proposed)
relation V52 : Void-Vacon – Toul (proposed)
relation La Boucle de la Moselle : Toul - Richardménil
relation La Boucle de la Moselle : Toul - Chaudeney-sur-Moselle
2 variantes
relation La Boucle de la Moselle : Chaudeney-sur-Moselle par les chemins
relation La Boucle de la Moselle : Chaudeney-sur-Moselle par les routes
relation La Boucle de la Moselle : Chaudeney-sur-Moselle - Richardménil
relation La Boucle de la Moselle : Richardménil - Laneuveville
relation V52 : Laneuveville – Maixe (proposed)
relation Véloroute voie verte du Sânon
relation V52 : Xures – Réchicourt-le-Château (proposed)
relation V52 : Réchicourt-le-Château – Gondrexange
relation V52 : Gondrexange EV5


2 variantes
relation V52 : Gondrexange – Hesse via Bébing
relation V52 : Gondrexange – Hesse via Lorquin (proposed)
relation V52 : Hesse – Saverne
relation V52 : Saverne – Strasbourg
relation V52 : Strasbourg Rue du Général Conrad EV5


relation PAN Segment 1 : Strasbourg – Kehl (type=route) No description No description
relation PAN Segment 2 : Deutschland-Baden-Würtemberg (type=route) No description
relation PAN Segment 3 : Deutschland-Bayern (type=route)
relation PAN Segment 4 : Tschechien (type=route)
Visualization relations childs Paneuropa Route JOSM 2019-05-09


The stages

Some tourist cycle routes offer stopovers. In the concept of hierarchical relations, two itineraries along the same paths do not necessarily propose the same steps. The solution is to create a child relation listing each step. This relation uses the same tags as the usual cycling relation ( type=route , route=bicycle , network=* , ref=* , from=* and to=* ) but uses an explicit name ( name=Véloroute 50 : Étapes ). The members of this child relation are exclusively stages, nodes located on the route paths bearing the stage role.

This type of relation will eventually evolve over time as needs change. By adding, for example, information panels specific to the itinerary, or hostels in partner with the operator...

Tags from and to

It was previously written that the tags from = * and to = * are mandatory, this is not the case. However, their use is strongly recommended because they can be decisive for certain specific cases. Imagine that an agency created a 30-km cycleway, and decided to use it for two local routes. In this case, the solution is to create a child relation for one of the two routes, which will then be included in the second route. Since the two job routes network = lcn, then the tags from = * and to = * differentiate them.

Proposal status

Concerning the management of child relations considered as proposals due to the use of the tag state = proposed (usually planned routes and therefore not yet existing in the field), they can be included in the same way others not having this status. A system for rendering or reusing these data respecting the concept of hierarchies, will differentiate them, either by ignoring them, or by treating them in a different way. Thus, when this way will exist in the field, it will be sufficient to remove this tag.

The variants

Many itineraries offer variants of their routes: There are several alternative paths, starting from the same place and ending up on another same place. Currently there is no standardized methodology for tagging these variants, however a working group is currently studying the issue following the SOTMFR 2018.

These tags are used for testing purposes:

  • via=*

Indicate here a city or other possible appointment, which allows to differentiate it from other variants, do not hesitate to use official names if they exist.

  • alternate=variant/main/no

variant : indicates that this is a variant.
main : is to be used if a variant is considered to be the main.
no : indicates that it is not a variant, it is the implicit value but may be useful to specify in some cases.

Examples : relation V52 : Gondrexange – Hesse via Bébing ; relation V52 : Gondrexange – Hesse via Lorquin

Regarding the introduction of these routes into the concept of hierarchies, the practice is to create a separate relation for each of the available variants, referenced at the lowest level (recall: lcn <rcn <ncn <icn). These relations representing variants, generally two in number, are then to be integrated into the corresponding parent relation.

If you add a route with a referencing of the same level or higher, if it uses the same variants, then it can exploit these relations as they are. Also, in the case where the route of the same level or higher, exploits only one of the variants, having no alternative, this variant becomes in fact the only available route (this is also the case if only use two out of three variants).

External Links

Relation hierarchies [ dead link ] concept used by Waymarked Trails

  1. The Toul - Richardmenil relation is divided into 4 child relations to take into account two variants, which makes a total of 9 relations for the Boucle de la Moselle relation. For simplicity these are ignored.