Proposal talk:Hiking trail relation roles

Alternative vs main

How to handle case where hiking trail splits into two versions and none is main/alternative, you just have version A and version B? Real example: https://en.mapy.cz/turisticka?x=19.9668710&y=49.2614064&z=15 (at least both versions had the same rank when I was there) Mateusz Konieczny (talk) 10:36, 6 December 2019 (UTC)

It is important there is only one main path to generate elevation profiles and export routes as one contiguous way. I understand that sometimes it is not one main route and some alternatives but then it is not be possible to generate an elevation profile. --Mfbehrens99 (talk) 11:13, 6 December 2019 (UTC)

I would put each main routes in a separate relation and then both in a superrelation. Then optionally assign roles to one or both the subrelations. Is that within the scope of this proposal?--Peter Elderson (talk) 12:55, 6 December 2019 (UTC)

Nodes, ways or (sub)relations?

i guess backward and forward roles are for ways only, the other roles are more suited for relation members. Or not? Could I enter all the ways of a 3 Km medieval castle excursion to a viewpoint into the hiking relation holding the ways of the main route, each with the 'excursion' role? I think this should be explicit. --Peter Elderson (talk) 10:57, 6 December 2019 (UTC)

This proposal was mainly designed for the roles of ways that make up the path. I think in general the type=superroute should be discussed more: When should it be used, how and there have to more tags a superroute should be able to hold.

Let's not do that. Let's just say type=route can contain ways as members, or other relations. I am inclined to forget the nodes altogether for the moment. When I say superroute I mean type=route containing relations. Subrelation just means it's a member route relation of a higher route relation. Need for different tagging at a higher level is one of the reasons for creating higher route relation.--Peter Elderson (talk) 14:51, 6 December 2019 (UTC)

But then you mean that we should not use type=superroute but only put subrelations into relations. --Mfbehrens99 (talk) 17:17, 6 December 2019 (UTC)

I think type=route is enough. Super does not add information. type=route can contain ways but also relations tagged type=route. In turn it can stand on itself or be part of a higher level route. When handling these relations, the route hierarchy has to be solved. --Peter Elderson (talk) 22:16, 8 December 2019 (UTC)

superroutes are mainly in use with bicycle routs although I think that there is still no need for them. My Idea would be to deprecate this tag or are there any reasons that explain why we still need this tag? Taginfo says that there are only 5 superrelations currently in use. --> Talk:Relation:superroute --Mfbehrens99 (talk) 08:57, 17 December 2019 (UTC)

Waymarkedtrails treats them same as any other route relation. I don't know what other renderers/data users do. You could say it's the top of the hierarchy, but when the supperroute is added as part of a still higher relation, does the type change? I don't think so. You just have a route hierarchy, on the lowest level you have the ways and above that you have only relations as members. Maybe some nodes, but there is no consensus at all about that. --Peter Elderson (talk) 14:31, 30 December 2019 (UTC)

Additionally, the issue concerning subrelation was requested by many users. The advantage of just putting all the ways into one relation (and then for very long trails putting the different daily stages into one superrelation) is much faster than to create a new relation for every single and small excursion and alternative. However to have many small subrelations is probaply much more tidy and also easier to interpret by a computer.

That ship has sailed I think. Very large relations are difficult to handle and difficult to maintain, lots of trails have been divided. Also lots of very long trails are still around. Both have to be handled. --Peter Elderson (talk) 14:51, 6 December 2019 (UTC)

I am not talking about putting all the ways of one big hiking trail into one relation but more splitting the relation into smaller pieces but then adding roles to the ways themselves. But from the direction into which this discussion is leading I see that we will probably use sub and super relations and assign the roles to subrelations.--Mfbehrens99 (talk) 17:17, 6 December 2019 (UTC)

That's what I think. Note that lower level relations (containg just a chain of ways) are often shared by multiple routes, and they can have a different role in different higher order routes. This means you cannot assign the variant roles directly to the ways. --Peter Elderson (talk) 22:16, 8 December 2019 (UTC)

New Idea is shared below or on the proposal page.

I wonder in how far relations still have a direction? Many users claimed that the forward and backward is only for ways but I think that roles also have a specific direction.

What would forward or backward mean, when applied to a route relation? Forward, compared to what?--Peter Elderson (talk) 14:51, 6 December 2019 (UTC)

The elements of a relation are in a sorted list. So why don't we use forward from top to bottom for forward and bottom to top backward --Mfbehrens99 (talk) 17:17, 6 December 2019 (UTC)

Note that forward and backward roles used in cycling routes have a very specific definition. I have seen this used in hiking relations as well. The existing meaning is not related to the route direction (sorting order), but to the direction the way is drawn in OSM. So you could use the roles forward and backward for relation members, but then they might also be there on ways within the lower level relation. Might pose problems in interpretation?--Peter Elderson (talk) 22:25, 8 December 2019 (UTC)

Elements in a relation are not always sorted. Relying on them being sorted is not guaranteed. Warin61 (talk) 21:09, 15 December 2019 (UTC)

These are two problems we have to face. That relations are not always sorted is a problem in general, not just in case of subrelations. I think that this is a problem that is there anyway. By not adding subrelations we are just shifting back the problem back to the superrelations.

Forward and Backward is an other problem. Somebody said that this is already in use with bike routes. How is this problem solved here? Although some mappers don't want to hear that, why don't we just change the use of these two roles for hiking? Or is there any important argument that needs these roles like they are right now. Actually, it does not even make sense how backward and forward are used in public transport. It is not very difficult to write a script that figures out in which direction the way should be pointing for the route to be linear but it is a lot of work and there is a lot of potential for errors while mapping these roles. --Mfbehrens99 (talk) 08:57, 17 December 2019 (UTC)

role alternative with forward/backward

An alternative path might be restricted to a certain direction. This is common for a Steig, via ferratas or narrow paths which are sometimes a more challenging alternative to a section of a regular hiking trail. Do we need additional roles alternative_forward and alternative_backward to map them correctly? Or is it sufficient to add Key:oneway to these ways? --scai (talk) 11:15, 6 December 2019 (UTC)

You are right. Then the same thing would apply to forward and backward.

However I could imagine that it is still useful for the way that is leading to the a via ferrata. To determine whether a alternative is oneway you would have to look at all the ways if one of them is oneway. I would like to hear other comments / ideas. --Mfbehrens99 (talk) 11:33, 6 December 2019 (UTC)

Note that alternate may be a oneway segment of a hiking route, without some/all ways underlying it being oneway=* or oneway:foot=* Mateusz Konieczny (talk) 08:52, 7 December 2019 (UTC)

When a set of ways is tagged with forward/backward this does not automatically mean that you are not allowed (or able) to use this path into the other direction. It only means that this section of the path is only signed into one direction. On some hiking trails the main trail can fork into two trails and the signs are telling you to take one of the trails into one direction and the other one for the other direction. This does not necessarily legally restrict you to use the paths into the other direction. That is why, at least we need some forward and backward roles.--Mfbehrens99 (talk) 08:18, 8 December 2019 (UTC)

Difference between approach and excursion

Seems to me that these are in effect the same thing: a branch from/to a POI. Approach and Excursion are functions of a branch. How about the role "branch" for both purposes?--Peter Elderson (talk) 11:38, 6 December 2019 (UTC)

Peter, I think both can exist, there is a small difference. In Belgium and The Netherlands, the GR routes have what we call 'aanlooproute'. It's the connection from a train station to the main trail. I would not see this as equal of an excursion. --S8evq (talk) 12:03, 6 December 2019 (UTC)

The same can be seen at the Rheinsteig in Germany. There is the main route staying on the plateau and many marked trails coming up from the rhine vally to join the main trail. But only those trails which are marked with the Rheinsteig symbol should be added into the relation.
However, the definition of all the different role types have to be very specific or it will all become a mess. --Mfbehrens99 (talk) 12:23, 6 December 2019 (UTC)

For me an 'approach' is a point of access (bus, train, car). But an 'excursion' is to access a point of interest or service (a view, some historical feature, a camp site). Neither form part of the main route. Warin61 (talk) 23:50, 6 December 2019 (UTC)

Cycling too?

I don't see any reason to exclude cycling route relations from this - the same applies.

FWIW "forward", "backward" and "alternate" are already in widespread use and there's no reason for them to go through the voting rigmarole. --Richard (talk) 11:39, 6 December 2019 (UTC)

+1 for cycling routes. Fun fact, "alternative" and "alternate" have almost exactly the same number of uses. We could have the discussion if one of the two should be deprecated but I tend to think: why bother. Lonvia (talk) 23:02, 6 December 2019 (UTC)

And horse, skiing, skating too. Warin61 (talk) 00:06, 7 December 2019 (UTC)

I think that we have to be a little more careful here. For skiing everything is a little different because everything is only one-way. --Mfbehrens99 (talk) 14:11, 7 December 2019 (UTC)

+1 for cycling routes.--RobHubi (talk) 19:15, 15 December 2019 (UTC)

Different Role Types

Here are three types of paths. The straight vertical path is always the main path. The red dot is a POI.
The question now is. Which path gets which roles? The left one could be considered as a excursion because the POI is maybe only 50m away from the path. But here we would have to draw lines concerning the distance that is hiked.
Thatfor, I would say that every excursion way can be hiked to the POI but then also has to be hiked back again.
Under that definition the left example would be an alternative and not an excursion.

The middle one is an example for an excursion. However, the difference between an excursion and approach is also not very easy to define.
A single path leading to a dead end (like a viewpoint next to a cliff or a viewpoint where simply no other ways are) is an excursion.
The approach role is usually only used for long distance trails. For an approach it is important that there is a possibillity of leaving (e. g. parking and road, train station and so on). These paths are usually hikied only once (or on the first and on the last day if it is a round trip).

A special case may be something like alpine huts. On one hand, they can be considered as an excursion for lunch or so. On the other hand, you can also rest there for the night. If the route is a collection of daily stages then it is very reasonable to use the role approach

This is open for discussions now --Mfbehrens99 (talk) 12:50, 6 December 2019 (UTC)

I would say excursion means you come back to the main route at roughly the same point where you left it. In between you can do straights and loops, doesn't matter. E.g. go through the forest, do a tour of the lake, then return by the same forest road to your main hike.

An alternative branches off then rejoins the main route at a significantly different point.

An approach is a one-ended separate branch to/from the main route.--Peter Elderson (talk) 13:13, 6 December 2019 (UTC)

An 'approach' is an access way from a bus, train, car, boat, or aeroplane. Warin61 (talk) 23:59, 6 December 2019 (UTC)

Is 'excursion' appropriate for a side trail that leads to services, such as a lean-to, campsite, spring, or privy? --Kevin Kenny (talk) 00:59, 7 December 2019 (UTC)

Initial reaction. I think so. An excursion is a trip off to something that goes there and comes back .. so yes. Warin61 (talk) 02:50, 7 December 2019 (UTC)

I'd say that it has more to do with purpose. Otherwise, you could tell the difference between 'alternative' and 'excursion' by topology alone. --Kevin Kenny (talk) 01:07, 7 December 2019 (UTC)

You are right that the difference should rather be seen from the purpose of the trail because the user goes there for the purpose. If we would the topological difference the information can be misinterpreted by the user. The following picture is an example for that:

The red dot represents a train station, the black line is the main trail and the blue trail is not the main trail.

The blue trail on the left is two approaches. However, what would the blue lines be on the right? Actually, it could be seen as a alternative although I would find the information misleading to the map user. It is not intended by the creator of the trail to hike down into the vally and up again.

So in my opinion should only between approach and alternative, excursion should only be told by the purpose. But the difference between alternative and excursion should still be told by the topology. A excursion has to rejoin the path at (roughly) the same place where it left it, no matter how the rest of the way looks. --Mfbehrens99 (talk) 12:01, 7 December 2019 (UTC)

Rendering

Rendering potential is the main driver for this proposal. Which types of alternatives or sections are envisioned to be rendered different from main and from each other?--Peter Elderson (talk) 13:37, 6 December 2019 (UTC)

I think it would be great to see some applications to support rendering for this proposal. Apps could have some buttons where you hide/show excursions, alternatives, shortcuts and approaches.

Additionally a revised editor (or plugin) for JOSM would make mapping of such big structures much easier. --Mfbehrens99 (talk) 13:50, 6 December 2019 (UTC)

