Volker Schmidt <vosc...@gmail.com>: > > > On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <lon...@denofr.de> wrote: > > Assuming we don't care what happens to really botched relations, all cases >> except one that I listed initially are covered with one single simple >> instruction to the mapper: sort your route. >> > > I strongly disagree with this advice, at least as far as cycle routes are > concerned (disclaimer: I have mapped many bicycle route relations) > Even many run-of-the mill "linear" (A-to-B) routes have the problem that > the the precise A-to-B route is different form the B-to-A version of the > "same" route. The reasons are mainly > > - roundabouts > - one-way cycle paths > - oneway streets without bicycle:oneway=no (frequent in > agglomerations, the route A-to-B uses different streets from the B-to-A > route) > > At the practical level it is impossible to sort these route relations > automatically (in JOSM for example) or manually. > The only clean solution for these cases would be separate A-to-B an B-to-A > route relations for the same linear bicycle route. >
Either that, or have extraction routines readily available to filter by role and return one linear sorted route, so you can request e.g. gimme the forward route. For hiking routes, roles are not necessary, it's easiest to make a linear main route relation and separate alternatives. Using roles for alternatives as a storing method is fine with me, but again: it should come with an extraction method that allows filtering and adequate sorting. If that's not available, which it isn't, mappers need to order the data itself to get the required output. > Apart from the enormous additional work, this does not solve the case of > branched routes, for example. > Keeping linear main route and alteratives separate is actually quite straightforward and much less work than creating and maintaining routes with roles. Especially when the forward/backward roles do not indicate the direction of travel, as is the case with bicycle routes. > And I still do not see the benefit of having sorted cycling (an hiking) > relations. I have planned hundreds of cycling tours, which often run along > cycle routes, and have not yet come across a single case, where I would > have needed a sorted list of the ways in the relation. I use rout planners > that visualize cycling routes, and that's it. > The point of route relations is that they are already routed, i.e. they prescribe exacty what ways to travel. They are not suggestions for routing. Of course, if there are problems, you can try to make up for that using routng techniques, but you should not turn that around and say hey, I am routing anyway, so forget the data issues. The idea is to record exactly how to travel, so people can travel along the path without rerouting. Just take a way, then the next, etc until the end. These are not suggestions, it's a prescribed route to follow, as seen on the road because it's signposted/waymarked. > Let me also introduce a further complication in the "sorting" discussion > for hiking and cycling route relations. > Some mappers like the idea to keep signposts in the same route relation as > the ways making up the route. This strategy has been adopted in an > important collaboration between the Italian Alpine Club (CAI) and OSM (in > Italy represented by WIkimedia Italia). Unfortunately the corresponding > wiki page <https://wiki.openstreetmap.org/wiki/CAI> is only available in > Italian. > I have done some minor work in that direction on one or two cycle route > relations, where I was involved in placing the signposts and for that > reason had direct access at the position data. > > Volker > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
