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

classic Classic list List threaded Threaded
90 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
Kevin Kenny <[hidden email]>:

On Sun, Aug 18, 2019 at 3:31 PM Peter Elderson <[hidden email]> wrote:
I'm afraid testing is all I can offer. I could list problems to detect, but I think I would not be telling you news. Very important: handle nested relations (hierarchies). RA currently does not.

Uhm, yeah, that's a problem. For what it's worth, Waymarked Trails
seems to have a much better route assembler. It copes with
https://hiking.waymarkedtrails.org/#route?id=919642, which definitely
has lacunae (because I never seem to have time to get to Schoharie
County to get the data to close the gaps).


It is quite clever! Its explained here: https://hiking.waymarkedtrails.org/help/rendering/hierarchies

It’s easy to spot if a route is broken: the map usually will be not that bad, but the elevation profile will tell you and show you. If it’s badly broken, it usually requires lots of JOSM before you can use it for export to a gps app or device, or import into a route editor or trip planner for waymarked/signposted routes.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Sarah Hoffmann
In reply to this post by Richard Fairhurst
On Sun, Aug 18, 2019 at 09:25:01AM -0700, Richard Fairhurst wrote:
> But just as long established in OSM is the principle that - since mappers
> are our most precious resource - we optimise for the mapper, not for ease of
> consumption. Allowing relations to be unsorted is an example of that. If a
> relation represents a linear route, it's a SMOP to put the ways in the right
> order.

Sure, we are not talking about the 80% linear routes (of which less than a
quarter is unsorted btw, so it doesn't seem to be a too difficult thing to
do for the mapper.) Happy to processed them in any order.

We are talking about routes which are non-linear by design (split direction,
alternatives, accesses, circular, self-intersecting), broken relations,
unfinished relations, directed routes (think MTB downhill) and truely
botched relations.

> There are two obvious strategies. 1 is: create an empty polyline P with
> endpoints P1 and P2; iterate through the relation members; every time you
> encounter a way with an endpoint P1 or P2, add it to the polyline
> (potentially in reverse order) and remove it from consideration; repeat
> until there are no ways left. This is broadly the approach I've used until
> now.
>
> 2 is more involved but more fault-tolerant and flexible; create a routing
> graph, then route from the relation's startpoint to its endpoint using a
> very heavy uplift for members of this relation. This is a useful approach
> where the route actually _is_ non-contiguous but you nonetheless want to
> include connecting routes between the sections. (Quite a lot of American
> rail-trails are like this, as are several UK National Cycle Network routes.)
> This is an approach I'm investigating at present.

I have experimented quite extensively with using routing algorithms for the
relation assembly. Even determining a start and endpoint of the relation is
already messy. There are corner cases everywhere. Example: a relation with
exactly two open ends should be an open and shut case, right? Wrong! It might
also be a circular route with two access ways.

Any sorting suggestion that either starts with "Step 1: install a planet-
wide OSRM with a foot profile" or involves a complicate algorithm that makes
a lot of undocumented assumptions about the relations cannot be in the
interest of OSM.

The first hinders the use of our data. You shouldn't need be able to afford a
2000$ server just to assemble a couple of routes.

The second makes life harder for mappers because it becomes non-obvious how
they can fix their stuff when it breaks in their favourite software. And
worse, even if they fix it for one, it might acutally breaks the other software
which is working on different assumptions.

We do happen to have a clear rule for unbroken linear routes: just assemble
in the obvious way, no matter if sorted or unsorted. We don't have any rule
for anything more complicated that mappers can follow to get the desired
effect. We already fail with something as simple as a directed unbroken
linear routes and circular routes. There is no single recommended way to
define the start point.

 
> Approach 1 does of course fail if the relation doesn't represent a single
> linear route. That would, however, still be true if the route was ordered.

With sorted routes, your approach 1 becomes quite a bit simpler: just take
ways in order, adapt direction so that the gaps are minimal. Assemble.

That algorithm gives you reasonable results for the following cases
automatically: linear, broken, unfinished, circular and self-intersecting
routes.

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.
                                 
What remains are routes which are split/have alternatives/access routes etc.
Gut feeling tells that roles will solve those cases but I get back to you
on that once I had a go at implementing it.

