On 09/12/19 07:14, Peter Elderson wrote:
Sarah Hoffmann <lon...@denofr.de <mailto:lon...@denofr.de>>:
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?
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
harmonious.
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.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
