[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Peter Elderson pelderson at gmail.com
Wed Mar 4 07:26:54 UTC 2020


After consulting the Dutch OSM community on the OSM forum, I have tagged
relation member roles for 3 recreational foot routes in Nederland:

1. The Roman LIMES trail
https://hiking.waymarkedtrails.org/#route?id=9214891
This national trail has several alternatives and one approach. The main
route is the Dutch part of the international LIMES trail.

2. The Floris V trail
https://hiking.waymarkedtrails.org/#route?id=9769895&map=9!51.9349!4.6883
This national trail has three short alternatives and I added one section
connecting this trail to the Dutch part of the GR5 (=E2).
The connecting section has the "approach" role within the parent relation.
The connection is signposted on both larger trails and waymarked with the
same symbol as the parent trails.

3. Brabantse Vennenpad https://hiking.waymarkedtrails.org/#route?id=9500318
This is a regional roundtrip trail, it is sectioned for daily stages and
includes a number of waymarked approaches to/from train stations.

Tagging roles like this in well-sectioned and
well-maintained+well-documented routes is very easy and takes very little
time. I can do all the national and regional trails in Nederland in an
hour.
Other routes would take more time, not for assigning the roles but for
straightening out.

If the roles were to be assigned to way members in "mixed" relations, it
would be much more difficult. Mostly because the relation editor in JOSM is
not equipped to deal with non-contiguous trails. It would require functions
such as "group the members according to role and sort within the group"
and/or "detect and sort chains of ways". I would rather spent the time to
section them first then assign roles to the section relations.

The roles as applied in this "pilot" do not affect any existing rendering.
We will leave them in place for anyone to have a go at using them in a test
of rendering or data use.

Personally, I would be very pleased if it amounts in slightly different
rendering of sections that have any role. On most walking maps in
Nederland, the lines of non-main routes would be dashed, but these usually
do not show multiple routes over the same ways. If you show all the routes,
you might have to render a node2node network line, local route line,
several national trails, a regional trail and all may be part of one or
more international trails. All of these may or may not have a role for that
one section... Can't be easy.

Best,  Peter Elderson


Op za 29 feb. 2020 om 23:10 schreef Peter Elderson <pelderson at gmail.com>:

> I think the proposal is not ready for use or for voting, but there does
> not seem to be much progress.
>
>
> The basics are clear enough I think.
>
> Though I myself would have made things even simpler (e.g. not bother with
> functions like approach or excursion, but simply use alternative and branch
> as roles), I am toying with the idea to move forward and start adding the
> roles:
>
> alternative, approach and excursion for wellknown hiking routes in
> Nederland, next time I do a regular consistency check on the lot. No
> role=main, It’s up to me to ensure that one main route is present when alle
> the special roles are filtered out.
>
> I would not use forward and backward roles as these conflict with how they
> are used in cycling routes. I prefer all recreational routes to use the
> same (or at least compatible) tagging scheme. Same with all the other
> suggested refinements and niceties involving access, direction, starting
> points, POI’s and what have you: I see too many complications.
>
> I would use the roles on relation type members, not on way members. This
> way the maintenance burden is low. Most hiking routes in Nederland have
> been sectioned and alternatives/branches already are separate relations.
>
> This basic role tagging would not conflict with current usage, and it
> would not affect current non-role renderings. It would be useful for
> rendering alternatives and branches differently e.g. dashed or dotted.
>
> Worst case, nobody follows and I wil lose a few hours of work. Best case,
> some renderers might think “hey, that’s neat!” and start using the roles.
> Middle case, renderers test it and give useful feedback for a better
> proposal. If this proposal would lead to different roles, I could simply
> alter the roles in the course of regular route maintenance.
>
> Peter Elderson
>
>
> Op vr 28 feb. 2020 om 18:07 schreef Peter Elderson <pelderson at gmail.com>:
>
>> +1 for stating more clearly What to map and What NOT to map.
>>
>> The first goal of the proposal, I think, is to separate the main (linear
>> or circular) route from the extras, for display and some data use (e.g.
>> export, length calculation and elevation profile).
>> Then render the extras as dashed route lines or something, but exclude
>> those from calculations and main export.
>>
>> Best, Peter Elderson
>>
>>
>> Op vr 28 feb. 2020 om 12:29 schreef Andrew Harvey <
>> andrew.harvey4 at gmail.com>:
>>
>>> I agree with Peter, it'll probably be better to start with the basics,
>>> get that approved so at least there is some improvement, then move forward
>>> with the more complicated parts of the proposal.
>>>
>>> In terms of the role names proposed I noticed that it is a very similar
>>> to a schema I came up with for creating hiking routes from OSM data,
>>> https://gitlab.com/beyondtracks/beyondtracks-walks#ways. I have
>>> role=primary (main), sidetrack (excursion), altroute (alternate),
>>> transit_connection (approach) and find this covers most of what you need to
>>> represent.
>>>
>>> Though I think the proposal needs more emphasis that these should only
>>> be mapped if these alternate routes,excursions or approaches are verifiable
>>> on the ground through signage, otherwise it's subjective based on opinion.
>>> It already says "Only add secondary trails to the relation that are really
>>> part of the trail route, not made up or other trail routes." but I think it
>>> needs to be clearer.
>>>
>>> On Fri, 28 Feb 2020 at 21:07, s8evq <s8evqq at runbox.com> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> What is the status of this proposal? Should we go forward and start
>>>> voting?
>>>> Lots of people have added valuable information and insight. It would be
>>>> a pity if this proposal yet again stays in "Draft" status for forever.
>>>>
>>>> On Fri, 6 Dec 2019 10:15:31 +0000, Michael Behrens <
>>>> mfbehrens99 at gmail.com> wrote:
>>>>
>>>> >
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles
>>>> >
>>>> >
>>>> >
>>>> > There is no unique way to tag roles in hiking route relations
>>>> although they
>>>> > carry a high potential for the rendering of hiking trails. This
>>>> proposal
>>>> > was requsted by Sarah Hoffmann on the FOSSGIS conference. A only
>>>> officially
>>>> > marked trails should be added to the relations!
>>>> >
>>>> > Role nameExplaination
>>>> > *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 or alternate Tags the members of an alternative path to
>>>> *main*
>>>> >  path.
>>>> > excursion Can be used on parts of the trail that leads to a
>>>> viewpoint, peak
>>>> > or other. The path has to be hiked back again or else it will be a
>>>> > *alternative*.
>>>> > approach A path that is leading from a town, train station / bus
>>>> station or
>>>> > parking to main hiking trail or the other way around.
>>>> > shortcut A trail that shortens the main trail.
>>>> >
>>>> > Please write comments here:
>>>> >
>>>> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles
>>>> >
>>>> > Greeting
>>>> > Michael
>>>> > _______________________________________________
>>>> > Tagging mailing list
>>>> > Tagging at openstreetmap.org
>>>> > https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tagging mailing list
>>>> Tagging at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> _______________________________________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200304/67923074/attachment-0001.htm>


More information about the Tagging mailing list