Sarah

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

voschix
In reply to this post by Richard Fairhurst


On Sun, 18 Aug 2019 at 18:26, Richard Fairhurst <[hidden email]> wrote:
I'd fully agree on roles. The use of 'alternate' and 'forward'/'reverse'
roles for bike route relations dates back to the earliest days of bike route
mapping in OSM and is well established by now.
I suppose this is a typo:
It should be 'forward'/'backward' and not  'forward'/'reverse'
(see the wiki page: Cycle Routes:
"Relation role: Cycle routes sometimes have different paths depending on the direction you are travelling. In this case, ways in the relation should have a role of forward or backward as described in Relation:route#Members. The direction is rendered on the cycle map (example)")

Volker


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

voschix
In reply to this post by Sarah Hoffmann


On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <[hidden email]> 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.
Apart from the enormous additional work, this does not solve the case of branched routes, for example.
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.

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 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
Volker Schmidt <[hidden email]>:


On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <[hidden email]> 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 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Sarah Hoffmann
In reply to this post by voschix
On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:

> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Signposts in Roles of route members

Warin
In reply to this post by voschix
On 19/08/19 18:50, Volker Schmidt wrote:

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 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.


As these may be in any order???
Then group them together or not. Accept them in a separate relation if wanted. And have them with a suitable role that users can ignore or use as they like.
The same with any other POI like log books etc.

Those who like sequential order in the routes can then place them all at the bottom and deal with the ways as they please.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

voschix
In reply to this post by Sarah Hoffmann
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 <[hidden email]> wrote:
On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Forward/backward routes

Kevin Kenny-3
In reply to this post by Peter Elderson
On Mon, Aug 19, 2019 at 6:34 AM Peter Elderson <[hidden email]> wrote:
> 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.

The 'forward' and 'backward' roles are well defined. At least two
editors that I've used understand them. JOSM appears to sort them
correctly. (It does stumble a bit in the special case where a
route=road ends at junction among dual carriageways, because it cannot
find a single endpoint.)  We seem to have this problem mostly solved.

I disagree with the 'much less work' when you're maintaining a route
that's hundreds of km long, follows dedicated trails or rural roads
most of the way, but once in a while enters a city and splits because
of one-way streets. Maintaining separate 'forward' and 'backward'
relations for the whole thing would be quite annoying.

> 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.

Right. Structuring the route in that form also allows software to
produce the skeleton of the route book.  I started with the output of
a PostgreSQL query when I wrote the initial draft of
http://www.nptrail.org/trip-planning/section-descriptions-and-mileages/
(I found several gross errors in the 'official' route book that way:
there was one segment that was shown as 1700 m shorter than its actual
length, for instance).

--
73 de ke9tv/2, Kevin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
In reply to this post by voschix
You can't seem to let go of your routing. The routes in OSM represent routes that are already there. They are sequences of ways to follow in the order given, not sequences of points to route to.

Ideally, you should not have to create gpx-s from them and you should need no ordering or routing at all, because they ARE the routes. An app or gps-device should use them as is, just tell the user what to do next. Since no app currently does that (future still has to arrive) we resort to transferring the route to them as tracks, i.e. gpx.
Exporting as a gpx loses the way information. THEN you need rerouting, to turn them back into a chain of censecutive ways to follow. 

The rerouting should return exactly the original route. Of course this only works when the routing software uses exactly the same map, i.e. knows exactly all the ways used to create the transport gpx-file. 

Some imperfections in various stages can be helped by routing. his means you get a route over a gap, but you can't be sure it will be the waymarked OSM-route as it is found on the road. Routing along with planning is a big help in trip planning, but it should not touch the route itself. 

So, it's not all about getting there. It's about doing the way. As hikers use to say, the way is the goal. Very Tao.

Fr gr Peter Elderson


Op ma 19 aug. 2019 om 14:46 schreef Volker Schmidt <[hidden email]>:
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 <[hidden email]> wrote:
On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Forward/backward routes

Paul Johnson-3
In reply to this post by Kevin Kenny-3


On Mon, Aug 19, 2019, 08:20 Kevin Kenny <[hidden email]> wrote:
On Mon, Aug 19, 2019 at 6:34 AM Peter Elderson <[hidden email]> wrote:
> 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.

