Proposal talk:Recreational route relation roles

Post-vote cleanup

--Peter Elderson (talk) 17:22, 18 June 2020 (UTC) I intend to wrap things up a little now that the role set has been approved. This will involve some changes in the wording, without changing the role set or its application. These are my intentions:

• DONE Since it's no longer a proposal, rephrase and reposition some sections to make it more like an instruction.
• DONE The first image shows roles on ways, next to a section that says to use roles on relation members. Add an image of roles on relation members.
• DONE Move the votes to the talk page.
• DONE Restructure the talk page: move todo's to the top, and handled issues to the bottom.

If anyone thinks a change affects the approved set and its application or scope, please feel free to improve or revert, preferably with argument.

Re: https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Recreational_route_relation_roles&oldid=2001844 - this is incorrect. Please check https://wiki.openstreetmap.org/wiki/Proposal_process#Approved and follow the instructions there. Or if you don't mind, I can help you with the clean-up. The approved proposal should not be edited after the vote, unless to archive it.

I see you've mentioned these roles at Template:Tagging_scheme_for_hiking_and_foot_route_relations which is used in Tag:route=hiking and Tag:route=foot. Could you also mention the new roles in Tag:route=bicycle and other recreational route relation types like Tag:route=canoe, Tag:route=horse, Tag:route=inline_skates, Tag:route=mtb?

DONE --Peter Elderson (talk) 19:52, 25 June 2020 (UTC)

