Proposed features/Recreational route relation roles
|Recreational route relation roles|
|Definition:||specification of role values for members of a recreational route relation|
- 1 Definition and scope
- 2 Applies to
- 3 Tagging
- 4 When to apply to way members, and when to relation members
- 5 More than one main variant
- 6 Examples
- 7 See also
- 8 Comments
- 9 Voting result 2020-06-17
Definition and scope
Basic role values (main, alternative, excursion, approach and connection) are defined for members of recreational route relations, except where a more specific proposal has been approved. An example of such an exception is route=piste. The approved role set applies to routes of these types: bicycle, canoe, foot, hiking, horse, inline_skates, mtb, running.
This does not exclude the use in non-recreational routes. The connection role is already in use for relations of type network, and is certainly applicable for "functional bicycle routes" which are intended for commuters rather than recreation.
The roles enable renderers and data users to filter or select members for further processing according to role value. Different line types could be rendered for different roles, e.g. continuous for main and dashed for all other roles. Or select only members with a particular role to calculate length or height profile.
and members of a relation tagged with type=route and route=hiking or route=foot or route=bicycle or any other recreational route type (canoe, horse, inline_skates, mtb, running), except where a more specific proposal has been approved. An example of such an exception is route=piste.
Note: Role values for node members are not defined here.
Note the "signposted or otherwise waymarked" requirement. Even the most useful path for approach that is not signed/waymarked as a part of route must not be added to the route relation. This requirement is not specific to this proposal.
When to apply to way members, and when to relation members
The roles are applicable to way members in a basic (single strand) route relation, and to relation members (child relations) in a parent route relation or superroute.
Apply to ways: only in single strand routes without forward/backward roles
Do not use these roles on ways in double strand route relations.The forward/backward roles (directional roles) cannot be combined with the functional variant roles on the same ways.
Recreational routes are often single strand i.e. either both directions use exactly the same ways or the route is waymarked in one direction only.
Ways in double strand route relations, especially common in bicycle routes, use the roles forward and backward to indicate in which direction a way should be used with respect to the direction it is drawn in OSM. This is in effect a way to combine two routes in one route relation, where most of the ways are common to both route directions while other sections have different ways for each direction. This directional use of roles on ways can conflict with the functional roles, when e.g. a bicycle route has an alternative route with forward and backward roles in it. There is no approved way to combine two roles for one relation member.
If this problem occurs, map the variant route in a separate route relation and include both the main route relation and the variant route relation as members in a parent route relation. This is described in the next section.
Apply to child relations in a route hierarchy
Within a parent relation, apply the roles to the members of type relation. Note that a particular member relation may have one role in one parent, and at the same time a different role in another parent relation. The parent relation itself may be a member of one or more higher route relations and have yet a different role there.
It is up to the data user to resolve this hierarchy according to purpose. A common procedure will probably be to take a relation, leave out all the non-main members, then if the members are relations get the main members of those, etcetera until only main ways are left. Then perform further processing (rendering, routing, height profile, total length calculation).
More than one main variant
The role alternative in this proposal denotes a secondary route. If there is more than one equally important main route, do not use roles on the ways but create separate route relations. If necessary they can be combined into a higher parent relation, without assigning roles to the main child routes. They will both default to main. Calculations, processes and exports based on role filtering will then produce non-optimal results for this top level route relation. Note that this is no different than the current situation e.g. for long international routes consisting of country-based sections with equally important variant routes through one or more countries.
Parent route with child routes, roles main (none), alternative and connection: https://www.openstreetmap.org/relation/9769895#map=16/51.5292/4.3080 and on waymarkedtrails: https://hiking.waymarkedtrails.org/#route?id=9769895&map=16!51.5289!4.3101
This was a more complex earlier proposal with more role values and combinations. It did not reach the voting stage.
Please comment on the discussion page.
Voting result 2020-06-17
Individual votes are on the talk page