The 'forward' and 'backward' roles are well defined. At least two
editors that I've used understand them. JOSM appears to sort them
correctly. (It does stumble a bit in the special case where a
route=road ends at junction among dual carriageways, because it cannot
find a single endpoint.)  We seem to have this problem mostly solved.

I disagree with the 'much less work' when you're maintaining a route
that's hundreds of km long, follows dedicated trails or rural roads
most of the way, but once in a while enters a city and splits because
of one-way streets. Maintaining separate 'forward' and 'backward'
relations for the whole thing would be quite annoying.

Depends.  I prefer to split to separate forward and backward relations when the number of members gets to be extremely large or when either or both ends of a route is not single carriageway, because it gets to be a real pain in the butt to validate and maintain otherwise.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Richard Fairhurst
In reply to this post by Sarah Hoffmann
On mobile, on train, apologies for lack of formatting. :)

Sarah - the problem is that when you say “one single simple
instruction to the mapper: sort your route“, the instruction might be simple
but carrying it out isn’t.

Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
section to an existing route. As Peter says, doing this to said
specification “usually requires lots of JOSM”. The steps involved to do this
in sorted order are:

1. spend half the afternoon trudging through contradictory pages on the OSM
wiki to find out what you have to do
2. apparently it involves this thing called “JOSM”. Download that
3. apparently that involves this thing called “Java”. Download that too
4. learn to use this 80s throwback of a GIS program with the UI of a
startled warthog
5. find route sorting stuff in JOSM somewhere
6. make edit
7. get shouted at by sociopaths in changeset comments because unwittingly
you did something wrong

(I have elided most of the intermediate steps.)

That isn’t how OSM works. It might be how Wikipedia works but we are better
than that.

_If_ route ordering is to be expected, then the burden needs to be on the
editing software, not the mapper. That means invisible support in iD, P2,
and I’m guessing Vespucci and Go Map (I don’t know what their current
support is like). And tbh the burden of providing patches is on the few
people who are asking for it. Certainly I’m happy to implement something in
P2 if it’s an afternoon’s work and I’m given a fully fleshed out algorithm
which copes with the partly loaded relations that are standard for an online
editor, but I’m not going to spend two days of dev time on something for
which there is no great clamour outwith a couple of people on the tagging
list.

cheers
Richard




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
On Mon, 19 Aug 2019 at 16:02, Richard Fairhurst <[hidden email]> wrote:

Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
section to an existing route. As Peter says, doing this to said
specification “usually requires lots of JOSM”. The steps involved to do this
in sorted order are:

1. spend half the afternoon trudging through contradictory pages on the OSM
wiki to find out what you have to do
2. apparently it involves this thing called “JOSM”. Download that
3. apparently that involves this thing called “Java”. Download that too
4. learn to use this 80s throwback of a GIS program with the UI of a
startled warthog
5. find route sorting stuff in JOSM somewhere
6. make edit
7. get shouted at by sociopaths in changeset comments because unwittingly
you did something wrong

(I have elided most of the intermediate steps.)

It's that easy?  Last time I did it, it seemed a lot harder than that.

And say what you like about Warthogs being ugly, the Fairchild Republic A-10
Thunderbolt II (aka Warthog) was a very effective war plane, both in kill power and
survivability.  Please don't make JOSM's UI seem better than it is by comparing it
to the Warthog.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Kevin Kenny-3
In reply to this post by Richard Fairhurst
On Mon, Aug 19, 2019 at 11:02 AM Richard Fairhurst <[hidden email]> wrote:

> Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
> section to an existing route. As Peter says, doing this to said
> specification “usually requires lots of JOSM”. The steps involved to do this
> in sorted order are:
>
> 1. spend half the afternoon trudging through contradictory pages on the OSM
> wiki to find out what you have to do
> 2. apparently it involves this thing called “JOSM”. Download that
> 3. apparently that involves this thing called “Java”. Download that too
> 4. learn to use this 80s throwback of a GIS program with the UI of a
> startled warthog
> 5. find route sorting stuff in JOSM somewhere
> 6. make edit
> 7. get shouted at by sociopaths in changeset comments because unwittingly
> you did something wrong

I'd much rather that the novice's task be:

1. Map the ways making up the new section of the route.
2. If you or your editor can't handle route relations of the
complexity that you encounter, don't worry about it. Either flag the
changeset for review or leave an OSM note indicating that the work is
undone.
3. Someone in the community who can handle relations will then have
the geometry already established, so tidying the topology becomes a
clerical task.

Of course, this depends on the solution to step (7) above, for which I
have no good answer.

I have absolutely no problem with tidying a route anywhere within a
hundred miles of my home base if a mapper can explain to me in words
what's in the field, and has created ways so that I have the geometry.
There aren't *that* many routes out there. I understand that route
relations can be complex, and there's no need for everyone to be able
to edit them. If we are a global collaborative community, can't we act
like one and admit that there may be cases that require specialists to
manage? (By the way, the "explain in words" may be a sticking point.
There seem to be a lot of people who want to give me a bucket of data
without explanation, and think that the data speak for themselves.)

There's also something to be said for using the ugly editors to prove
the concept, because at this point, we don't yet know how to do
everything, much less how to make it novice-friendly! The exception is
simple linear routes, and Sarah or I can give you algorithms - or at
least heuristics - for maintaining sort order on those. But we're
perfectly happy to consume those unsorted, precisely because we do
know how to automate cleaning them up.

