Proposed features/Hierarchies route=bicycle

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Proposed features/Hierarchies route=bicycle
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް
Hierarchies route=bicycle
Status: Draft (under way)
Proposed by: Axelos
Tagging: route=bicycle
Drafted on: 2017-12-20

This page is in draft stage, but do not hesitate to participate.

This kind of manipulation is more for advanced users, not beginners because relation manipulation is not necessary easy in OpenStreetMap.


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

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.

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.


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.

Since the project hierachies is not validated, the PAN Segment 1 relation remains independent for the moment. The Véloroute 16 (Dieppe - Strasbourg) use partially the Véloroute 52 (V16 is partielly implemented).

icn icn child ncn / icn child-child ncn child rcn / rcn child lcn / rcn-lcn child others ncn / icn
relation Paneuropa-Radweg (PAN) relation PAN Segment 1 : French Paris – Strasbourg/Kehl (Hierarchical relations is not enabled) relation Véloroute 52 (V52) : Paris – Strasbourg Paris – Crouttes-sur-Marne No
relation V52 : Claye-Souilly – Crouttes-sur-Marne (proposed)
relation V52 : Crouttes-sur-Marne – Trélou-sur-Marne/Dormans (proposed)
relation Véloroute de la Vallée de la Marne (proposed)
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 V16
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 V16
PAN Segment 1 : Strasbourg – Kehl No description No description
relation PAN Segment 2 : Deutschland-Baden-Würtemberg No description
relation PAN Segment 3 : Deutschland-Bayern
relation PAN Segment 4 : Tschechien


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

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 relationships 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 concept used by Waymarked Trails