One of the main drivers for me is the elevation profile and gps files from 'waymarked trails'. By tagging these roles it should help the rendering of the elevation profile and the gps file/s be more organised. Warin61 (talk) 00:04, 7 December 2019 (UTC)

Use of Subrelations and Superrelations

Some user requested to use subrelations to map parts of hiking trail and then assign a role to the subrelation instead of each member of this subrelation. In some cases this makes a lot of sense (long alternatives) however in other cases (an excursion trail to a viewpoint made up of two ways) it seems a little overdone.

My suggestion would be to establish a system that is able to handle both ways of mapping at once.

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 which don't have a role 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.

In this way both of the possible ways to map hiking trails are combined into one way.--Mfbehrens99 (talk) 14:17, 8 December 2019 (UTC)

Nice work. The picture shows the image I have in my head when thinking about the hierarchy. About inheritance of relation role as the role of all the ways underneath: I think you can't do that for the forward and backward roles, because these are defined differently for relations than for ways. For the relation forward means in the direction of the order of ways in the relation, but for ways in the relation it means in the direction the way has in OSM. A way could then have the backward role within the relation and inherit the forward role from the relation. For hiking, this would (as it stands) be an exception, but for cycling it would occur in many routes. I think it's better to just use the relations matching the role you are looking for when resolving the hierarchy, and ignore the ones that do not match. Once you get to the ways, for most way roles you could apply the same filter, except for the forward and backward roles which require different handling and can occur within all the other roles. But, how this is actually done in the code is of course up to the data user.--Peter Elderson (talk) 07:26, 12 December 2019 (UTC)

Introductory text

"There is no unique way to tag roles in hiking route relations although they carry a high potential for the rendering of hiking trails." Not strictly true. There is a way to tag roles, but the roles or role values are not defined clearly, uniquely and exclusively. Suggestion: "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 uniquely defined." --Peter Elderson (talk) 09:17, 9 December 2019 (UTC)

Resolved

--Mfbehrens99 (talk) 07:23, 10 December 2019 (UTC)

Secondary trails?

"Only add secondary trails to the relation that are realy part of the trail route, not made up or other trail routes." I'm not sure what this means, exactly. By secondary trails, do you mean variants, i.e. ways or routes that do not belong to the main route? What does "made up or other trails" mean exactly? Made up=Not waymarked? Do you have an example of "other"? --Peter Elderson (talk) 09:35, 9 December 2019 (UTC)

Ascent/Descent/both

Hiking routes in Japan, especially on Mt Fuji, have different ascent and descent routes on the steeper sections. These cross and overlap for very short sections, and are mapped as such. There is no main or alternate, just Ascent and descent, labeled as such. The routes I am familiar with in California are mainly “loops” that have no hiking direction, but these Mt Fuji routes are one-way but shared, overlapping, intertwined, - but heavily signed for one-way movement. It is much more complicated than a simple loop (think of 4 loops twisted together around a ring and each other), so having members be easily labeled as “descent” and “ascent” would be much less confusing and not rely merely on the name=FooBar (descent). I assume “main” could take the place of “both”. Javbw (talk) 10:38, 9 December 2019 (UTC)

Looks like adding oneway=yes and signed_direction=forward to the relations would help. Rendering could show an arrow or > signs based on that. --Peter Elderson (talk) 11:16, 9 December 2019 (UTC)

if You are making a way to tag how different trail segments are interconnected, including “excursions” from the trail, then there should be some way to tag ascent and descent - “forward” for ascent and “backward” for “descent”? These are heavily trafficked trails, but not simple loops. I want to be able to tag this information as metadata, not just “one way”. I can do that already. Javbw (talk) 01:00, 12 December 2019 (UTC)

If you woud apply forward and backward to ways in a single route relation, they mean in (forward) or against (backward) the direction the way has in OSM. Forward and backward roles of relations in a higher relation would mean in or against the order of the ways within the lower relation. I don't think it is wise to put yet another meaning in these roles. I have looked at the mount Fuji relations, looks to me that ascents and descents are different routes for most of the way, so I would keep them as separate relations. You can then tag oneway and ascent-descent on the separate relations. Some ways are then in both relations; that's no problem. Additional information such as ascent and descent can be tagged on the relations. The current proposal would allow you to mark the variants in e.g. https://hiking.waymarkedtrails.org/#route?id=223084 . That would repair the height profile and the export of the main descent route.

If an ascent and a descent really belong together (according to name, operator, symbol, travel guide etc.) combine them in a higher relation. You could then assign roles like ascent and descent to the member relations, but I don't really see what information that adds that cannot be seen or extracted from the member relations themselves. Or am I missing something? --Peter Elderson (talk) 08:39, 12 December 2019 (UTC)

Alternative/excursion/shortcut/approach marked with a different symbol.

"All the paths that make up that excursion should be tagged as excursion, as far as they are still marked like the main trail." I think the symbol can differ. I know national foot trails using a differently waymarked local roundtrip or a section of a regional path as an alternative, e.g. alternative with dog, "Klompenpad variant" (Wooden shoe variant through farmland), high water variant, train station approach or seasonal variant. In general, waymarking is not necessarily the same along the full extent of a long hiking trail, even if only the main path is considered. Especially international trails tend to vary a lot. The other way around, one symbol is not necessarily limited to one trail. Nederland has about 20 national trails marked white-over-red, 20 regional trails all waymarked yellow-over-red, and at least a dozen PT-centered daytrips using both symbols (using sections of the national and regional trails). Approaches tend to use a variation of the symbol of the trail they lead to, eg half-width stickers. There is more, but let's leave it at this. --Peter Elderson (talk) 18:53, 9 December 2019 (UTC)

Thanks!

I like this proposal as it reads now. Thanks a lot for working this out :)--PangoSE (talk) 20:50, 15 December 2019 (UTC)

Yes, thanks. Good thing! -- Geowas (talk) 07:54, 17 December 2019 (UTC)

Updating other wiki pages

The proposal page currently has "The new rules should be explained on the Wiki-Page about Walking Routes with some examples." There are probably more pages describing the tagging of walkin relations, for example: https://wiki.openstreetmap.org/wiki/Hiking https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot All these pages transclude the template https://wiki.openstreetmap.org/wiki/Template:Tagging_scheme_for_hiking_and_foot_route_relations Perhaps you could add the information about the member roles to that template. Or if not, at least use a template as well and transclude it on all pages about hiking/walking. --S8evq (talk) 11:17, 17 December 2019 (UTC)

Unique Role

> alternative (alternate is also accepted)

No, only one - IMHO alternative - should be accepted.

Rationale: "Roles can be used to improve rendering of hiking trails if the role values are uniquely defined"

--Nospam2005 (talk) 12:40, 21 December 2019 (UTC)

Change the Rationale to "...unambiguously defined"? --Peter Elderson (talk) 14:43, 30 December 2019 (UTC)

I took the liberty to change this in the main text. --Peter Elderson (talk) 09:38, 23 January 2020 (UTC)

Separate loops belonging to the named trail

--Peter Elderson (talk) 11:13, 5 March 2020 (UTC) In Nederland, we have named hiking routes with, or even consisting of, separate roundtrips. Example: "Waddenwandelen": a series of roundtrips over a group of islands. The main trail is a route relation containing the island sections as member relations. So it's inherently discontinuous, and the sections are not alternatives, excursions or approaches. A few other trails do have a main route and a few branches, plus one or two completely separate roundtrips (daytrips) which are considered by the operator to belong to the main route. I think these detached sections would need a separate role value? E.g. detached? This would enable the renderer to render them like the main trail, but exclude them for export.

role=POI, guidepost, information

(role=* - Nutzungen als Vorschlag - unabgestimmt!)

• Wegstrecken (role=forward, role=backward, role=excursion für Abstecher, role=alternative für Varianten, role=connection für Verbindungen, role=approach für Zuwege)
• Gipfel, Aussichtspunkte (role=POI)
• Sehenswürdigkeiten, Höhlen, besondere Bäume (auch zur Nav. ohne Gerät)(role=POI)
• Info-Tafeln, Karten, Touristinformation (role=information)
• Wegweiser - role=guidepost - bereits akzeptiert

https://wiki.openstreetmap.org/wiki/DE:Wandern#In_die_Relation_aufnehmen

--Geri-oc (talk) 08:52, 7 April 2020 (UTC)