I do want editors minimally to observe the 'don't break the route'
principle. About 80% of the broken-route problem can be solved simply
by, "when splitting a way, both the pieces become members of any route
relations in which the original way appeared, with the same role if
one is specified, preferably preserving continuity if either or both
endpoints was shared with the neighbouring way in the relation." At
least iD, Meerkartor and JOSM all do that. (It means downloading the
two neighbouring ways. This doesn't appear to be a problem for iD).
It's a purely local check, not requiring full analysis of the route.
I'm willing to delegate all the more complex stuff to a specialist
editor.

For what it's worth, I think that the "route editing is complex"
problem partly drives the 'startled warthog' and '1980s throwback'
issues. In my experience, newer and prettier UI's try so very hard to
be pretty and novice-friendly that in many cases, they simply reach a
ceiling of complexity beyond which they can't cope or become an
obstacle to the power user. (I'm looking at *you*, LabView!)  Beyond
that point, "ugly but serviceable" starts looking a lot more like the
ideal approach. I'm not saying that any OSM editor falls in this
category, but I've used far too many applications where the UI
designer ruled, and the thing I want to do becomes impossible because
the designer couldn't figure out a way to make it attractive enough.
(I've even had the misfortune of developing applications in that sort
of political environment. They were less than 100% successful.) Of
course, I write this as a grumpy old man, so take my comment as senile
raving if you wish.

--
73 de ke9tv/2, Kevin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Kevin Kenny-3
In reply to this post by Paul Allen
On Mon, Aug 19, 2019 at 11:10 AM Paul Allen <[hidden email]> wrote:
> And say what you like about Warthogs being ugly, the Fairchild Republic A-10
> Thunderbolt II (aka Warthog) was a very effective war plane, both in kill power and
> survivability.  Please don't make JOSM's UI seem better than it is by comparing it
> to the Warthog.

If we're talking about the aircraft, you're right that the A-10 is an
amazing aircraft; even now, the USAF doesn't have anything that does
its mission nearly as well as it does. (Of course, close air support
isn't nearly glamourous enough for the flyboys. The Army would love to
take over the A-10 or develop a successor, but isn't allowed
fixed-wing aircraft in its ambit.)

If we're talking about the beast, beauty is in the eye of the
beholder. Gentlemen warthogs appear to find lady warthogs quite
attractive, since there seems still to be no shortage of warthog
piglets.
--
73 de ke9tv/2, Kevin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
In reply to this post by Richard Fairhurst
Richard Fairhurst <[hidden email]>:
On mobile, on train, apologies for lack of formatting. :)

Sarah - the problem is that when you say “one single simple
instruction to the mapper: sort your route“, the instruction might be simple
but carrying it out isn’t.

Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
section to an existing route. As Peter says, doing this to said
specification “usually requires lots of JOSM”.

That was about repairing a broken and corrupted route relation.
 
The steps involved to do this
in sorted order are:

1. spend half the afternoon trudging through contradictory pages on the OSM
wiki to find out what you have to do
2. apparently it involves this thing called “JOSM”. Download that
3. apparently that involves this thing called “Java”. Download that too
4. learn to use this 80s throwback of a GIS program with the UI of a
startled warthog
5. find route sorting stuff in JOSM somewhere
6. make edit
7. get shouted at by sociopaths in changeset comments because unwittingly
you did something wrong

You simply can't do enough without JOSM if you really want to maintain routes. Other method are not up to the task. Entering en new section is easy. Yes, you have to set up and learn the editor and learn about routes and relations. If you don't want to do that, you can't do it. It should be easier - but it isn't. Smartphone apps will not do.
 
(I have elided most of the intermediate steps.)

That isn’t how OSM works. It might be how Wikipedia works but we are better
than that.

No we are not. OSM is very primitive, chaotic and unreliable. If things were better, simple edits would not be allowed to break relations.
 
_If_ route ordering is to be expected, then the burden needs to be on the
editing software, not the mapper. That means invisible support in iD, P2,
and I’m guessing Vespucci and Go Map (I don’t know what their current
support is like). And tbh the burden of providing patches is on the few
people who are asking for it. Certainly I’m happy to implement something in
P2 if it’s an afternoon’s work and I’m given a fully fleshed out algorithm
which copes with the partly loaded relations that are standard for an online
editor, but I’m not going to spend two days of dev time on something for
which there is no great clamour outwith a couple of people on the tagging
list. 

If nobody has a better way and people who say they have solutions do not provide that knowledge in a usable form e.g. an extraction method or linking method that solves the problems, the only way for the likes of me is to use detection tools and maintenance tools to order data by hand at the mapping level, so ordinary people can use waymarkedtrails to get usable linear gpx-s for their basecamps, route editors, trip planners, navigation apps and devices. 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Andy Townsend
On 19/08/2019 17:21, Peter Elderson wrote:
 the only way for the likes of me is to use detection tools and maintenance tools to order data by hand at the mapping level, so ordinary people can use waymarkedtrails to get usable linear gpx-s for their basecamps, route editors, trip planners, navigation apps and devices.

You keep perpetrating this myth - you're suggesting again that ways in routes need to be sorted before they can be used in Garmin software and navigation devices.  It simply isn't true.  For about 11 years now I've been creating Garmin maps based on OSM data, and I've been walking along local and national trails in the UK for far longer.  Never have I needed to "follow a GPX" - it seems a very alien thing to want to do, and (as mentioned previously) isn't actually supported by any of the various Garmin hiking GPSs that I've used.  If you want to do that - fine - but not everyone does.

I suspect that "Ordinary people" will just download OSM maps from http://garmin.openstreetmap.nl/or one of the alternatives - they'll see the route on-screen and they will navigate using that.  Sometimes they'll stray from it because they've arranged somewhere to eat or stay; they're not limited to "only walking along the actual ways that form the official route" which you seem to be.

If you have a different requirement then that's very much a personal requirement for you; please don't try and dissuade "ordinary people" from contributing to mapping hiking routes.  If you want to manually sort and rearrange hiking route data in a way that doesn't prevent everyone else from contributing that's also fine, but please don't raise the bar to contributions so high that people can't contribute at all. You'd essentially be filling the role that Kevin Kenny identified above as "Someone in the community who can handle relations will then have the geometry already established, so tidying the topology becomes a clerical task".

The people we want adding hiking routes to OSM are people who've just taken their boots off, know where routes have been diverted, and know what the surface tags etc. should be, not people who've never emerged from behind a PC.

Best Regards,

Andy


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Signposts in Roles of route members

Andy Townsend
In reply to this post by voschix
On 19/08/2019 09:50, Volker Schmidt wrote:
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.

By way of example, here's one near me:

https://www.openstreetmap.org/relation/370667

The method for mapping the signposts is not quite the same as the CAI page.  Signposts are mapped as either guidepost (see e.g. https://www.openstreetmap.org/node/5894712185 ) or route_marker ( https://www.openstreetmap.org/node/5734015420 ) depending on what form the route marker takes.  Each has the role "marker" within the relation. 

Best Regards,

Andy



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Jo-2
In reply to this post by Andy Townsend
OK, I have fixed my fair share of route relations, both public transport and bicycle and foot routes.

I find it easier to EDIT them, when they are sorted. To figure out there are problems with them, when they are sorted. JOSM actually does a great job with the sorting. For bicycle, foot and horse route relations it can handle forward/backward roles very well, when they branch.

I've been developing PT_Assistant for the parts that are missing in JOSM. It now comes with routing helper functionality, which works for bicycle routes too since this summer.

Instead of having to manually select, split, deselect not needed part of ways manually, you can simply direct it by pressing numbers, which correspond to segments rendered in different colours. It would be wonderful if that could be implemented in iD as well. No need to know much about the underlying relations. If you know the itinerary you want to add, you're good to go.

It takes into account oneway traffice and turn restrictions for the mode of transport of the route relation you are editing. So it behaves differently when you are closing gaps in bus route relations than when you're doing the same for bicycle route relations.

It still requires lots of JOSM atm. I'll give a demo/workshop of how it works during SotM in Heidelberg. In the mean time I'm creating videos on Youtube.


Polyglot 

On Mon, Aug 19, 2019 at 6:57 PM Andy Townsend <[hidden email]> wrote:
On 19/08/2019 17:21, Peter Elderson wrote:
 the only way for the likes of me is to use detection tools and maintenance tools to order data by hand at the mapping level, so ordinary people can use waymarkedtrails to get usable linear gpx-s for their basecamps, route editors, trip planners, navigation apps and devices.

You keep perpetrating this myth - you're suggesting again that ways in routes need to be sorted before they can be used in Garmin software and navigation devices.  It simply isn't true.  For about 11 years now I've been creating Garmin maps based on OSM data, and I've been walking along local and national trails in the UK for far longer.  Never have I needed to "follow a GPX" - it seems a very alien thing to want to do, and (as mentioned previously) isn't actually supported by any of the various Garmin hiking GPSs that I've used.  If you want to do that - fine - but not everyone does.

I suspect that "Ordinary people" will just download OSM maps from http://garmin.openstreetmap.nl/or one of the alternatives - they'll see the route on-screen and they will navigate using that.  Sometimes they'll stray from it because they've arranged somewhere to eat or stay; they're not limited to "only walking along the actual ways that form the official route" which you seem to be.

If you have a different requirement then that's very much a personal requirement for you; please don't try and dissuade "ordinary people" from contributing to mapping hiking routes.  If you want to manually sort and rearrange hiking route data in a way that doesn't prevent everyone else from contributing that's also fine, but please don't raise the bar to contributions so high that people can't contribute at all. You'd essentially be filling the role that Kevin Kenny identified above as "Someone in the community who can handle relations will then have the geometry already established, so tidying the topology becomes a clerical task".

The people we want adding hiking routes to OSM are people who've just taken their boots off, know where routes have been diverted, and know what the surface tags etc. should be, not people who've never emerged from behind a PC.

Best Regards,

Andy

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
In reply to this post by Andy Townsend
Andy Townsend <[hidden email]>:
On 19/08/2019 17:21, Peter Elderson wrote:
 the only way for the likes of me is to use detection tools and maintenance tools to order data by hand at the mapping level, so ordinary people can use waymarkedtrails to get usable linear gpx-s for their basecamps, route editors, trip planners, navigation apps and devices.

You keep perpetrating this myth - you're suggesting again that ways in routes need to be sorted before they can be used in Garmin software and navigation devices.  It simply isn't true.  For about 11 years now I've been creating Garmin maps based on OSM data, and I've been walking along local and national trails in the UK for far longer.  Never have I needed to "follow a GPX" - it seems a very alien thing to want to do, and (as mentioned previously) isn't actually supported by any of the various Garmin hiking GPSs that I've used.  If you want to do that - fine - but not everyone does.

Ok, I accept I just don't know how it's done. So how is that done? How do I tell my Garmin to guide me along, say, the Limes trail through the Netherlands? It's mapped in OSM as a series of sections, each relation encompassing one days walking, and all the sections are in a parent route, which in turn is part of the international Limes trail.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12345