[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Peter Elderson pelderson at gmail.com
Sun Dec 8 20:14:00 UTC 2019


Sarah Hoffmann <lonvia at denofr.de>:

> On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote:
> > 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.
>

You are right, I used the wrong word. Non-linear. In practice most long
routes I work with also have gaps, in addition to branches, shortcuts,
extra loops, alternatives, full length variants, variants of variants and
completely separated variants e.g. island loops which are seen as part of a
longer route or collection. In addition, local routes are often part of
regional routes, (parts of) regional routes are sections of national
routes, and (part of) the main route of a national route is the national
section of an international route which can have completely separated
alternatives.


> 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.
>

Of course. But it's not always clear what "the route" is! We (Nederland)
have routes consisting of several sections carrying their own trail names.
Sometimes people know them by their collective name, sometimes only the
separate names of the section paths. Many separate routes have identical
waymarking, and most of the waymarks carry no path name, so that does not
help.


> 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.
>

I'll take your word for that, but I do not see it yet! The proposal says
it's on your request, so considering the processing by waymarkedtrails
seems appropriate. Is that what the requested roles are intended for, if
you can find the time? Or do you mean processing of non-linear routes
without special roles? Can this result in exports usable for navigating by
OsmAnd, Garmin and the like? Will it solve your discontinuous profile issue
for non-linear routes?



> 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.
>

The wiki about that says over 300 ways. I agree. More is not immediately
fatal, but from 300 on maintenance effort increases significantly because
errors (chain breaks and sorting errors) by other editors will happen more
often, are more difficult to track, and sorting functions do not handle
these errors well. Non-linearity also frustrates sorting and maintenance.

The main route of nearly all route relations I regularly maintain are far
more than 300 members in total. So they will be split into parts conform
the wiki. Of course there is no special relation type "sub-relation", that
just means it's a route-in-a-route. Variants can be short or long, the
longer ones can e.g. consist of 3 day's walking, which merits one ore more
separate route relations for the variant. Variants and main route are then
assembled in a route relation of type route or sometimes superroute.
I assumed handling this is accepted practice and will continue to happen.

The question at hand is, should the proposed roles be applicable only to
ways, or also to other elements in the route relations? If so, the proposal
should state that, I think, and also what exactly it means, e.g. what
exactly does forward mean for a (sub)relation element, and whether a
particular sorting order is required.

_______________________________________________
> 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/20191208/ffad56fc/attachment-0001.html>


More information about the Tagging mailing list