Proposed features/Hierarchies route=bicycle

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Proposed features/Hierarchies route=bicycle
· Afrikaans · Alemannisch · aragonés · asturianu · Aymar aru · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · bamanankan · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · 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î · Latina · latviešu · Lëtzebuergesch · lietuvių · Limburgs · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tagalog · Tiếng Việt · Türkçe · Türkmençe · Vahcuengh · vèneto · walon · Wolof · Yorùbá · Zazaki · isiZulu · српски / 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.

Concept

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.

Example

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 / lcn child others 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 Relation not defined yet for V52 : 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 : 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 – Saverne V16
EV5
Relation V52 : Saverne – Strasbourg
Relation not defined yet for 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

Possibilities

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.

External Links

Relation hierarchies concept used by Waymarked Trails