[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Sarah Hoffmann lonvia at denofr.de
Fri Dec 6 22:29:51 UTC 2019

On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote:
> Andy Townsend <ajt1047 at gmail.com>:
> > Michael Behrens:
> >
> >
> > There is no unique way to tag roles in hiking route relations
> >
> > I'd suggest making it clear that that table is currently for way members
> > only - it doesn't mention node members (start, end, marker, etc.).  This
> > may be deliberate, or you just haven't expanded it yet, but I'd definitely
> > mention node members.
> >
> >  Also, 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.
> It seems to me that use of these roles leads to relations containing
> non-contiguous trails. I would call those relations collections rather than
> routes. Processing non-contiguous routes presents extra challenges for
> processing such as exporting routes and making elevation profiles.

I have to strongly disagree with all of that.

1. Having alternatives and excursions does not make a route non-contiguous.
   It just makes it non-linear.
2. It is perfectly normal for a route to be non-linear. If the alternative
   route is marked, it's part of the route and should be mapped accordingly.
3. Non-linear routes are not a problem for processing per-se.

The point about the processing you have now made repeatedly in different
contexts. You seem to have come to this conclusion because waymarkedtrails
does not implement non-linear routes. As much as it honors me that you
consider waymarkedtrails the gold standard for what is doable with route
relations, I have to disappoint you here. Non-linear routes are simply not
implemented because of lack of time.

If I'd have to state a rule what makes processing easier then it would be:
avoid subrelations unless the relation is so large that it is a pain to
handle in the editor.

Kind regards


More information about the Tagging mailing list