Sarah Hoffmann <lon...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging