Proposal:Hiking trail relation roles

From OpenStreetMap Wiki
Jump to navigation Jump to search
Hiking trail relation roles
Proposal status: Draft (under way)
Proposed by: Mfbehrens99
Applies to: wayrelation
Definition: Better specification of the function of a special part of a hiking trail
Draft started: 2019-11-30
RFC start: 2019-12-06


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.


  • 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 requested an unambiguous way of tagging alternatives and excursions at FOSSGIS 2019 in Dresden to be implemented in her map.


JOSM displays role tags

A first example can be found in the Monte Rosa tour.

Example for an excursion coming from a alpine_hut
alternative hiking path around lake Mattmark on
Here a black trail is a separate trail. Ways of other trails should not be part of the relation. For that reason the ways also have no special roles like excursion.


way Ways and relation Relations
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 excursion, as far as they are still marked like the main trail.

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 way and relation part of a relation tagged withtype=route and route=hiking or route=foot


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


Please comment on the discussion page.