Also, would you please make the pages for the new role tags? I think these should be located at Role:main, Role:alternative, Role:excursion, Role:approach and Role:connection. It would also be good to add links to those pages from Relation:route later (see https://wiki.openstreetmap.org/wiki/Relation:route#Members). Or if that's too much work, perhaps you can make an overall page like Roles for route relations to start? Once this is done we can archive the proposal and link to the relevant page(s). --Jeisenbe (talk) 17:44, 25 June 2020 (UTC)

Thanks for the work you put in. You have posted a question on the tagging list; let's wait and see what comes, okay? --Peter Elderson (talk) 19:55, 25 June 2020 (UTC)

2020-06-28 Hm, not a lot of people seem to have an outspoken opinion. I will proceed and create Roles for recreational route relations. I will keep the "recreational" term, because it does not cover PT, rail, road and other cans of worms. A link to the Key:route page will have to do. Is that allright with you? --Peter Elderson (talk) 19:35, 28 June 2020 (UTC)

That sounds good, except that I would not use "recreational", because not all foot or cycling routes are for recreation: many cycling routes are used for transportation, commuting and utilitarian travel. Some foot routes are religious pilgrimages. Perhaps the best description for these type of routes is "non-motorized"? --Jeisenbe (talk) 21:12, 6 July 2020 (UTC)

True, but the role set is meant for recreational use. Routes for pilgrimage are used mostly for recreation; I've walked long stretches of "pilgrim routes" but never met a true pilgrim! The few pilgrims I met follow their own path (metaforically as well as literally), not the signed route. "Non-motorized" would include all node networks, which are abundant in Nederland and Belgium, spreading rapidly in Germany, and starting in France, Austria and Spain. But this role set has no meaning for node networks. So far, only 'çonnection' has a potential for wider use. All in all, I think we should stick with recreational for now. The roles set is meant for that; other uses are not excluded and if many other uses appear, we can widen the scope.--Peter Elderson (talk) 06:16, 8 July 2020 (UTC)

Other question: On https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations I have used the template for tags, but that is not right. There is a template for a single role, that doesn't fit either. I would like to make a new template that looks like the tag template but with r~v instead of k=v on top, but I could not figure out how to do that and I did not want to break anything... could I get some help with that? --Peter Elderson (talk) 06:17, 8 July 2020 (UTC)

Issues raised / things to consider after voting

--Peter Elderson (talk) 11:09, 5 June 2020 (UTC) Some issues may require a new vote in the future.

• JOSM sorting in relation manager does not yet handle the roles when they are set on way members -> developer's issue

Roles forward and backward on ways, as defined for routes where the directions differ at some locations, are handled as intended by the sorting routine. Other roles are currently ignored. The request is to sort the ways for each role separately (forward and backward are sorted as main). So main, foward and backward are sorted like it is now; all alternative ways are sorted separately and kept together; all excursions idem; etc. Let's call it: grouped sorting. This could be generic: the sort does not have to check for specific roles other than forward/backward, it can simply group all members with the same role together, alphabetically. Validation will warn if undocumented roles are used.

https://josm.openstreetmap.de/ticket/19411 --Peter Elderson (talk) 14:56, 18 June 2020 (UTC)

• FIXED BY DEVELOPER! Will be available next milestone update. [JOSM validator does not yet handle the new roles -> developer's issue]

JOSM's relationChecker warns that only forward, backward and guidepost are valid roles in relations. Shouldn't be too hard to get other roles accepted if the proposal is approved. Until then it's a warning, so it doesn't prevent the use.

https://josm.openstreetmap.de/ticket/19403#ticket --Peter Elderson (talk) 15:20, 17 June 2020 (UTC)

FIXED in 2020-07-02: Stable release 16731. --Peter Elderson (talk) 15:30, 9 July 2020 (UTC)

• iD might have more trouble validating/adapting route relations after e.g. splitting a way. -> test, then if needed -> github issue
• Make github requests with renderers, applications, apps and tools to handle the roles.

Posted a waymarkedtrails github issue: https://github.com/waymarkedtrails/waymarked-trails-site/issues/356 --Peter Elderson (talk) 09:33, 17 June 2020 (UTC)

• If possible, handle the current directional roles (forward and backward) with the proposed functional roles (alternative, approach, connection, excursion) when occurring in the same relation. -> vote on extension
• Other roles? -> vote on extensions
• Roles for nodes? > separate proposal, maybe combined later
• DONE Add other applications of "connection" role as a side note. -> explanatory text, no vote required.
• Add more/better real life examples of role tagging and results of the tagging -> explanatory, no vote required
• Adapt wiki pages
• DONE Inform communities

The Dutch, Belgian and German communities and the tagging list have been informed. --Peter Elderson (talk) 15:35, 17 June 2020 (UTC)

• CLOSE; NO SOLUTION repeating segments (glasses layout) -> vote on extension, or vote on different solution
• Extract possible improvements from the previous proposal -> vote on extension proposals, or vote on different solutions

Note that JOSM is not developed on github, they are using self-hosted bug tracker ( https://josm.openstreetmap.de/report ) Mateusz Konieczny (talk) 16:42, 5 June 2020 (UTC)

Thanks! --Peter Elderson (talk) 16:46, 5 June 2020 (UTC)

"Inform communities" - maybe obvious, but entry in weekly osm is likely a good idea Mateusz Konieczny (talk)

Somebody beat me to it! https://osmbc.openstreetmap.de/article/searchandcreate?search=https%3A%2F%2Fwiki.openstreetmap.org%2Fwiki%2FProposed_features%2FRecreational_route_relation_roles&SearchNow= --Peter Elderson (talk) 17:03, 5 June 2020 (UTC)

Features/Pages affected

Additions to wiki pages and tables about recreational routes.

Transfer

--Peter Elderson (talk) 13:05, 12 June 2020 (UTC) (Not part of this proposal) Idea for the future: a "transfer" role. This would be a section where you use a different method of transport. So it's part of the route, you just can't walk/cycle/ride/skate there so you use a transfer. Without the transfer, the route is not continuous and gpx-output will show a gap. Examples are ferry transfer over a river or a lake, bus or train transfer to get through a car-only tunnel. I will provide examples later (Nederland Oosterschelde tunnel, Afsluitdijk; Switzerland Vierwaldstättersee; Switzerland Sankt-Gotthard Pass during the winter; ? portage in canoe routes; ? cablecar in mountain routes). This would be a role that renders like an alternative but is included in gpx output, height profile, and routing, I think. Routing always has to look at the ways to determine access, so a walker would not be routed though a car tunnel even if relation says it's the right way, but this enables routers to warn about the transfer and not try to found a way around it.

A use case was briefly discussed on the tagging mailing list: a cable car transfer in a bicycle route. I suggested the transfer role as a generic solution, other use cases were posted. Maybe a proposal is coming up, maybe not. --Peter Elderson (talk) 05:08, 25 June 2020 (UTC)

Repeating segment

Is there a way how to tag "repeating" segments? Should they be added several times?

Here is the example:

https://cycling.waymarkedtrails.org/#route?id=10995393&map=14!57.1689!24.5757

--Ursus (talk) 06:50, 3 June 2020 (UTC)

Good question, but this proposal does not address that. It is a more complicated issue, and this proposal just covers basic roles for rendering and filtering non-main sections. I will keep it in mind though. After the vote, the more complicated issues can be tackled separately. Ok? --Peter Elderson (talk) 08:12, 3 June 2020 (UTC)

I think that just adding them multiple times would be OK? Or is it not possible/causes validator complaints? Mateusz Konieczny (talk) 20:26, 3 June 2020 (UTC)

You can add them, of course. Rendering will be no problem. Validators, hm I don't know and I don't care too much: validators can be adapted. No, the problem is sorting, routing, en export for routing applications/devices.

• Routing planner applications do not have a problem, they just set a preference (high weight) for ways appearing in a certain type of relation, and it does not matter if they appear once or 10 times. But if a routing app is required to follow the route as it is set in the relation, it fails because it cannot handle the common section(s) appearing twice.
• Sorting is required in route relations. If a series of ways appears multiple times, automated sorting does not work.
• the same occurs with gpx output. The gpx is probably ok, but if you export it to a navigation device or app, the thing will re-route using all the trackpoints as Via points, and it gets very confused if the track had crossing or overlapping sections. (I have yet to see an application or device that simply follows the ways given in the relation, because that actually is the route and you don't have to reroute a route!)

I just talked to some fellow route mappers. The issue is well known, and you can't fix it with a role. The main problem is: you enter some of the ways twice, ignoring the validator, so far so good. But you cannot use the sort option; JOSM sorting will break the route into multiple smaller roundtrips. So you have to keep the route sorted manually.
Then waymarkedtrails will render it, and show a continous elevation profile, and export a fine gpx which you can use in a route editor.
Navigation with gps-devices and apps is a problem only they can solve. --Peter Elderson (talk) 19:46, 23 June 2020 (UTC)

Closed issues

Votes

• I approve this proposal. --GiantOSM (talk) 12:16, 15 June 2020 (UTC)
• I approve this proposal. --Ursus (talk) 10:32, 3 June 2020 (UTC)
• I approve this proposal. --Westis (talk) 11:02, 3 June 2020 (UTC)
• I have comments but abstain from voting on this proposal. I'm wondering how we're going to maintain all this when we're already seeing how hard it is to maintain linear/circular route Marc marc (talk) 11:13, 3 June 2020 (UTC)
• I approve this proposal. --streckenkundler (talk) 11:15, 3 June 2020 (UTC)

• I approve this proposal. --V0174 (talk) 11:26, 3 June 2020 (UTC)
• I approve this proposal. --MoritzM (talk) 11:47, 3 June 2020 (UTC)
• I approve this proposal. --TheBlackMan (talk) 11:50, 3 June 2020 (UTC)
• I approve this proposal. --Komadinovic Vanja (talk) 12:04, 3 June 2020 (UTC)
• I approve this proposal. --Galbinus (talk) 12:10, 3 June 2020 (UTC)
• I approve this proposal. @Marc marc - as I understand, it is tagged already as part of a route (where it is a part of the route). For linear/circular routes with no extra signed parts it will change nothing --Mateusz Konieczny (talk) 12:12, 3 June 2020 (UTC)
• I approve this proposal. Mir fehlt in der Liste das [in DE:Wandern] aufgeführte guidepost; POI; --Geri-oc (talk) 12:54, 3 June 2020 (UTC)

@Geri-oc Let's talk about the nodes later, ok? Peter Elderson (talk) 18:48, 3 June 2020 (UTC)

• I approve this proposal. --Waldhans (talk) 13:00, 3 June 2020 (UTC)
• I approve this proposal. --Thetornado76 (talk) 13:31, 3 June 2020 (UTC)
• I approve this proposal. I think this is especially useful in relations that contain smaller 'section relations'. A67-A67 (talk) 13:32, 3 June 2020 (UTC)
• I approve this proposal. --S8evq (talk) 14:26, 3 June 2020 (UTC)
• I oppose this proposal. To solve the forward/backward problem later would possibly require the tagging to change. Or introduce inconsistencies in the tagging scheme. Imo we should think about that now. One solution could be semi-coloning them: connection;forward. I'm thinking of the functional cycle route network in Belgium: "connection" would be useful, for example on the intersection between F7 and F40. I know the proposal is about "recreational routes" but "connection" is the same concept so it would be weird to disallow it on functional routes. —M!dgard [ talk ] 17:20, 3 June 2020 (UTC)

Good points! I think the forward/backward issue has been dealt with in the section "Apply to ways: only in singular strand routes". Connections of functional routes: I agree, this role is perfectly applicable there. Note that the role connection is also in use for node2node routes connecting different node networks. I think using the role here does not mean that it's exclusive. It is important that there is no conflict. Maybe after the vote a few words to clarify this are in order. Peter Elderson (talk) 18:48, 3 June 2020 (UTC)

• I approve this proposal. --CjMalone (talk) 22:14, 3 June 2020 (UTC)
• I approve this proposal. --Jeisenbe (talk) 23:04, 3 June 2020 (UTC)
• I approve this proposal. --JeroenHoek (talk) 12:14, 4 June 2020 (UTC)
• I approve this proposal. --Sdicke (talk) 12:56, 4 June 2020 (UTC)
• I approve this proposal. Thank you for putting this proposal to the vote. --geow (talk) 18:03, 4 June 2020 (UTC)
• I approve this proposal. --Mfbehrens99 (talk) 10:43, 5 June 2020 (UTC)
• I approve this proposal. --Roef (talk) 11:17, 5 June 2020 (UTC)
• I approve this proposal. --Adamfranco (talk) 14:44, 5 June 2020 (UTC)
• I approve this proposal. Thank you for this work --Fanfouer (talk) 18:00, 5 June 2020 (UTC)
• I approve this proposal. --Sommerluk (talk) 07:18, 6 June 2020 (UTC)
• I approve this proposal. Very useful. --Floridaeditor (talk) 14:27, 6 June 2020 (UTC)
• I approve this proposal. --Rskedgell (talk) 11:04, 14 June 2020 (UTC)
• I approve this proposal. --Rjgambrel (talk) 12:57, 14 June 2020 (UTC)
• I approve this proposal. A very sensible and useful proposal. Thank you for all your work on this. --PeterPan99 (talk) 14:39, 14 June 2020 (UTC)

• I approve this proposal. --Hholzgra (talk) 16:11, 14 June 2020 (UTC)

• I approve this proposal. --RobHubi (talk) 17:07, 14 June 2020 (UTC)
• I approve this proposal. --Andreas Binder (talk) 17:35, 14 June 2020 (UTC)
• I approve this proposal. --Soldier Boy (talk) 18:59, 14 June 2020 (UTC)
• I approve this proposal. --Michi (talk) 20:15, 14 June 2020 (UTC)
• I approve this proposal. --Reino Baptista (talk) 09:55, 15 June 2020 (UTC)
• I approve this proposal. Once it succeeds lets make sure to update JOSM and other developpers. --MomoMilkiway (talk) 10:18, 15 June 2020 (UTC)

excursions returning to a different point

> alternative: A waymarked alternative branching off then rejoining the main route at a significantly different point. The alternative is used instead of a section of the main route.

> excursion: Waymarked side track to a viewpoint or POI and back. The path has to rejoin at roughly the same point where it left. If not, use alternative. The excursion may be used in addition to the main route.

I think this needs to be clearer if you are choosing the role based on the topology (so return to same point or join up later up the track) or choosing the role based on the usage of the route (so to visit a POI or simply just to provide an alternative route)

From the wording here it sounds like this is based on topology alone so I'd suggest revising the excursion description to "A waymarked side track which rejoins at roughly the same point where it left, usually to visit a point of interest". --Aharvey (talk) 13:05, 20 May 2020 (UTC)

Thanks! Done. --Peter Elderson (talk) 13:15, 20 May 2020 (UTC)

waymarked

> Note "waymarked" part. Even the most useful path for approach that is not signed as a part of route must not be added to the route relation.

Glad to see this here, I'd make it bolder. It'll be very tempting for people to start marking alternatives, excursions, etc based on their opinion, but since it's not verifiable without signage and would just lead to conflicts of opinions, glad to see the requirement for only signposted features to be included.

PS. the term "waymarked" doesn't hold any meaning to me locally, is that just me or does it hold meaning in some locales? It's it just meant to mean signposted? --Aharvey (talk) 13:12, 20 May 2020 (UTC)

Thanks! Changed the wording. The requirement now has a special Note and it is repeated for each role - I think that is emphasis enough! --Peter Elderson (talk) 13:27, 20 May 2020 (UTC)

> Re. "..the term "waymarked" doesn't mean anything to me locally...".

“Waymark” is defined as:

(1) “in British English, a noun: a symbol or signpost marking the route of a footpath.” https://www.collinsdictionary.com/dictionary/english/waymark

(2) "an object serving as a guide to someone traveling" https://www.merriam-webster.com/dictionary/waymark

Thus, "waymarks" include signposts (a sign on a post) and also other symbols or marks, such as paint splashes on rocks, that identify the way. Personally, I am very happy to see “waymark” explicitly included here.

--PeterPan99 (talk) 16:37, 23 May 2020 (UTC)

Proposal

I like this proposal very much, thanks a lot for the creation. --RobHubi (talk) 18:48, 31 May 2020 (UTC)

Difference between approach and connection

I think it is very difficult to distinguish between approach and connection. For example, if there is an "approach" from a place, but there are also other routes leaving from the place, then this way would be both an approach and a connection, depending whether you start from this place or come from another route. I suggest to use only "connection" for both. --Mueschel (talk) 08:56, 1 June 2020 (UTC)

I had the same thought, though I wanted to use 'approach' for both. Which doesn't make any difference, as long as there is consensus and documentation. But hikers pointed out to me that for them, an approach is a completely different thing than a connection! An approach gets you started or ends your trip, while a connection gets you further. Since the role names are functional names, I decided to keep both approach and connection.
connection is then recognized on the road by signs at both ends pointing to the other route. Yes, this could topologically coincide with the approach function; then I think the approach function takes precedence for the hiker. It is a logical thing that you can switch routes at shared amenities and POI's; just when you're in the middle of nowhere you want to know about a special connection route.
How about I specify that a connection actually needs this bilateral signposting? --Peter Elderson (talk) 09:37, 1 June 2020 (UTC)

I have some problem with this definition. It makes sense in regions where you have some separate trails with defined starting places or entrance points. In other places (e.g. the Alps) its more common to have a network of interconnected trails. The proposed roles (apart from my comment here) make sense for me, but it will be really hard to define what an approach or a connection is. Some cases are obvious, but many are ambiguous as well. --Mueschel (talk) 10:18, 1 June 2020 (UTC)

I see. In fact, in Nederland we have many many routes all intersecting each other, and almost all have train stations in the main route. If the train station is actually on the main route, there is no approach. If the main routes intersect, there is no connection.
If there is a side path to/from a station, it's an approach, even if other routes pass by the same station.
Only if there is a signed sidepath landing on another route, so it's a side path for both routes and they refer to one another, only then it's a connection.
Maybe you could give a few examples of ambiguous sections?--Peter Elderson (talk) 11:08, 1 June 2020 (UTC)

With the clarification you added it should be fine. Related question: Should the 'connection' be added to both routes? That should be stated in the text. --Mueschel (talk) 11:28, 1 June 2020 (UTC)

Done, and thanks!--Peter Elderson (talk) 11:41, 1 June 2020 (UTC)

Different symbols and colours in one route?

The main trail is marked in blue whereas the approaches ("Zuweg") are marked in yellow

Below the header "Apply to child relations in a hierarchy" you state that you can put smaller relations into super relations. Does this implicate that it is possible to have multiple symbols/colours within one route relation? This would be great because I already know one example where one hiking trail is marked in different colours. The Rheinsteig in Germany

Yes you can tag a different symbol for the approach relation.
There is no guarantee about rendering though. Very few renderers, data users and tools actually handle the relation hierarchy well. The current proposal might help them with the handling of the relation hierarchy. Waymarkedtrails does this neat trick where the child relations in a parent relation are replaced by their members, recursively. If the parent's network tag is different from the child's, the child is kept and rendered as well; if not the child is not rendered after its members have been moved to the parent. That would mean that an approach relation would be dropped and its symbol would not be rendered. Once this role proposal is approved, the logic could be altered to keep the child route separate if it is an approach or another variant. In that case, its symbol would appear on the map.
But I am speculating. It is up to the renderer how to handle it, once the tagging has been approved and documented. --Peter Elderson (talk) 09:02, 5 June 2020 (UTC)

Forked Approaches?

How are we going to map a approach when it is forked?

Main Trail
    |                /------------------ approach a)
    |   approach    /
    |--------------<
    |               \
    |                \------------------ approach b)

This is another example you can only solve with relation members.

Make a relation for approach a and a relation for approach b. The common way will appear in both relations.
Add approach a and approach b to the main route relation, both with the role approach.
I actually have tagged a route with a split approach. It begins at a station, then a few common ways, then it splits and both parts land at different locations on the main route.
https://hiking.waymarkedtrails.org/#route?id=9500318&map=14!51.4562!5.5029 (load in OSM or JOSM to see the sections and roles)
--Peter Elderson (talk) 11:25, 5 June 2020 (UTC)

Is approach a and approach b a separate signed route or is it signed as part of the main trail? Is a and b the same signed route or a separate? I would map it in 3 difffereng ways depending on a case:

All signed as a one route - 1 relation have ways in approach added to relation, with role "approach".

Main trail is signed as one route, approach a and b as a one separate route - tag main trail as one relation, have separate relation for approach, all tagged without specified role.

Main trail is signed as one route, approach a and b as a two separate routes - create three relations, all tagged without any exotic roles

Mateusz Konieczny (talk) 16:47, 5 June 2020 (UTC)

"Named" alternatives

Great proposal. I would like to add an example: https://www.openstreetmap.org/relation/9563275 -> here the alternative has a "name" or "attribute" the original route is on asphalt but there is a "grass_alternative" (official name). At another point the original route is on grass but there is an "asphalt_alternative". Do you have any idea on how to incorporate that? I don't think it should be done using a role (as it is at the moment) because then we would have a never ending number of roles to maintain. keeping your "alternative" role though would need to add an attribute at some location, but I don't know where. --MomoMilkiway (talk) 09:24, 8 June 2020 (UTC)

I think description is the right tag for that. Here is an example: https://hiking.waymarkedtrails.org/?zoom=10&lat=51.4944&lon=5.90778&layers=FFBTT#route?id=8460902 . Please ignore the name which currently holds the same information, but that is not conform the wiki for name tagging. But that's a different can of worms!
--Peter Elderson (talk) 09:34, 8 June 2020 (UTC)

So the way would have the role=alternative in the relation and the tag description=Grass Alternative ? Sounds ok but maybe we can find a better solution later that actually adds a name (or other attribute). Searching for attributes of a relation member within the tags of the member itself sounds a bit complex, errorprone and similar to the deprecated oldstyle multipolygons. --MomoMilkiway (talk) 10:10, 15 June 2020 (UTC)

I think I was not clear enough! If you tag the alternative in the form of roles on the way(s) within the route relation, you can't tag a name or description for just the alternative. Because the way can, and often will, also be a main way in another route. I think the alternative has to be a relation on its own. So the ways of the alternative are in a separate relation. That one you can tag with description=grass_alternative, and include in the parent relation with a role "alternative".--Peter Elderson (talk) 11:00, 15 June 2020 (UTC)