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. Let's assume that for hiking and cycling type relations I do have all component ways in some, generally agreed, -sequence in the database. How do I get this information out of the database and converted nto a navigation aid for me as end user? I see four basically different options: 1) a paper map or a sequence of paper maps 2) a road book with turn instructions 3) a GPX track to follow on a navigation device 4) real time navigation with turn instructions on a navigation device
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. There is theoretically a fifth option: I tell my intelligent navigation device "bring me to route XVZ and guide me along that route in direction N / S / E / W But also in that case the sequence of the ways in the route relation seems irrelevant. I must be missing a crucial point in your reasoning. Best regards Volker On Mon, 19 Aug 2019 at 13:16, Sarah Hoffmann <lon...@denofr.de> wrote: > 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 >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
