<div dir="ltr"><div>Maybe it's the summer heat, or my age, but I still don't get the essential step in both Sarah's and Peter's reasoning.</div><div>Let's assume that for hiking and cycling type relations I do have all component ways in some, generally agreed, -sequence in the database.</div><div>How do I get this information out of the database and converted nto a navigation aid for me as end user?</div><div>I see four basically different options:</div><div>1) a paper map or a sequence of paper maps<br></div><div>2) a road book with turn instructions</div><div>3) a GPX track to follow on a navigation device</div><div>4) real time navigation with turn instructions on a navigation device<br></div><div><br></div><div>All four do not need the sorting of the relation members under the condition that the routing algorithm gives very strong preference those ways that are part of a hiking/biking route relation.</div><div><br></div><div>There is theoretically a fifth option:</div><div>I tell my intelligent navigation device "bring me to route XVZ and guide me along that route in direction N / S / E / W</div><div>But also in that case the sequence of the ways in the route relation seems irrelevant.<br></div><div><br></div><div>I must be missing a crucial point in your reasoning.</div><div><br></div><div>Best regards</div><div><br></div><div>Volker<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 19 Aug 2019 at 13:16, Sarah Hoffmann <<a href="mailto:lonvia@denofr.de">lonvia@denofr.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:<br>
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <<a href="mailto:lonvia@denofr.de" target="_blank">lonvia@denofr.de</a>> wrote:<br>
> <br>
> Assuming we don't care what happens to really botched relations, all cases<br>
> > except one that I listed initially are covered with one single simple<br>
> > instruction to the mapper: sort your route.<br>
> <br>
> I strongly disagree with this advice, at least as far as cycle routes are<br>
> concerned (disclaimer: I have mapped many bicycle route relations)<br>
> Even many run-of-the mill "linear" (A-to-B) routes have the problem that<br>
> the the precise A-to-B route is different form the B-to-A version of the<br>
> "same" route. The reasons are mainly<br>
> <br>
> - roundabouts<br>
> - one-way cycle paths<br>
> - oneway streets without bicycle:oneway=no (frequent in agglomerations,<br>
> the route A-to-B uses different streets from the B-to-A route)<br>
<br>
> At the practical level it is impossible to sort these route relations<br>
> automatically (in JOSM for example) or manually.<br>
<br>
I disagree that a) it is not possible to sort such routes and<br>
b) that sorting doesn't help.<br>
<br>
A route that goes like this:<br>
<br>
A -> X -> B<br>
<- Y <-<br>
<br>
can be put into the relation in order A, X, Y, B or A, Y, X, B.<br>
Or to put it more formally: If you take only ways used to get from<br>
A to B, you should get a linear route. And if you take only ways<br>
that are used to get from B to A, you still get a linear route.<br>
<br>
You get a nicely sorted route with one break in there. It's easy<br>
to do in any editor where sorting is easy to do and there is no need<br>
for nested relations.<br>
<br>
To convert something like this into a linear geometry, do:<br>
<br>
1. Go through relation and reverse all ways as necessary to create a<br>
route with minimal gaps.<br>
2. For each way that is tagged forward/backward you can now determine<br>
from the direction of the way and its role if it is part of A->B<br>
or B->A.<br>
3. Filter all ways that are two-way or marked A->B, line them up and<br>
you have one direction of the route.<br>
4. Rinse and repeat for direction B->A.<br>
<br>
Or to put it in other words: you can use exactly the same algorithm<br>
as for linear routes and just add a bit of oneway detection on top.<br>
<br>
(I am aware that roundabouts are a special case that should be handled<br>
to spare the mapper splitting of roundabouts. But, again, if the route<br>
is sorted, then detecting this is a piece of cake, even when the<br>
roundabout is split at inconvenient places.)<br>
<br>
> Let me also introduce a further complication in the "sorting" discussion<br>
> for hiking and cycling route relations.<br>
> Some mappers like the idea to keep signposts in the same route relation as<br>
> the ways making up the route. This strategy has been adopted in an<br>
> important collaboration between the Italian Alpine Club (CAI) and OSM (in<br>
> Italy represented by WIkimedia Italia). Unfortunately the corresponding<br>
> wiki page <<a href="https://wiki.openstreetmap.org/wiki/CAI" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/CAI</a>> is only available in<br>
> Italian.<br>
<br>
This is not relevant for sorting during processing. Those members are stripped<br>
away first thing. If it bothers you during editing, I have to say that I have<br>
little sympathy as those guideposts don't belong into the relation in the<br>
first place. Use <a href="https://wiki.openstreetmap.org/wiki/Relation:destination_sign" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Relation:destination_sign</a><br>
instead.<br>
<br>
Sarah<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>