Proposal:Hierarchies route=bicycle
Hierarchies route=bicycle | |
---|---|
Proposal status: | Proposed (under way) |
Proposed by: | Axelos |
Tagging: | route=bicycle |
Statistics: |
|
Draft started: | 2017-12-20 |
RFC start: | 2018-12-30 |
The proposal is under discussion here : http://gis.19327.n8.nabble.com/Feature-Proposal-RFC-Hierarchies-route-bicycle-tt5930353.html [ dead link ]
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 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.
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:
- A parent relation taking the whole journey by listing its children (type=superroute)
- A child relation Toul - Pompey
- A child relation Pompey - Laneuveville (segment A)
- A child relation Richardménil - Laneuveville (segment B)
- A child relation Toul - Richardmenil (segment C)[1]
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:
- A parent relation representing the entire path by listing the children (type=superroute)
- A child relation Apach - Pompey
- The child relation Boucle de la Moselle: Pompey - Laneuveville (segment A)
- The child relation Boucle de la Moselle: Richardménil - Laneuveville (segment B)
- A child relation Richardménil - Lyon
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:
- A parent relation representing the entire path by listing the children (type=superroute)
- A child relation Paris - Toul
- The child relation Boucle de la Moselle: Toul - Richardmenil (segment C)
- The child relation Boucle de la Moselle: Richardménil - Laneuveville (segment B)
- A child relation Laneuveville - Strasbourg
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
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.
icn | icn child | ncn / icn child-child | ncn child | rcn / ncn-rcn child | lcn / rcn-lcn child | others ncn / icn |
---|---|---|---|---|---|---|
Paneuropa-Radweg (PAN) Paneuropa-Radweg (PAN) (type=superroute) | PAN Segment 1 : French Paris – Strasbourg/Kehl PAN Segment 1 : French Paris – Strasbourg/Kehl (type=route) | Véloroute 52 (V52) : Paris – Strasbourg Véloroute 52 (V52) : Paris – Strasbourg (type=superroute) | V52 : Paris 1er - Paris 19e V52 : Paris 1er - Paris 19e (type=route) | V52 : Paris 1er - Place de la Bataille de Stalingrad V52 : Paris 1er - Place de la Bataille de Stalingrad | EV3 | |
2 variantes
V52 : Place de la Bataille de Stalingrad - Rue de Crimée via Quai de la Loire V52 : Place de la Bataille de Stalingrad - Rue de Crimée via Quai de la Loire V52 : Place de la Bataille de Stalingrad - Rue de Crimée via Quai de la Seine V52 : Place de la Bataille de Stalingrad - Rue de Crimée via Quai de la Seine | ||||||
V52 : Rue de Crimée Paris 19e V52 : Rue de Crimée Paris 19e | EV3 | |||||
Piste cyclable du canal de l'Ourcq Piste cyclable du canal de l'Ourcq | EV3 | |||||
V52 : Claye-Souilly – Crouttes-sur-Marne (proposed) V52 : Claye-Souilly – Crouttes-sur-Marne (proposed) | No | |||||
V52 : Crouttes-sur-Marne – Trélou-sur-Marne/Dormans (proposed) V52 : Crouttes-sur-Marne – Trélou-sur-Marne/Dormans (proposed) | ||||||
Véloroute de la Vallée de la Marne Véloroute de la Vallée de la Marne | ||||||
V52 : Condé-sur-Marne – Recy (proposed) V52 : Condé-sur-Marne – Recy (proposed) | ||||||
Voie Verte du canal latéral à la Marne Voie Verte du canal latéral à la Marne | ||||||
V52 : Moncetz-Longevas – Sermaize-les-Bains (proposed) V52 : Moncetz-Longevas – Sermaize-les-Bains (proposed) | ||||||
V52 : Sermaize-les-Bains – Fains-Véel (proposed) V52 : Sermaize-les-Bains – Fains-Véel (proposed) | V16 | |||||
Voie Verte de la Vallée de l’Ornain Voie Verte de la Vallée de l’Ornain | ||||||
V52 : Saint-Amand-sur-Ornain – Void-Vacon (proposed) V52 : Saint-Amand-sur-Ornain – Void-Vacon (proposed) | ||||||
V52 : Void-Vacon – Toul (proposed) V52 : Void-Vacon – Toul (proposed) | ||||||
La Boucle de la Moselle : Toul - Richardménil La Boucle de la Moselle : Toul - Richardménil | ||||||
La Boucle de la Moselle : Toul - Chaudeney-sur-Moselle La Boucle de la Moselle : Toul - Chaudeney-sur-Moselle | ||||||
2 variantes La Boucle de la Moselle : Chaudeney-sur-Moselle par les chemins La Boucle de la Moselle : Chaudeney-sur-Moselle par les chemins La Boucle de la Moselle : Chaudeney-sur-Moselle par les routes La Boucle de la Moselle : Chaudeney-sur-Moselle par les routes | ||||||
La Boucle de la Moselle : Chaudeney-sur-Moselle - Richardménil La Boucle de la Moselle : Chaudeney-sur-Moselle - Richardménil | ||||||
La Boucle de la Moselle : Richardménil - Laneuveville La Boucle de la Moselle : Richardménil - Laneuveville | ||||||
V52 : Laneuveville – Maixe (proposed) V52 : Laneuveville – Maixe (proposed) | ||||||
Véloroute voie verte du Sânon Véloroute voie verte du Sânon | ||||||
V52 : Xures – Réchicourt-le-Château (proposed) V52 : Xures – Réchicourt-le-Château (proposed) | ||||||
V52 : Réchicourt-le-Château – Gondrexange V52 : Réchicourt-le-Château – Gondrexange | ||||||
V52 : Gondrexange V52 : Gondrexange | EV5
V16 | |||||
2 variantes V52 : Gondrexange – Hesse via Bébing V52 : Gondrexange – Hesse via Bébing V52 : Gondrexange – Hesse via Lorquin (proposed) V52 : Gondrexange – Hesse via Lorquin (proposed) | ||||||
V52 : Hesse – Saverne V52 : Hesse – Saverne | ||||||
V52 : Saverne – Strasbourg V52 : Saverne – Strasbourg | ||||||
V52 : Strasbourg Rue du Général Conrad V52 : Strasbourg Rue du Général Conrad | EV5 EV15 V16 | |||||
PAN Segment 1 : Strasbourg – Kehl PAN Segment 1 : Strasbourg – Kehl (type=route) | No description | No description | ||||
PAN Segment 2 : Deutschland-Baden-Würtemberg PAN Segment 2 : Deutschland-Baden-Würtemberg (type=route) | No description | |||||
PAN Segment 3 : Deutschland-Bayern PAN Segment 3 : Deutschland-Bayern (type=route) | ||||||
PAN Segment 4 : Tschechien PAN Segment 4 : Tschechien (type=route) |
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.
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 : V52 : Gondrexange – Hesse via Bébing V52 : Gondrexange – Hesse via Bébing ; V52 : Gondrexange – Hesse via Lorquin 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
- ↑ 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.