On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> 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.
I disagree that a) it is not possible to sort such routes and
b) that sorting doesn't help.
A route that goes like this:
A -> X -> B
<- Y <-
can be put into the relation in order A, X, Y, B or A, Y, X, B.
Or to put it more formally: If you take only ways used to get from
A to B, you should get a linear route. And if you take only ways
that are used to get from B to A, you still get a linear route.
You get a nicely sorted route with one break in there. It's easy
to do in any editor where sorting is easy to do and there is no need
for nested relations.
To convert something like this into a linear geometry, do:
1. Go through relation and reverse all ways as necessary to create a
route with minimal gaps.
2. For each way that is tagged forward/backward you can now determine
from the direction of the way and its role if it is part of A->B
or B->A.
3. Filter all ways that are two-way or marked A->B, line them up and
you have one direction of the route.
4. Rinse and repeat for direction B->A.
Or to put it in other words: you can use exactly the same algorithm
as for linear routes and just add a bit of oneway detection on top.
(I am aware that roundabouts are a special case that should be handled
to spare the mapper splitting of roundabouts. But, again, if the route
is sorted, then detecting this is a piece of cake, even when the
roundabout is split at inconvenient places.)
> 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.
This is not relevant for sorting during processing. Those members are stripped
away first thing. If it bothers you during editing, I have to say that I have
little sympathy as those guideposts don't belong into the relation in the
first place. Use https://wiki.openstreetmap.org/wiki/Relation:destination_sign
instead.
Sarah
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
