[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Peter Elderson pelderson at gmail.com
Wed Mar 4 21:00:46 UTC 2020


I agree with most things you say, Kevin. But it's not my proposal!

I don't really care about the purpose or exact value of a variant, just
that it ibelongs to the route but is not the main route and that values are
unambiguous. But I don't want to undercut the proposal.

I suggested "branch" for all extra's, including PT approaches, shelter
spurs, loops, excursions, shortcuts, waymarked seasonal variants, dog
variants, waymarked detours, connections etcetera, but most people seemed
to agree with the proposed values. spur would also be fine with me, but was
not suggested/discussed or did not make it to the proposal.

Anyway, I roletagged a few examples with the basic clearcut role values, to
A. determine workability and time consumption, and B. provide real trails
for a trial by data users and renderers. Would be nice to add a few  more
challenging and complex trails, see if these can be roletagged as simple as
the Dutch ones, to simply enable separation of the main route for export,
elevation profile and length calculations, and extra's for slightly
different rendering.

Maybe someone could try basic roletagging of ways. I will not do that,
because it would take much more time, maintenance and tooling. I don't
foresee mappers in Nederland to do it that way, but in other countries
putting everything in one big relation is more common.

Best, Peter Elderson


Op wo 4 mrt. 2020 om 15:58 schreef Kevin Kenny <kevin.b.kenny at gmail.com>:

> I certainly agree in principle that having a notation for loops, spurs
> and alternatives would be a step forward in mapping hiking routes. I
> don't see any particular advantage in having the role identify the
> specific purpose of the secondary trail, except that hikers will care
> whether or not a side route that returns to the trail is a formal
> alternative. A bad-weather shortcut that bypasses a summit is NOT an
> acceptable alternative unless the main trail is closed!
>
> I think I mentioned earlier that 'spur' would be a useful generic term
> for 'side trail that does not return to the main trail'. 'Spur' would
> work well for approaches, since 'main trail or any loop or spur off
> it, that intersects a motor road/arrives at a trailhead' (you and I
> appear to have different working definitions of 'trailhead') would be
> an adequate query to represent 'where can I start a trip near here?'
> 'Spur' also works well for out-and-back side trails to shelters,
> viewpoints, privies, water sources, or whatever.
>
> That would leave only the loops, with 'alternative' being a cognizable
> alternative for having 'completed' the trail, while 'excursion' is
> simply a loop that wanders off the main trail for another purpose and
> doesn't count for hiking it. I think users _will_ want that
> information, and alas, the role is the only good place to encode it.
>
> Since JOSM and the other tools already deal with loops, spurs, links
> and alternatives in road routes, I would imagine that upgrading them
> to whatever is needed for trails would at least be possible without
> any major software redesigns.
>
> It would be quite a while before I'd map them, but specific examples
> that I'd be likely to curate, in whole or in part:
>
> The Appalachian Trail has many loops and spurs associated with it -
> for a variety of purposes, anything from access to a shelter or privy,
> to a lovely view, a bad-weather bypass, or, of course, an approach
> from a trailhead. The convention in several states is to blaze the
> main trail with white paint and the secondary trails with blue.
>
> The Long Trail (Vermont) has a documented set of approach trails (and
> even a 'side to side' award for hiking them all, complementary to the
> 'end to end' award!). Many of the side trails are mapped, but they are
> not associated with the route in the data model. (For these, I'd use
> some sort of Long Trail-specific tagging on the ways as well as
> including them in the relation.)
>
> The Long Path (New York/New Jersey) has a documented bypass that
> avoids road walking (follow the Appalachian Trail to High Point, New
> Jersey, and then the Shawangunk Ridge Trail north to rejoin the Long
> Path near Otisville, New York). The trail is mostly mapped (sorry
> about Schoharie County; it needs field work and life keeps getting in
> the way) but the bypass is not included. The trails that the bypass
> follows are also mapped, so the hiker has something to follow. The
> Long Path is already a super-relation because the large number of
> segments and the handful of remaining discontinuities made it tough to
> manage otherwise. (I chose to divide it by county, which fortuitously
> broke it into eleven nearly equal sections.)
>
> Neither the Long Path nor the Long Trail has formally recognized
> alternatives for high water, fire or severe weather. Some other long
> trails in the US do. (Some even have simple alternative routes that
> the hiker is free to choose among.)
>
> Here in the Northeastern US, a great many 'approach trails' are
> individually named trails, and with the exception of the ones that I
> mention for the Long Path, I probably would NOT bother with adding
> them to the relation for the main-stem trail.  For instance, if you
> look at the Devil's Path
> (https://www.openstreetmap.org/relation/5461814), you'll see approach
> trails, from east to west, named Overlook Turnpike, Jimmy Dolan Notch
> Trail, Pecoy Notch Trail, Roaring Kill Trail, Mink Hollow Bicycle
> Trail, Warner Creek Trail, and so on. Any of these is a useful access
> way if you want to do a day trip on a piece of the Devil's Path, but
> none has any formal association with it. I think that the 'approach'
> role should be reserved for trails that either are officially
> recognized or marked as approaching the main trail, or at least that
> lack another identity of their own. I've hiked on the Overlook
> Turnpike on a leisurely trip to Echo Lake, with no intention at all of
> doing any portion of the Devil's Path on that trip!
>
> All of the given trails join with many secondary trails, and with
> other main trails (the Long Path connects to at least the Appalachian,
> Finger Lakes and Northville-Placid Trails, for instance.)
>
> On Wed, Mar 4, 2020 at 2:28 AM Peter Elderson <pelderson at gmail.com> wrote:
> >
> > 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
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> --
> 73 de ke9tv/2, Kevin
>
> _______________________________________________
> 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/8f6852c8/attachment-0001.htm>


More information about the Tagging mailing list