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

Volker Schmidt voschix at gmail.com
Mon Aug 19 12:42:54 UTC 2019

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

I must be missing a crucial point in your reasoning.

Best regards


On Mon, 19 Aug 2019 at 13:16, Sarah Hoffmann <lonvia at 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 <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.
> 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 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/63dea924/attachment.html>

More information about the Tagging mailing list