[Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

Volker Schmidt <voschix at gmail.com>:

>
>
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <lonvia at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190819/0f4600e1/attachment.html>