[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles
61sundowner at gmail.com
Sun Dec 8 21:36:54 UTC 2019
On 09/12/19 07:14, Peter Elderson wrote:
> Sarah Hoffmann <lonvia at denofr.de <mailto:lonvia at denofr.de>>:
> The point about the processing you have now made repeatedly in
> contexts. You seem to have come to this conclusion because
> does not implement non-linear routes. As much as it honors me that you
> consider waymarkedtrails the gold standard for what is doable with
> 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?
I believe the intention is to make it possible to resolve issues with
routes. At the moment the roles in routes are not documented nor
Thrashing out the various roles here helps lots to combine thoughts.
> 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.
Lucky you in only having 3 days to deal with. There are routes of 3+
months. Thousands of kilometres.
> 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.
For me these roles could be used for both ways and relations. However
some roles do not make sense for relations .. eg forwards/backwards ..
the ways in those relations should have any forwards/backwards applied
there, not on the entire relation.
Why? The ways in the relation may have different directions. Someone
could edit a way or add a new way with a different direction. It is the
individual ways that have the direction, not the entire relation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging