Proposal:Hiking trail relation roles
See Proposed_features/Recreational_route_relation_roles - version of that proposal that went through vote and was accepted |
Hiking trail relation roles | |
---|---|
Proposal status: | Draft (under way) |
Proposed by: | Mfbehrens99 |
Applies to: | |
Definition: | Better specification of the function of a special part of a hiking trail |
Draft started: | 2019-11-30 |
RFC start: | 2019-12-06 |
Proposal
There is no consensus about role values for members of hiking route relations. Roles can be used to improve rendering of hiking trails if the role values are unambiguously defined. This proposal was requested by Sarah Hoffmann on the FOSSGIS conference.
Only add secondary trails to the relation that are really part of the trail route, not made up or other trail routes.
Rationale
- This is important because roles can be assigned to members of a relation and there is no consensus about role values for members in a hiking trail relation.
- Additionally, it is very difficult to get a height profile of the trail with all the different alternatives, excursions or approaches tagged without marking them as such.
- Sarah Hoffmann (founder of waymarkedtrails.org) requested an unambiguous way of tagging alternatives and excursions at FOSSGIS 2019 in Dresden to be implemented in her map.
Examples
A first example can be found in the Monte Rosa tour.
Tagging
Role name | Explaination |
---|---|
None or main |
The main "normal" roletype for the main section of the hiking trails. |
forward |
Section of the hiking trail that can only be hiked into the direction of the way. |
backward |
Section of the hiking trail that can only be hiked against the direction of the way. |
alternative (alternate is also accepted) |
An alternative branches off then rejoins the main route at a significantly different point |
alternative:forward and alternative:backward
|
A alternative that can only be used into one direction e.g. via ferrata |
excursion |
Excursion trail (sidetrack) that leads e. g. to a viewpoint or peak. The path has to rejoin at roughly the same point where it left or else it will be a alternative.
All the paths that make up that excursion should be tagged as |
approach |
This path is not part of the main trail but gives the hiker access to transport infrastructure e.g. parking, train station, bus station, cable car or a different hiking route. |
How to use roles in a relation hierarchy
This diagram should help to better visualise the structure.
- The squares are relations which can contain further subrelations or
- ways which are displayed as smaller circles.
- The yellow circles are tagged with the role main. That means that they are part of the main hiking trail.
- If you want to extract the main hiking trail from this hierarchic structure, you have to flatten out the whole structure into one big one-dimensional list of ways. That means that you follow down the hierarchie until you find the first way and then take the next one. This is called depth-first_search. An example is also indicated by the red line in the diagram. After that you ignore everything that is not a way and is not tagged with the role main (forward and backward can be considered later). This should give us a linear route that contains all elements from the main route in the correct direction.
- The three white ways in the bottom right corner could be an alternative. For everything to be neat and tidy it has been put into a subrelation. Because it is just not tagged with the main role it has simply been ignored when we tried to figure the main trail out.
- The fourth way in our main relation is also white. This one represents a short and very simple excursion to a viewpoint. This one is also ignored in the main trail procedure
Additionally roles can also be assigned to relations. In this case all the elements in this relation inherit the role from their relation. With this feature it is possible to create a relation with all the paths of an alternative and only assign the role to the newly created relation. Still, all the ways are considered as alternatives.
Applies to
All and part of a relation tagged withtype=route
and route=hiking
or route=foot
Rendering
This proposal will help hiking maps to handle the data better in terms of calculation of lenght and hight profile.
Features/Pages affected
Many hiking trail relations should be updated.
The new rules should be explained on the Wiki-Page about Walking Routes with some examples.
A plugin / reworked relation editor for e.g JOSM would help to work on the relations
See also
- Proposed_features/Recreational_route_relation_roles - version of that proposal that went through vote and was accepted
Comments
Please comment on the discussion page.