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

[Paul Allen]

On Tue, 20 Aug 2019 at 11:17, Warin <61sundow...@gmail.com> wrote:

[editors and/or mappers]

I think some separate a way and insert a new roundabout .. the new
> roundabout does not go into the relations.
>

This is the sort of problem that iD could cause, a year or two ago.  You
could delete or
disconnect ways that were in a route relation without iD complaining, or
warning you
that you were going to break a relation.  That changed.  Now, in that
situation, iD does
an impression of HAL in the film 2001: "I can't let you do that, Dave."
Tricking iD into
letting you do it is even harder than tricking HAL was. If you do manage to
do it,
you'll have some route repairs to do afterwards, but that's going to be the
case
with any editor if you break a way to insert a roundabout.

I don't know if iD catches every possible way you could accidentally break
a relation.
But I don't know if any of the other editors do that either.  I doubt their
authors would
guarantee that they could never accidentally break a relation (in fact, I
hope none of
those authors would make such a claim, because it's impossible to be sure).

I have had some that were broken by the additions of turn restrictions.
> Never bothered
>
to find out what they did, just fixed them and got on with life.  Usually
> they are iD edits,
>
I suspect most people use iD, particularly those just starting out so it is
> no real guide
>
as to potential iD problems.
>

Again, that WAS the case in the past.  It no longer is, at least not for
common ways of
accidentally breaking a relation (where "common" is defined as "stuff I do
or have
done recently").

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Richard Fairhurst :
> Kenny:

> > 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.
>
> As does P2, I believe (I didn't write that bit of code) - iD's code might
> actually be based on P2's. That does make me wonder how much of a problem
> this is in reality if the four major desktop editors already support it.
>

Web editors you mean?
 I do regular maintenance for about 50 national and regional named and
waymarked hiking routes and their variants,  This involves checking
integrity and ensuring that there is a linear main route which can simply
be extracted for further processing in route editors, apps, gps devices and
trip planner sites. When I have a route finished without any problems, then
return a month later, it invariably has several breaks and flaws which make
simple extraction as one ordered linear track impossible. These are almost
always caused by online edits to the map. Other routes and relations
maintainers will experience the same. As long as there are enough people
who care, it gets fixed. Using the proper tools, that is not very difficult
if you know what you are doing. As soon as they stop, the routes
deteriorate quickly. Not only structural, but also the changes no longer
find their way to OSM.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Warin]

On 20/08/19 18:38, Richard Fairhurst wrote:

Kevin Kenny wrote:

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.

I have an algorithm like that too - it skeletonises dual carriageways and
roundabouts, hops over small jumps, and so on. But that's very different
from the steps to implement in an online editor, which has many more
constraints. (P2 doesn't have access to the full set of JTS/PostGIS tools,
for example!) _If_ the issues can be identified clearly and the realistic
steps to fix them enumerated, then we're getting somewhere.


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.

As does P2, I believe (I didn't write that bit of code) - iD's code might
actually be based on P2's. That does make me wonder how much of a problem
this is in reality if the four major desktop editors already support it.


I don't know.

I think some separate a way and insert a new roundabout .. the new roundabout 
does not go into the relations.

I have had some that were broken by the additions of turn restrictions. Never 
bothered to find out what they did, just fixed them and got on with life.
Usually they are iD edits, I suspect most people use iD, particularly those 
just starting out so it is no real guide as to potential iD problems.




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.

Generally I tend to think that a data model that can't be edited with a
simple UI is a bad data model; and that "power users" are a curse on
Wikipedia and rapidly becoming the same in OSM, especially when their main
role is to generate abstruse content as self-gratification but which no-one
will ever actually consume. But that's just me being a grumpy old man too.
:)


That is an expanding club. Generally life membership is granted.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

That is exactly what I described: you have a route i.e. a chain of ways to
follow. But OsmAnd cannot do that! It can access the route and show it on
the map, but it does not use it for navigation. So you have to first turn
it into a string of points (gpx), losing the connection to the map and the
ways. Then import that into OsmAnd. The OsmAnd combines that with the map
again, to turn the track (list of points) back into a route (list of ways
you began with) for navigation. Am I the only one to find this a bit odd?

Fr gr Peter Elderson


Op di 20 aug. 2019 om 09:25 schreef s8evq :

>
>
> On Tue, 20 Aug 2019 01:00:47 +0200, Peter Elderson 
> wrote:
> >  The osm route IS the route, and it should be usable as is, without
> redoing the routing.
>
>
>
> Perhaps I'm misunderstanding you, but couldn't you do that in OsmAnd? Take
> the GPX from a hiking route and import in Osmand. Set your destination in
> Osmand, start navigation, and under options, go for "GPX route - Choose
> track file to follow" and choose your imported GPX. OsmAnd wil give you
> turn by turn instructions, along the GPX.
> (I have to be honest, doesn't work 100% perfectly. Perhaps bad quality
> GPX? I didn't test it enough.)
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Richard Fairhurst]

Kevin Kenny wrote:
> 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.

I have an algorithm like that too - it skeletonises dual carriageways and
roundabouts, hops over small jumps, and so on. But that's very different
from the steps to implement in an online editor, which has many more
constraints. (P2 doesn't have access to the full set of JTS/PostGIS tools,
for example!) _If_ the issues can be identified clearly and the realistic
steps to fix them enumerated, then we're getting somewhere.

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

As does P2, I believe (I didn't write that bit of code) - iD's code might
actually be based on P2's. That does make me wonder how much of a problem
this is in reality if the four major desktop editors already support it.

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

Generally I tend to think that a data model that can't be edited with a
simple UI is a bad data model; and that "power users" are a curse on
Wikipedia and rapidly becoming the same in OSM, especially when their main
role is to generate abstruse content as self-gratification but which no-one
will ever actually consume. But that's just me being a grumpy old man too.
:)

cheers
Richard



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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[s8evq]

I would like to briefly add my opinion on the sorting of relations question:

To be clear: my experience is mostly with short roundtrip hiking/walking 
relations in Flanders 
(https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Local_Walking_Routes_Flanders#Local_Walking_Routes_in_Flanders).
 I hardly every work on public transport relations.

-  Sarah wrote here that currently about 15% is not sorted. I can agree with 
that. Most relations I encounter are already correctly sorted.

- I can not agree with Peter and others that sorted relations easily break. I 
hardly ever see somebody messed up a short walking relation. Once they are 
properly entered, they stay correct for the most time.

- There is one small reason in favor of sorting walking relations: If the walk 
has signs, but the signs are only visible when doing the walk in a certain 
direction, it could be handy to know what direction that is. 
(https://wiki.openstreetmap.org/wiki/Key:signed_direction) We had a discussion 
about this previously. We couldn't come up with any solution for this, besides 
sorting the relation. (sorting is not perfect either, as Kevin Kenny pointed 
out (https://lists.openstreetmap.org/pipermail/tagging/2019-March/043882.html)

- The argument that requiring sorting would burden that mappers Personally 
I don't find that it's a lot of work, and it makes the relation easier to 
handle. More benefit with little additional work. If we have sorted routes: 
great, that's a little bit of extra info. If we don't: no problem either.


On Mon, 19 Aug 2019 23:36:37 +0200, Volker Schmidt  wrote:

> On Mon, 19 Aug 2019 at 15:40, Peter Elderson  wrote:
> 
> > 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.
> >
> 
> Now we are getting closer to the point. You are correctly saying "no app is
> currently doing that". So why should we sort topologically non-sortable
> route-relations members? We have a solution that works with existing tools
> on unsorted hiking/cycling routes, and that is routing with strong
> preference on the use of ways that are part of cycling/hiking routes.
> I see the problem from the mapper's perspective (as I map a lot) and from
> the end-users perspective (I very often design bicycle tour routes from OSM
> data).
> I am not a data consumer in the sense I do not write software thta uses OSM
> data, I am an end usere, eclusivley using the software produced by others)
> and I acknowledge that  my experience is limited to cycling/hiking routes.
> I am sure there are routes that have different problems and may need
> sorting, One such category are most likely public transport routes, which
> are used in a completely different way.
> 
> Volker
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[s8evq]

On Tue, 20 Aug 2019 01:00:47 +0200, Peter Elderson  wrote:
>  The osm route IS the route, and it should be usable as is, without redoing 
> the routing.



Perhaps I'm misunderstanding you, but couldn't you do that in OsmAnd? Take the 
GPX from a hiking route and import in Osmand. Set your destination in Osmand, 
start navigation, and under options, go for "GPX route - Choose track file to 
follow" and choose your imported GPX. OsmAnd wil give you turn by turn 
instructions, along the GPX.
(I have to be honest, doesn't work 100% perfectly. Perhaps bad quality GPX? I 
didn't test it enough.)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

And that is a reason why routes can be nested, so you can use the sections as 
routes of their own. I would still like to know how else to feed an OSM-route 
to a garmin or app if not by converting it to gpx so it can reroute along the 
points in the track to produce exactly the original route.

Mvg Peter Elderson

> Op 20 aug. 2019 om 08:13 heeft Warin <61sundow...@gmail.com> het volgende 
> geschreven:
> 
> The longest local route to me that I have worked on is over 5,000 km long. I 
> am certain that would not fit on my GPS as a route using this method.
> 
> To reduce the gpx file it would be better to use the nodes where the route 
> changes from one way to another or where the way ends/starts. This would 
> leave the GPS to figure out that the internal map has a way between those 
> points and can use it That should be less way points. But even then on my 
> 5,000 km route it would be far too big for my old GPS as one route. That is 
> ok .. I'd separate it into bits. 
> 
> 
>> On 20/08/19 15:59, Peter Elderson wrote:
>> That is what I do, and what an growing number of hiking people do: turn a 
>> route into a gpx, load the gpx into an app or device, which then routes 
>> along the gpx using all the nodes as waypoints. It works, and it recreates 
>> the exact route if the map is exctly the same as the original. And if the 
>> gpx is linear and without ordering problems. 
>> And its crazy. Because the route is there to begin with, ready in OSM. 
>> 
>> I still don't know how else to feed a pre-existing route to a garmin. If it 
>> doesn't take the route from the map, and it doesn't take a gpx, how does the 
>> device know where to go?
>> 
>> Vr gr Peter Elderson
>> 
>> 
>> Op di 20 aug. 2019 om 05:49 schreef Warin <61sundow...@gmail.com>:
>>> On 18/08/19 00:07, Peter Elderson wrote:
>>> > In this case, I do NOT want to go from A to B. I want to do the hike, 
>>> > that is the route, exactly as it is specified OSM. Those ways, in the 
>>> > exact order. I want my smartphone or garmin to guide me exactly along 
>>> > those ways, which were carefully picked when the route was entered 
>>> > into OSM.
>>> >
>>> > If that can't be done directly, I want to get an export that I can 
>>> > feed to my device or app, so it can recreate the route exactly, 
>>> > without adding, weighing, guessing or rerouting anything.
>>> >
>>> > When I'm planning a hike, I want the software to start with the exact 
>>> > OSM route, not a rerouted version.
>>> 
>>> It may be possible...
>>> Each node alone the OSM route would be a waypoint for your Garmin device 
>>> as a route. There will be lots of waypoints!
>>> You would need a OSM map on the Garmin device.
>>> 
>>> That may work... I am not certain if voice prompts would work, but the 
>>> gpx file will be large, there may be too many waypoints for you device 
>>> to handle.
>>> The device will still be routing .. but between the nodes of the way 
>>> there will be no difference between the OSM map and the route.
>>> 
>>> Because of the large number of waypoints I'd think most people will not 
>>> do this. If you chose to do it Peter, good luck.
>>> 
>>> 
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>> 
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Warin]

The longest local route to me that I have worked on is over 5,000 km 
long. I am certain that would not fit on my GPS as a route using this 
method.


To reduce the gpx file it would be better to use the nodes where the 
route changes from one way to another or where the way ends/starts. This 
would leave the GPS to figure out that the internal map has a way 
between those points and can use it That should be less way points. But 
even then on my 5,000 km route it would be far too big for my old GPS as 
one route. That is ok .. I'd separate it into bits.



On 20/08/19 15:59, Peter Elderson wrote:
That is what I do, and what an growing number of hiking people do: 
turn a route into a gpx, load the gpx into an app or device, which 
then routes along the gpx using all the nodes as waypoints. It works, 
and it recreates the exact route if the map is exctly the same as the 
original. And if the gpx is linear and without ordering problems.

And its crazy. Because the route is there to begin with, ready in OSM.

I still don't know how else to feed a pre-existing route to a garmin. 
If it doesn't take the route from the map, and it doesn't take a gpx, 
how does the device know where to go?


Vr gr Peter Elderson


Op di 20 aug. 2019 om 05:49 schreef Warin <61sundow...@gmail.com 
>:


On 18/08/19 00:07, Peter Elderson wrote:
> In this case, I do NOT want to go from A to B. I want to do the
hike,
> that is the route, exactly as it is specified OSM. Those ways,
in the
> exact order. I want my smartphone or garmin to guide me exactly
along
> those ways, which were carefully picked when the route was entered
> into OSM.
>
> If that can't be done directly, I want to get an export that I can
> feed to my device or app, so it can recreate the route exactly,
> without adding, weighing, guessing or rerouting anything.
>
> When I'm planning a hike, I want the software to start with the
exact
> OSM route, not a rerouted version.

It may be possible...
Each node alone the OSM route would be a waypoint for your Garmin
device
as a route. There will be lots of waypoints!
You would need a OSM map on the Garmin device.

That may work... I am not certain if voice prompts would work, but
the
gpx file will be large, there may be too many waypoints for you
device
to handle.
The device will still be routing .. but between the nodes of the way
there will be no difference between the OSM map and the route.

Because of the large number of waypoints I'd think most people
will not
do this. If you chose to do it Peter, good luck.


___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

That is what I do, and what an growing number of hiking people do: turn a
route into a gpx, load the gpx into an app or device, which then routes
along the gpx using all the nodes as waypoints. It works, and it recreates
the exact route if the map is exctly the same as the original. And if the
gpx is linear and without ordering problems.
And its crazy. Because the route is there to begin with, ready in OSM.

I still don't know how else to feed a pre-existing route to a garmin. If it
doesn't take the route from the map, and it doesn't take a gpx, how does
the device know where to go?

Vr gr Peter Elderson


Op di 20 aug. 2019 om 05:49 schreef Warin <61sundow...@gmail.com>:

> On 18/08/19 00:07, Peter Elderson wrote:
> > In this case, I do NOT want to go from A to B. I want to do the hike,
> > that is the route, exactly as it is specified OSM. Those ways, in the
> > exact order. I want my smartphone or garmin to guide me exactly along
> > those ways, which were carefully picked when the route was entered
> > into OSM.
> >
> > If that can't be done directly, I want to get an export that I can
> > feed to my device or app, so it can recreate the route exactly,
> > without adding, weighing, guessing or rerouting anything.
> >
> > When I'm planning a hike, I want the software to start with the exact
> > OSM route, not a rerouted version.
>
> It may be possible...
> Each node alone the OSM route would be a waypoint for your Garmin device
> as a route. There will be lots of waypoints!
> You would need a OSM map on the Garmin device.
>
> That may work... I am not certain if voice prompts would work, but the
> gpx file will be large, there may be too many waypoints for you device
> to handle.
> The device will still be routing .. but between the nodes of the way
> there will be no difference between the OSM map and the route.
>
> Because of the large number of waypoints I'd think most people will not
> do this. If you chose to do it Peter, good luck.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

> Volker Schmidt  het volgende geschreven:
> 
>> On Mon, 19 Aug 2019 at 15:40, Peter Elderson  wrote:
>> 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.
> 
> Now we are getting closer to the point. You are correctly saying "no app is 
> currently doing that". So why should we sort topologically non-sortable 
> route-relations members? We have a solution that works with existing tools on 
> unsorted hiking/cycling routes, and that is routing with strong preference on 
> the use of ways that are part of cycling/hiking routes.
> I see the problem from the mapper's perspective (as I map a lot) and from the 
> end-users perspective (I very often design bicycle tour routes from OSM 
> data). 
> I am not a data consumer in the sense I do not write software thta uses OSM 
> data, I am an end usere, eclusivley using the software produced by others) 
> and I acknowledge that  my experience is limited to cycling/hiking routes. I 
> am sure there are routes that have different problems and may need sorting, 
> One such category are most likely public transport routes, which are used in 
> a completely different way.

Routes in osm describe closely the routes found on the road. They are described 
as the chain of ways you follow. If they don’t, that should be fixed so they 
again reflect the situation on the road. The osm route IS the route, and it 
should be usable as is, without redoing the routing. If you find it necessary 
to do the routing again, no matter how cleverly you do that, you don’t fix the 
problem, you are just fixing errors at the wrong end, leaving the osm data as 
flawed as before. (Question: where does your weighted routing start and end?)

If you have a method of fixing the data, I would like it better if you make 
that avaible as a tool to enhance/ensure the quality of the osm-data, so the 
recorded routes can be used as the ready-to-use routes they are supposed to 
reflect.

Once routes are reliable for direct use, they will be used much more frequently 
in real applications. Osmand could use it, they now demand a linear gpx even 
for routes that are already known and displayed because you just can’t rely on 
OSM routes. If they could, exact turnbyturn instructions could be given to the 
user, complete with other map info, without any routing algorithm, because the 
route is already there.

In the current state, reliability is simply too low for direct use. If that 
remains the case over the next few years, mark my words, you can stop putting 
routes into osm, because other sources will offer far better functionality 
based on actually reliable data. The people who mark the ways will record 
changes realtime, and that will be available for users with apps near realtime. 
Then osm mappers who now often are faster with updates, will always be slower 
and they will be recording things that are already done better elsewhere (and 
shown on the OSM of course, just leaving out the messy data)


> 
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 17:01, Richard Fairhurst  wrote:
> 
> (I have elided most of the intermediate steps.)


and a lot of preparatory steps: you need to buy a computer, find a wall outlet 
to plug it in, find the power button, find an internet provider and subscribe 
to a plan, configure your modem, ...

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Volker Schmidt]

On Mon, 19 Aug 2019 at 15:40, Peter Elderson  wrote:

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

Now we are getting closer to the point. You are correctly saying "no app is
currently doing that". So why should we sort topologically non-sortable
route-relations members? We have a solution that works with existing tools
on unsorted hiking/cycling routes, and that is routing with strong
preference on the use of ways that are part of cycling/hiking routes.
I see the problem from the mapper's perspective (as I map a lot) and from
the end-users perspective (I very often design bicycle tour routes from OSM
data).
I am not a data consumer in the sense I do not write software thta uses OSM
data, I am an end usere, eclusivley using the software produced by others)
and I acknowledge that  my experience is limited to cycling/hiking routes.
I am sure there are routes that have different problems and may need
sorting, One such category are most likely public transport routes, which
are used in a completely different way.

Volker
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

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.
>
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jo]

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.

https://www.youtube.com/user/yoyo7yoyo

Polyglot

On Mon, Aug 19, 2019 at 6:57 PM Andy Townsend  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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Richard Fairhurst :

> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

On Mon, Aug 19, 2019 at 11:10 AM Paul Allen  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

On Mon, Aug 19, 2019 at 11:02 AM Richard Fairhurst  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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 
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Richard Fairhurst]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

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 :

> 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  wrote:
>
>> On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
>> > On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  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 

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

[Volker Schmidt]

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  wrote:

> On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> > On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  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  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

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

[Sarah Hoffmann]

On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  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  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

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

[Volker Schmidt]

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

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

[Volker Schmidt]

On Sun, 18 Aug 2019 at 18:26, Richard Fairhurst 
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Sarah Hoffmann]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Kevin Kenny :
> 
>> On Sun, Aug 18, 2019 at 3:31 PM Peter Elderson  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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

On Sun, Aug 18, 2019 at 3:31 PM Peter Elderson  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).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Richard Fairhurst :

> Sarah Hoffman wrote:
> > On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> > > Peter Elderson wrote:
> > > > The point is, as it is it's not good enough for data use besides
> > > > rendering. you can't rely on route relations for anything but
> > rendering
> > >
> > > Once again: pretty much every OSM-based bike router uses route
> relations
> > to
> > > influence routing. (That might give you a clue to one of the
> > strategies.)
> >
> > But this is a task which is essentially the same rendering.
>
> I was addressing Peter's point that route relations can only be used for
> rendering, which is demonstrably false - they're used for influencing
> weighting in routing.
>

Ok, I agree you can use membership of a route relation as a weight factor,
while you do routing. You don't use the relation as a route. The idea of
walking routes is that they are the route and you follow the route, partly
or with own adaptions, but not for rerouting.

I did not mean that they can only be used for rendering. The point I made
is that if there are interruptions, branches, duplicates, stray nodes,
nested relations, etc in a route relation, it can still be used for
rendering (or, for granting weight to individal ways when routing), but you
cannot use it as a route that you follow from A to B by the ways it
contains.

>
> > The problems come in if you want to go the other way. When you start
> with
> > the relation, want to determine where the route goes along. That
> > information
> > is simply not contained in the route relations as long as you don't
> impose
> > a
> > couple of restrictions. [...]
> > I consider sorting and the use of roles essential for that.
>
> 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.
>

How then do I get it in OsmAnd and have it guide me forward the entire
route, then backward the entire route? Or in a Garmin device? Mine does not
have the option, as far as I know. I can do a lot, but it requires getting
the OSM data organized exactly as required, and involves gpx transfer and
route editing software, and in the end, Garmin reroutes the whole thing
again, to arrive at exectly the chain of ways I started with in OSM. The
main point is, as you say, data quality. QA tools can find problems, but
the fixing is still up to the mapper. RA does things, but can simply not
handle complex walking route relations.

JOSM does a decent job in detecting problems and it provides decent fixing
tools. E.g. sorting. But that often fails when the route is broken. Just
like overpass turbo export has a sorting routine, which works for simple
ordering tasks but just gives up if it gets complicated. Sam with
waymarkedtrails: its fine when simple ordering problems are there, it also
handles hierarchies quite nicely, but if it doesn't work out completely it
gives up and gives the relation as is.

I would sure like a better QA tool. I also would like a sorting routine in
JOSM that can handle all the complexities that prevent the full sort. If
anyone has goed code for that and knows how to make that available as a
plugin, that would be a great asset in maintaining OSM walking routes. I'm
often sorry I am no good at programming.


> 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. The problem is that walking relations often do not add up to a
linear route when sorted. If they do, that doesn't last very long. So you
can't presume that they are, so it's up to the mapper to do it.

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

The problem is, the route relation is often meant to be 

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

[Richard Fairhurst]

Sarah Hoffman wrote:
> On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> > Peter Elderson wrote:
> > > The point is, as it is it's not good enough for data use besides 
> > > rendering. you can't rely on route relations for anything but
> rendering
> > 
> > Once again: pretty much every OSM-based bike router uses route relations
> to
> > influence routing. (That might give you a clue to one of the
> strategies.)
> 
> But this is a task which is essentially the same rendering. 

I was addressing Peter's point that route relations can only be used for
rendering, which is demonstrably false - they're used for influencing
weighting in routing.

> The problems come in if you want to go the other way. When you start with 
> the relation, want to determine where the route goes along. That
> information 
> is simply not contained in the route relations as long as you don't impose
> a
> couple of restrictions. [...]
> I consider sorting and the use of roles essential for that.

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.

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. 

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.

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.
There's probably a little more that editing software can do here, but unless
you want to require people to have 12 months of OSM experience before they
can map a change to their local cycle route, ultimately the solution is to
have better QA tools. Something like OSM Relation Analyser is faultless
algorithmically but the UI is less than immediate. If we were to have an OSM
Inspector-like view of lacunae, spurs and other relation issues, it would be
a whole lot easier to fix them. I occasionally wonder about coding this but
I'd love it if someone were to beat me to it.

cheers
Richard



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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 14:43, Paul Allen  wrote:
> 
> Maybe
> we shouldn't ever insist that mappers sort the routes they add, but I don't 
> think
> we should discourage them if they want to put in that effort. 


+1, this is my opinion as well. Sorted routes make it usually easier for other 
mappers to do modifications and to see if the route has gaps


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Allen]

On Sun, 18 Aug 2019 at 10:01, Sarah Hoffmann  wrote:

>
> I have no issue if relations require reasonable processing to get to a
> result
> but I would like to see enough information encoded in the route relation
> that
> the processing invariably gets me to the result that the mapper intended.
> I consider sorting and the use of roles essential for that.
>

So far we've only been talking of hiking/walking routes where some feel
sorting is
beneficial and others feel it is unnecessary.  At the risk of derailing the
thread,
there are other types of route relation.

Take bus routes.  I know of a very complicated bus route.  At three times
along the
route it drives into a cul-de-sac, reverses into a side-road of that
cul-de-sac, then
goes back the way it came.  Those three places are not termini, they are
merely
points along the route where most of the passengers remain on board.  In
one part of the route it does a loop-the-loop, going around four sides of a
square.
It traverses other segments of the route twice, in the same direction,
approximately
30 minutes apart.  Oh, and it does the reversing-turn trick in another
place that
isn't a cul-de-sac, it just doesn't go any further along that road.

It is perfectly possible to render the route.  Trying to figure out the
steps in the route
from the rendered route is pretty much impossible, although detailed
inspection of
the one-way markings eliminates several possibilities.  We don't (as far as
I know)
have any tool comparable to uMap that would allow ordinary users to step
through
the route so they can comprehend the details, although splitting the route
into sub-relations would allow uMap to give a crude approximation of that
capability.  But one day such a tool might appear, at which point having
the route
sorted would be beneficial.

Here is the route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6643
Good luck figuring out where it goes, even though the list of ways is (I
think) correctly
sorted.  On the public transport layer you wouldn't even get the list of
ways unless you
queried the route.

So maybe sorting isn't absolutely necessary, but it can make life easier.
Maybe
we shouldn't ever insist that mappers sort the routes they add, but I don't
think
we should discourage them if they want to put in that effort.  Especially
if, one day,
somebody comes up with a step-by-step tool for displaying routes.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Sarah Hoffmann]

On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> Peter Elderson wrote:
> > I would like to see this software in operation! Could you give me the 
> > links of some applications 
> 
> I use my code in the backend of cycle.travel. It's not open source. I've
> seen code used by one other OSM-based site and there's a further one that's
> clearly using something similar. There are at least two really obvious
> strategies for dealing with relations like this.
> 
> > The point is, as it is it's not good enough for data use besides 
> > rendering. you can't rely on route relations for anything but rendering
> 
> Once again: pretty much every OSM-based bike router uses route relations to
> influence routing. (That might give you a clue to one of the strategies.)

But this is a task which is essentially the same rendering. You only need
to know what routes are on a certain way segment and use that information
to adjust the weights for the road. Even if you do something fancy like
ensuring that you remain of the same cycling route, it still comes down to
using the relation information as a property of the ways. Our route relations
are well suited for that.

The problems come in if you want to go the other way. When you start with the
relation, want to determine where the route goes along. That information is
simply not contained in the route relations as long as you don't impose a
couple of restrictions. Sure, you can apply a couple of heuristics and get
a reasonably good result for most of the routes. But it remains guess-work.

I have no issue if relations require reasonable processing to get to a result
but I would like to see enough information encoded in the route relation that
the processing invariably gets me to the result that the mapper intended.
I consider sorting and the use of roles essential for that.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Again, software can not handle e.g. the E2 relation. Simple sort, fine,
bridge a small gap, handle a roundabout, fine, but not the more serious
route-breaking issues. You can't expect Garmin to solve that, it's a data
issue in OSM. Currently the only way to solve it is making the data
flawless: one main route, single chain, no nodes, handle hierarchies, no
duplicates, no branches, no areas. All alternatives separate. Then you can
use it  as is for further processing.

The main problem is maintenance against editing software and users breaking
the routes. The solution should be protection against breaking, not
repairing flaws at the client side.

Maybe the latest improvements in ID help. It's too early to tell. I'm still
encountering issues all the time in the routes I check and use.

Fr gr Peter Elderson


Op za 17 aug. 2019 om 15:58 schreef Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> I agree with Andy Townsend here.
>
> Routes are complicated enough without needing to be always perfectly
> sorted. Software developers and database users should make up for
> this. Mapping is hard and takes precious human time. Computational
> cycles are cheap.
>
> OSM has never been designed to be used directly "as-is" from the raw
> data. Even JOSM and ID do all sorts of clever things to show you a
> reasonable rendering of the data as you enter it.
>
> Please open issues requests with your favorite software providers,
> like Garmin, or switch to one that will support routes in the way that
> works for you. Perhaps one of the bike/hike websites like Map My Run,
> Ride With GPS, etc already have something like this offered?
>
> Mappers should not to do extra work and extra maintenance of data.
> Spend time mapping, not sorting relations.
>
> -Joseph Eisenberg
>
> (PS: I help develop software a little, by contributing at
> Openstreetmap-carto to improve and maintain the rendering. I haven't
> developed a routing engine or anything so complicated myself).
>
> On 8/17/19, Andy Townsend  wrote:
> >
> >> You want to do the routing. I want to avoid that, because the routing
> has
> >> already been done.
> >
> > To be clear, I want to navigate from where I currently am to where I
> want to
> > go.  If a route is blocked (or, heaven forfend, wrong in OSM) I still
> want
> > to get where I'm going, even if I am not exactly where I thought I should
> > be.
> >
> >> OsmAnd and Garmin should take the route itself, not waypoints to route
> to.
> >> It is odd that OsmAnd cannot navigate me along an ÒSM route that's shown
> >> on the map and is readily available from OSM.
> >
> > I'm not sure what the current situation is with OsmAnd, but do know that
> > it's been discussed within the last few months in the OsmAnd Google Geoup
> >
> > With regard to Garmin, it sounds like you should be submitting a feature
> > request to them - it is unlikely that they monitor OSM's tagging list for
> > those.
> >
> > It does sound, however, that you don't have a concrete use-case at all -
> you
> > have a view of how things "should" be, but this doesn't seem to be
> driven by
> > a real-world requirement.  That's why I've been asking for specifics
> > throughout this thread (and Richard has too).
> >
> > Best Regards,
> >
> > Andy
> >
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

In this case, I do NOT want to go from A to B. I want to do the hike, that
is the route, exactly as it is specified OSM. Those ways, in the exact
order. I want my smartphone or garmin to guide me exactly along those ways,
which were carefully picked when the route was entered into OSM.

If that can't be done directly, I want to get an export that I can feed to
my device or app, so it can recreate the route exactly, without adding,
weighing, guessing or rerouting anything.

When I'm planning a hike, I want the software to start with the exact OSM
route, not a rerouted version.

Fr gr Peter Elderson


Op za 17 aug. 2019 om 15:44 schreef Andy Townsend :

>
> > You want to do the routing. I want to avoid that, because the routing
> has already been done.
>
> To be clear, I want to navigate from where I currently am to where I want
> to go.  If a route is blocked (or, heaven forfend, wrong in OSM) I still
> want to get where I'm going, even if I am not exactly where I thought I
> should be.
>
> > OsmAnd and Garmin should take the route itself, not waypoints to route
> to. It is odd that OsmAnd cannot navigate me along an ÒSM route that's
> shown on the map and is readily available from OSM.
>
> I'm not sure what the current situation is with OsmAnd, but do know that
> it's been discussed within the last few months in the OsmAnd Google Geoup
>
> With regard to Garmin, it sounds like you should be submitting a feature
> request to them - it is unlikely that they monitor OSM's tagging list for
> those.
>
> It does sound, however, that you don't have a concrete use-case at all -
> you have a view of how things "should" be, but this doesn't seem to be
> driven by a real-world requirement.  That's why I've been asking for
> specifics throughout this thread (and Richard has too).
>
> Best Regards,
>
> Andy
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Joseph Eisenberg]

I agree with Andy Townsend here.

Routes are complicated enough without needing to be always perfectly
sorted. Software developers and database users should make up for
this. Mapping is hard and takes precious human time. Computational
cycles are cheap.

OSM has never been designed to be used directly "as-is" from the raw
data. Even JOSM and ID do all sorts of clever things to show you a
reasonable rendering of the data as you enter it.

Please open issues requests with your favorite software providers,
like Garmin, or switch to one that will support routes in the way that
works for you. Perhaps one of the bike/hike websites like Map My Run,
Ride With GPS, etc already have something like this offered?

Mappers should not to do extra work and extra maintenance of data.
Spend time mapping, not sorting relations.

-Joseph Eisenberg

(PS: I help develop software a little, by contributing at
Openstreetmap-carto to improve and maintain the rendering. I haven't
developed a routing engine or anything so complicated myself).

On 8/17/19, Andy Townsend  wrote:
>
>> You want to do the routing. I want to avoid that, because the routing has
>> already been done.
>
> To be clear, I want to navigate from where I currently am to where I want to
> go.  If a route is blocked (or, heaven forfend, wrong in OSM) I still want
> to get where I'm going, even if I am not exactly where I thought I should
> be.
>
>> OsmAnd and Garmin should take the route itself, not waypoints to route to.
>> It is odd that OsmAnd cannot navigate me along an ÒSM route that's shown
>> on the map and is readily available from OSM.
>
> I'm not sure what the current situation is with OsmAnd, but do know that
> it's been discussed within the last few months in the OsmAnd Google Geoup
>
> With regard to Garmin, it sounds like you should be submitting a feature
> request to them - it is unlikely that they monitor OSM's tagging list for
> those.
>
> It does sound, however, that you don't have a concrete use-case at all - you
> have a view of how things "should" be, but this doesn't seem to be driven by
> a real-world requirement.  That's why I've been asking for specifics
> throughout this thread (and Richard has too).
>
> Best Regards,
>
> Andy
>
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Townsend]

> You want to do the routing. I want to avoid that, because the routing has already been done. To be clear, I want to navigate from where I currently am to where I want to go.  If a route is blocked (or, heaven forfend, wrong in OSM) I still want to get where I'm going, even if I am not exactly where I thought I should be.> OsmAnd and Garmin should take the route itself, not waypoints to route to. It is odd that OsmAnd cannot navigate me along an ÒSM route that's shown on the map and is readily available from OSM. I'm not sure what the current situation is with OsmAnd, but do know that it's been discussed within the last few months in the OsmAnd Google GeoupWith regard to Garmin, it sounds like you should be submitting a feature request to them - it is unlikely that they monitor OSM's tagging list for those.It does sound, however, that you don't have a concrete use-case at all - you have a view of how things "should" be, but this doesn't seem to be driven by a real-world requirement.  That's why I've been asking for specifics throughout this thread (and Richard has too).Best Regards,Andy   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Your viewpoint is different from mine. You want to do the routing. I want
to avoid that, because the routing has already been done. The OSM-relation
IS a route. It is entered as an exact chain of ways to folllow.

OsmAnd and Garmin should take the route itself, not waypoints to route to.
It is odd that OsmAnd cannot navigate me along an ÒSM route that's shown on
the map and is readily available from OSM. Instead, I have to translate it
into a series of waypoints (gpx), then feed that to the app, and then it
recalculates the route (chain of ways) it already had.

Vr gr Peter Elderson


Op za 17 aug. 2019 om 15:08 schreef Andy Townsend :

>
> > apps like OsmAnd, Garmin devices, and planner applications
>
> I can answer the Garmin bit of that, as it's something that I do all the
> time.
>
> Firstly, the ability to "follow a GPX" isn't something that most Garmin
> devices support.  None of the eTrex or GPSMap (walking) or Nuvi (car)
> models that I've had support it.  I believe that some models designed for
> cycling do, but let's be honest - you're not going to be cycling along most
> of the Wolds Way or Cleveland way.  It not just not allowed in places it'd
> be close to physically impossible.
>
> What Garmins do offer is navigation by a series of waypoints, and they'll
> navigate between those either "as the crow flies" or allow a route that is
> appropriate for your current travel method.  Although the UI for walking-
> and car-focused devices are different, the principle is the same.  You'd
> typically add waypoints along the route manually - either on the device or
> in something like Garmin's PC software before loading to the device.
> "waypoints" and "routes" can fit into the same XML file as any GPX tracks
> you move to and from a Garmin device.
>
> When creating maps from OSM data you can also include route membership
> information on the on-screen map - I usually put the route names in
> brackets after any way name.  I create different Garmin maps for walking
> and driving to remove some paths you don't want to drive on or roads you
> don't want to walk on (or aren't allowed to, based on access tags).
>
> As an aside I do tend to create Garmin routes composed of waypoints for
> guideposts / route markers where I've got that info - it helps to find
> missing ones, and having guideposts and route markers in OSM helps other
> people see which bits of route are well signposted and which not.  You may
> notice that the Wolds Way has a few of these mapped as relation members
> ("role=marker"); other nearby routes are more complete.
>
> To summarise then, I've never found a need to sort the ways in a walking
> route before being able to navigate it using a Garmin handheld.
>
> Best Regards,
>
> Andy
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Townsend]

> apps like OsmAnd, Garmin devices, and planner applicationsI can answer the Garmin bit of that, as it's something that I do all the time.Firstly, the ability to "follow a GPX" isn't something that most Garmin devices support.  None of the eTrex or GPSMap (walking) or Nuvi (car) models that I've had support it.  I believe that some models designed for cycling do, but let's be honest - you're not going to be cycling along most of the Wolds Way or Cleveland way.  It not just not allowed in places it'd be close to physically impossible.What Garmins do offer is navigation by a series of waypoints, and they'll navigate between those either "as the crow flies" or allow a route that is appropriate for your current travel method.  Although the UI for walking- and car-focused devices are different, the principle is the same.  You'd typically add waypoints along the route manually - either on the device or in something like Garmin's PC software before loading to the device. "waypoints" and "routes" can fit into the same XML file as any GPX tracks you move to and from a Garmin device.When creating maps from OSM data you can also include route membership information on the on-screen map - I usually put the route names in brackets after any way name.  I create different Garmin maps for walking and driving to remove some paths you don't want to drive on or roads you don't want to walk on (or aren't allowed to, based on access tags).As an aside I do tend to create Garmin routes composed of waypoints for guideposts / route markers where I've got that info - it helps to find missing ones, and having guideposts and route markers in OSM helps other people see which bits of route are well signposted and which not.  You may notice that the Wolds Way has a few of these mapped as relation members ("role=marker"); other nearby routes are more complete.To summarise then, I've never found a need to sort the ways in a walking route before being able to navigate it using a Garmin handheld.Best Regards,Andy   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Volker Schmidt]

The sequence of the component ways in a walking/hiking route relation is
irrelevant for a hiker who use a navigation device to walk along the route.
Why?
How do you walk a walking route with a navigation device?
Basically you have two options:
A) you have prepared beforehand a GPX track, typically by using a
routing/planning tool on a web site. That site does off-line routing for
you. During the walk you follow the GPX track on the display of your GPS
device (you keep you position on the track on that you see on the screen)
B) you use an equivalent navigation process as in (A) but you execute it in
real time on the map that you have loaded on your navigation device.

In both cases you use some kind of algorithm that finds for you a (nearly)
optimal route from waypoint to waypoint. What does the routing algorithm
do? It assigns, from a table that defines your means of transportation,
"cost" (or "penalty") per meter to each way on the map and basically finds
the "cheapest" connection between consecutive waypoints (in the simplest
case there are two waypoints: start and destination for the off-line
navigation, and actual position and final destination for the on-line
version).
The cost for each way type is dependent on your means of transport.
In the case of walking the cost for a motorway will be near infinity, with
the effect that a hiker will not be routed via a motorway. A perfectly
smooth footway will have a very low cost, a bumpy footway will have a
bumpiness penalty (you are forced to walk slower) and so on.
How are hiking route relations handled? The fact that a specific way is
part of a hiking route relation means that it gets a cost benefit with
respect to an equivalent way that is not part of it. In this way the
algorithm gives preference to those ways that are part of a walking route
relation. I's up to designer of the routing cost table, how much advantage
she will give to a given type of route; she may want to give a national
hiking route a bigger cost advantage in comparison to a local hiking route.

This is the basics why the routing  algorithm does not "care" at all about
the sequence of the ways in the hiking route relation.


On Sat, 17 Aug 2019 at 13:08, Peter Elderson  wrote:

>
>
> Op za 17 aug. 2019 om 12:31 schreef Andy Townsend :
>
>> > but I would like to see one make a plausible navigation route out of
>> the E2 Yorkshire relation as it is now.
>>
>> Where are you going from and where are you going to?  Without that
>> information "make a plausible navigation route out of the E2 Yorkshire
>> relation" makes no sense.
>>
>> That's exactly the point why you can't use a walking route relation as a
> navigational route, unless it has been carefully prepared to be an ordered,
> uninterrupted single-chained A2B route.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

I would like to use walking route relations as they are in OSM, in apps
like OsmAnd, Garmin devices, and planner applications. Currently, you
can't. As far as I can see, they all re-route  instead of using an already
available route (= chain of ways). I would like to see unbroken elevation
profiles for OSM-routes. I would like a gpx from an OSM route to be direcly
usable in navigation apps and devices and reasonably adaptible as one route
in route editing software (without spikes and ordering problems).

Fr gr Peter Elderson


Op za 17 aug. 2019 om 13:33 schreef Andy Townsend :

> You haven't answered the question - I asked "Where are you going from and
> where are you going to?" in order to try and understand what real-life
> problem you're trying to solve. "I would like the ways of a relation to be
> sorted" is not a real-life problem.  What navigation software are you
> using and (in this example) where are you going from and where are you
> going to?
>
> I'm assuming that (on this imaginary hike through Yorkshire) you're not
> lugging a PC around running JOSM, trying to shade the screen from the sun
> on every hilltop so that you can see it, and wrapping it up whenever it
> starts raining.
>
> Best Regards,
>
> Andy
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Townsend]

 You haven't answered the question - I asked "Where are you going from and where are you going to?" in order to try and understand what real-life problem you're trying to solve. "I would like the ways of a relation to be sorted" is not a real-life problem.  What navigation software are you using and (in this example) where are you going from and where are you going to? I'm assuming that (on this imaginary hike through Yorkshire) you're not lugging a PC around running JOSM, trying to shade the screen from the sun on every hilltop so that you can see it, and wrapping it up whenever it starts raining.   Best Regards,Andy   ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Op za 17 aug. 2019 om 12:31 schreef Andy Townsend :

> > but I would like to see one make a plausible navigation route out of the
> E2 Yorkshire relation as it is now.
>
> Where are you going from and where are you going to?  Without that
> information "make a plausible navigation route out of the E2 Yorkshire
> relation" makes no sense.
>
> That's exactly the point why you can't use a walking route relation as a
navigational route, unless it has been carefully prepared to be an ordered,
uninterrupted single-chained A2B route.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

The issue here is that these relations are there, they conform to current
wiki documentation, but you can't simply use them in applications other
then for rendering. Some of the issues (sorting, bridge simple gaps) may be
solved with software at the data user's side, but on the whole you can't
rely on it. Usability depends on mappers applying strict tagging and
ordering standards and heavy maintenance to prevent problems.

If code exists that solves these problems, I would very much welcome that
if it could become availabe as e.g. a tool in JOSM. We could test that on
the E2 Yorkshire relation.

Fr gr Peter Elderson


Op za 17 aug. 2019 om 12:31 schreef Andy Townsend :

> > but I would like to see one make a plausible navigation route out of the
> E2 Yorkshire relation as it is now.
>
> Where are you going from and where are you going to?  Without that
> information "make a plausible navigation route out of the E2 Yorkshire
> relation" makes no sense.
>
> You could certainly argue that splitting the legs of the route rather than
> the "parts geographically in Yorkshire" would make more sense, but making
> use of whole sections of the Wolds Way, Cleveland Way etc. would be better
> still.  That's one for you to resolve though, since you're the one who
> seems to have the issue here.
>
> Best Regards,
>
> Andy
>
>
> .
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Townsend]

> but I would like to see one make a plausible navigation route out of the E2 
> Yorkshire relation as it is now.

Where are you going from and where are you going to?  Without that information 
"make a plausible navigation route out of the E2 Yorkshire relation" makes no 
sense.  

You could certainly argue that splitting the legs of the route rather than the 
"parts geographically in Yorkshire" would make more sense, but making use of 
whole sections of the Wolds Way, Cleveland Way etc. would be better still.  
That's one for you to resolve though, since you're the one who seems to have 
the issue here.

Best Regards,

Andy


.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Two routes, currently mapped together in one relation, but also containing 
subrelations, and not in the right order, and the total of that is part of a 
higher relation which also has variants. You can’t blame the route designers, 
you simply have to accommodate the real life variations. For rendering, it’s ok 
like it is. For routing, not at all. Cycling planners are slightly better than 
hiking planners, but I would like to see one make a plausible navigation route 
out of the E2 Yorkshire relation as it is now.

And yes, that’s a challenge.

Fr Gr Peter Elderson

> Op 17 aug. 2019 om 11:20 heeft Andy Townsend  het volgende 
> geschreven:
> 
>> On 17/08/2019 07:28, Peter Elderson wrote:
>> 
>> Gpx gaps in some software do show up as straight lines. If it's just a 
>> missing piece and the rest is in order, no problem. In the case of the E2 in 
>> Yorkshire, lots of straight lines. Feed that to a navigation device and it 
>> will have you start in Muston, take you around and across the entire region 
>> multiple times, and end up near Barnetby Ie Wold. You wil actually have 
>> followed the E2 as well, I'll give you that!
>> 
> "Following in the E2 in Yorkshire" would be an odd thing to do as there are 
> two parallel legs of it (see 
> https://hiking.waymarkedtrails.org/#?map=8!54.1195!-1.3988 ). From the Humber 
> bridge one side follows the Wolds Way / Cleveland Way etc. to just west of 
> Darlington, and on the other side of the county it runs from the Tan Hill Inn 
> down the Pennine Way.  The problem here isn't the mapping in OSM, but the 
> decision by whoever created the route to have two parallel routes called the 
> same thing.
> 
> What you'd logically actually do on the ground, of course is ignore the E2 
> altogether (it's not signed here) and either follow the Pennine Way signage 
> or the Wolds Way / Cleveland Way etc. signage.
> 
> Best Regards,
> 
> Andy
> 
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Townsend]

On 17/08/2019 07:28, Peter Elderson wrote:


Gpx gaps in some software do show up as straight lines. If it's just a 
missing piece and the rest is in order, no problem. In the case of the 
E2 in Yorkshire, lots of straight lines. Feed that to a navigation 
device and it will have you start in Muston, take you around and 
across the entire region multiple times, and end up near Barnetby Ie 
Wold. You wil actually have followed the E2 as well, I'll give you that!


"Following in the E2 in Yorkshire" would be an odd thing to do as there 
are two parallel legs of it (see 
https://hiking.waymarkedtrails.org/#?map=8!54.1195!-1.3988 ). From the 
Humber bridge one side follows the Wolds Way / Cleveland Way etc. to 
just west of Darlington, and on the other side of the county it runs 
from the Tan Hill Inn down the Pennine Way.  The problem here isn't the 
mapping in OSM, but the decision by whoever created the route to have 
two parallel routes called the same thing.


What you'd logically actually do on the ground, of course is ignore the 
E2 altogether (it's not signed here) and either follow the Pennine Way 
signage or the Wolds Way / Cleveland Way etc. signage.


Best Regards,

Andy




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Richard Fairhurst]

Peter Elderson wrote:
> I would like to see this software in operation! Could you give me the 
> links of some applications 

I use my code in the backend of cycle.travel. It's not open source. I've
seen code used by one other OSM-based site and there's a further one that's
clearly using something similar. There are at least two really obvious
strategies for dealing with relations like this.

> The point is, as it is it's not good enough for data use besides 
> rendering. you can't rely on route relations for anything but rendering

Once again: pretty much every OSM-based bike router uses route relations to
influence routing. (That might give you a clue to one of the strategies.)

Again I ask: perhaps you could clarify what your experience is in consuming
OSM data? Have you written code to do so? Do you run a website that uses
OSM? Because you're making some very confident pronouncements about "you
can't fix that with software", "impossible", "a lot of work for data users",
"no software can handle ", "the only way to get reasonable outcome" etc.
etc. that don't accord at all with my experience. Yet you've been a mapper
for under two years and don't appear to have any software development to
your name at all. But I might be missing something.

Richard



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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

I know how to fix these issues.  The point is, as it is it's not good
enough for data use besides rendering. you can't rely on route relations
for anything but rendering, and you can't fix that with software. It's not
a tagging issue, though.

Gpx gaps in some software do show up as straight lines. If it's just a
missing piece and the rest is in order, no problem. In the case of the E2
in Yorkshire, lots of straight lines. Feed that to a navigation device and
it will have you start in Muston, take you around and across the entire
region multiple times, and end up near Barnetby Ie Wold. You wil actually
have followed the E2 as well, I'll give you that!

Fr gr Peter Elderson


Op za 17 aug. 2019 om 03:16 schreef Warin <61sundow...@gmail.com>:

> My limited experience;
>
> Gaps on the gpx route tend to be straight lines, ok when they are
> contiguous but where they back track it gets confusing.
>
> Some initial thoughts on what I would do, and have done on some routes of
> interest to me ...
>
> On 16/08/19 21:31, Peter Elderson wrote:
>
> Looked at de E2 relation in Yorkshire. It would require a lot of work to
> make it work for data users beside rendering, and to fit it into the E2
> superroute as a whole.
> a. Nodes in the relation - not unheard of, but then with a role like
> start. Should be removed.
>
> Agreed. I don't think nodes belong on a route?
>
> b. 10 gaps. Needs investigating the cause; some just reflect wrong order.
>
> Re ordering is fairly easy.
>
> c. There are a bunch of sorted chains of ways. Maybe just a sorting
> problem, maybe more. Simple sort doesn't work because of the nodes and
> nested relations.
>
> Remove the nodes.
>
> d. Contains ways and other route relations. The other routes appear to
> belong to another main variant running far to the west through Yorkshire.
> These should be separately checked, sorted, oriented and repaired, and then
> moved to a separate relation, in the right order (north to south).
>
>
> If the relations are 'alternatives' .. or even if they are not .. move
> them all to the end of the members and sort the way you have into some
> order.
> Then look at the gaps and see if any of the relations 'fit'.
>
>
> The eastern and western variants separate in Scotland, then run separately
> through England. The east route is the one that connects to the european E2
> which follows the GR5 to Nice.
>
> The E2 has occasional signs all along the route, but the regular
> waymarking is that of the constituting trails. I think that is enough to
> say it's waymarked.
>
> Anybody knows who is mapping routes in England, knows his relation stuff,
> and wants to fix this?
>
>
> Not in England, and not that interested in looking at it in detail.
> Deleting nodes is easy, even putting them into a relation and then placing
> that relation at the end so it does not interfere with sorting is easy.. if
> someone objects to the nodes being deleted.
> Sorting and order the ways too is easy. Dealing with 'alternatives'  needs
> some knowledge of the route, I don't have that.
>
>
> Fr gr Peter Elderson
>
>
> Op vr 16 aug. 2019 om 12:09 schreef Peter Elderson :
>
>> Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend :
>>
>>> On 16/08/2019 08:50, Peter Elderson wrote:
>>> > Josm of course. Is there another relation editor that can handle large
>>> nested route relations spanning up to say 4000 Km?
>>>
>>> P2 can, at least.  Other people seem to suggest that iD does a
>>> reasonable job now too.
>>>
>>
>> Sorry to disagree. P2 and ID are aware of relations and can do a few
>> basic things like adding/removing a way and shifting a way up and down, in
>> one relation at a time. If you maintain a lot of long distance routes, that
>> is painfully inadequate. Even more so if you try to do it in a way that
>> prepares the relations for data users, currently meaning linear and gapless
>> gpx-es for use in navigation software, elevation profiles, and trip
>> planners. You need validation, gap detection, multiple relation windows
>> with shifting between windows, sorting, jump to first/last member,
>> direction reverse, download all members even those not in the bbox, ...
>>
>>
>>>
>>> The more interesting question, though, is "why do you want walking route
>>> relations to be sorted".  The point that's already been made about
>>> routes that use the same way twice is a valid one, but almost never
>>> applies to walking route relations.  What are you trying to do with e.g.
>>> https://www.openstreetmap.org/relation/1976184 (the part of E2* that
>>> runs through Yorkshire) if it's not sorted?
>>>
>>> If it's not sorted: display only. If I want to walk it, I want to use
>> OsmAnd navigation and or Garmin navigation. OsmAnd and Garmin currently
>> cannot use the relation directly, so I have to use a gpx, and they
>> recalculate the route for navigation. The gpx needs to be continous, sorted
>> and gapless, or it won't work. Overpass and Waymarkedtrails can export to a
>> routable gpx, if the 

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

[Warin]

My limited experience;

Gaps on the gpx route tend to be straight lines, ok when they are 
contiguous but where they back track it gets confusing.


Some initial thoughts on what I would do, and have done on some routes 
of interest to me ...


On 16/08/19 21:31, Peter Elderson wrote:
Looked at de E2 relation in Yorkshire. It would require a lot of work 
to make it work for data users beside rendering, and to fit it into 
the E2 superroute as a whole.
a. Nodes in the relation - not unheard of, but then with a role like 
start. Should be removed.

Agreed. I don't think nodes belong on a route?

b. 10 gaps. Needs investigating the cause; some just reflect wrong order.

Re ordering is fairly easy.
c. There are a bunch of sorted chains of ways. Maybe just a sorting 
problem, maybe more. Simple sort doesn't work because of the nodes and 
nested relations.

Remove the nodes.
d. Contains ways and other route relations. The other routes appear to 
belong to another main variant running far to the west through 
Yorkshire. These should be separately checked, sorted, oriented and 
repaired, and then moved to a separate relation, in the right order 
(north to south).


If the relations are 'alternatives' .. or even if they are not .. move 
them all to the end of the members and sort the way you have into some 
order.

Then look at the gaps and see if any of the relations 'fit'.


The eastern and western variants separate in Scotland, then run 
separately through England. The east route is the one that connects to 
the european E2 which follows the GR5 to Nice.


The E2 has occasional signs all along the route, but the regular 
waymarking is that of the constituting trails. I think that is enough 
to say it's waymarked.


Anybody knows who is mapping routes in England, knows his relation 
stuff, and wants to fix this?


Not in England, and not that interested in looking at it in detail.
Deleting nodes is easy, even putting them into a relation and then 
placing that relation at the end so it does not interfere with sorting 
is easy.. if someone objects to the nodes being deleted.
Sorting and order the ways too is easy. Dealing with 'alternatives' 
needs some knowledge of the route, I don't have that.




Fr gr Peter Elderson


Op vr 16 aug. 2019 om 12:09 schreef Peter Elderson 
mailto:pelder...@gmail.com>>:


Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend
mailto:ajt1...@gmail.com>>:

On 16/08/2019 08:50, Peter Elderson wrote:
> Josm of course. Is there another relation editor that can
handle large nested route relations spanning up to say 4000 Km?

P2 can, at least.  Other people seem to suggest that iD does a
reasonable job now too.


Sorry to disagree. P2 and ID are aware of relations and can do a
few basic things like adding/removing a way and shifting a way up
and down, in one relation at a time. If you maintain a lot of long
distance routes, that is painfully inadequate. Even more so if you
try to do it in a way that prepares the relations for data users,
currently meaning linear and gapless gpx-es for use in navigation
software, elevation profiles, and trip planners. You need
validation, gap detection, multiple relation windows with shifting
between windows, sorting, jump to first/last member, direction
reverse, download all members even those not in the bbox, ...


The more interesting question, though, is "why do you want
walking route
relations to be sorted".  The point that's already been made
about
routes that use the same way twice is a valid one, but almost
never
applies to walking route relations.  What are you trying to do
with e.g.
https://www.openstreetmap.org/relation/1976184 (the part of
E2* that
runs through Yorkshire) if it's not sorted?

If it's not sorted: display only. If I want to walk it, I want to
use OsmAnd navigation and or Garmin navigation. OsmAnd and Garmin
currently cannot use the relation directly, so I have to use a
gpx, and they recalculate the route for navigation. The gpx needs
to be continous, sorted and gapless, or it won't work. Overpass
and Waymarkedtrails can export to a routable gpx, if the relation
is one sorted and continous chain of ways.
So before exporting, I use JOSM relation editor, load the entire
thing, solve all gaps en remove duplications, move alternatives
one or more separate relations, then export the main route as gpx.

I also notify the operator of the website
https://www.longdistancepaths.eu/en/
so he can use the export for his trip planner. If he could depend
on routes to be flawless in OSM he could connect directly to it
for automatic periodical refresh.

If the route is on that planner, I would probably use that first
to plan the trip and route according to train and bus stations,
hotels & B's, and places on 

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

[Peter Elderson]

I would like to see this software in operation! Could you give me the links
of some applications that can reorder and use route relations with multiple
gaps, duplicate ways, branches, loose loops, uncut roundabouts, pedestrian
areas, nodes and nested relations? It's not about just unsorted, it's about
all the things that makes sorting impossible.

Vr gr Peter Elderson


Op vr 16 aug. 2019 om 21:05 schreef Richard Fairhurst :

> Peter Elderson wrote:
> > I think it's fair to say there is almost no software that does
> > anything with route relations except rendering and exporting
> > as a gpx.
>
> That's not true. Most bike routers based on OSM are aware of route
> relations
> and use them to influence routing.
>
> > Software needs a sorted or easily sortable relation. Currently,
> > no software can handle sorting when the routes get broken.
>
> That's not true either. I have software right here that reorders unsorted
> relations, as well as skeletonising dual carriageways into single lines,
> jumping over roundabouts and coping with other such issues. I know of two
> other sites operating similar software and I'm sure there are more.
>
> There are certainly issues with consuming route relations but sorting is
> not, in my pretty extensive experience, one of them.
>
> Peter, perhaps you could clarify what your experience is in consuming OSM
> data? Have you written code to do so? Do you run a website that uses OSM?
>
> Richard
> cycle.travel
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Richard Fairhurst]

Peter Elderson wrote:
> I think it's fair to say there is almost no software that does 
> anything with route relations except rendering and exporting 
> as a gpx.

That's not true. Most bike routers based on OSM are aware of route relations
and use them to influence routing.

> Software needs a sorted or easily sortable relation. Currently, 
> no software can handle sorting when the routes get broken. 

That's not true either. I have software right here that reorders unsorted
relations, as well as skeletonising dual carriageways into single lines,
jumping over roundabouts and coping with other such issues. I know of two
other sites operating similar software and I'm sure there are more.

There are certainly issues with consuming route relations but sorting is
not, in my pretty extensive experience, one of them.

Peter, perhaps you could clarify what your experience is in consuming OSM
data? Have you written code to do so? Do you run a website that uses OSM?

Richard
cycle.travel




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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

On Fri, Aug 16, 2019 at 1:40 PM s8evq  wrote:
> Just to be clear: are you still talking about hiking/walking routes? Or 
> public transport? Because, as far as I know, there is no clear explanation in 
> the wiki why forward/backward should be used in hiking routes.

I had one locally where the blazes were visible only on one direction.
(It was in OSM as a oneway route for a while, but I changed it when
they got around to painting them in the other direction.)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[s8evq]

On Fri, 16 Aug 2019 09:54:01 +0200, Jo  wrote:
> > By doing that, you're basically saying that alternatives can't have
> forward/backward roles. To me that doesn't make sense. We are using those
> forward/backward roles to indicate that there are 2 branches for each
> direction of travel along the route. This could easily happen along an
> alternative part of the route as well.
> 

Just to be clear: are you still talking about hiking/walking routes? Or public 
transport? Because, as far as I know, there is no clear explanation in the wiki 
why forward/backward should be used in hiking routes.

(except perhaps when there is a highway that is one way for foot? which is 
extremely rare)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend :

> On 16/08/2019 08:50, Peter Elderson wrote:
> > Josm of course. Is there another relation editor that can handle large
> nested route relations spanning up to say 4000 Km?
>
> P2 can, at least.  Other people seem to suggest that iD does a
> reasonable job now too.
>

Sorry to disagree. P2 and ID are aware of relations and can do a few basic
things like adding/removing a way and shifting a way up and down, in one
relation at a time. If you maintain a lot of long distance routes, that is
painfully inadequate. Even more so if you try to do it in a way that
prepares the relations for data users, currently meaning linear and gapless
gpx-es for use in navigation software, elevation profiles, and trip
planners. You need validation, gap detection, multiple relation windows
with shifting between windows, sorting, jump to first/last member,
direction reverse, download all members even those not in the bbox, ...


>
> The more interesting question, though, is "why do you want walking route
> relations to be sorted".  The point that's already been made about
> routes that use the same way twice is a valid one, but almost never
> applies to walking route relations.  What are you trying to do with e.g.
> https://www.openstreetmap.org/relation/1976184 (the part of E2* that
> runs through Yorkshire) if it's not sorted?
>
> If it's not sorted: display only. If I want to walk it, I want to use
OsmAnd navigation and or Garmin navigation. OsmAnd and Garmin currently
cannot use the relation directly, so I have to use a gpx, and they
recalculate the route for navigation. The gpx needs to be continous, sorted
and gapless, or it won't work. Overpass and Waymarkedtrails can export to a
routable gpx, if the relation is one sorted and continous chain of ways.
So before exporting, I use JOSM relation editor, load the entire thing,
solve all gaps en remove duplications, move alternatives one or more
separate relations, then export the main route as gpx.

I also notify the operator of the website
https://www.longdistancepaths.eu/en/
so he can use the export for his trip planner. If he could depend on routes
to be flawless in OSM he could connect directly to it for automatic
periodical refresh.

If the route is on that planner, I would probably use that first to plan
the trip and route according to train and bus stations, hotels & B's, and
places on the way, then export the trip gpx from that planner.

I will actually have a look at the E2 Yorkshire thing after lunch. I can
repair technical problems. If I need local survey I can probably not fix it
completely. Have to look at the history as well, don't want to offend
mappers over there with foreign ideas.

Best Regards,
>
> Andy
>
> * There are actually many other things wrong with that relation. It's
> not signed, so in a since here it "does not exist" but at the very least
> it should be tagged as such.  Also it's actually defined here in terms
> of the Wolds Way (which is signed), not in terms of individual paths.  I
> also doubt that the LDWA is in any sense an "operator".
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andy Townsend]

On 16/08/2019 08:50, Peter Elderson wrote:

Josm of course. Is there another relation editor that can handle large nested 
route relations spanning up to say 4000 Km?


P2 can, at least.  Other people seem to suggest that iD does a 
reasonable job now too.


The more interesting question, though, is "why do you want walking route 
relations to be sorted".  The point that's already been made about 
routes that use the same way twice is a valid one, but almost never 
applies to walking route relations.  What are you trying to do with e.g. 
https://www.openstreetmap.org/relation/1976184 (the part of E2* that 
runs through Yorkshire) if it's not sorted?


Best Regards,

Andy

* There are actually many other things wrong with that relation. It's 
not signed, so in a since here it "does not exist" but at the very least 
it should be tagged as such.  Also it's actually defined here in terms 
of the Wolds Way (which is signed), not in terms of individual paths.  I 
also doubt that the LDWA is in any sense an "operator".




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Both! If I enter a new route or alter it after survey, I often have to edit
ways. Cutting a way into sections, mostly. After a painful process of
making other people very unhappy, I finally know how to handle/repair all
the broken relations that causes, before uploading.

At the same time I notice that others do edits without repairing damage to
relations (not only routes, also turn restrictions). Most of these mappers
are not aware of the "damage", and if they are, they can't repair it. I
know many hiking people who start to make simple edits to the map on their
trips, but stop because of the trouble it causes.

Fr gr Peter Elderson


Op vr 16 aug. 2019 om 09:56 schreef Jo :

> Peter, I think Martin's question comes from a misunderstanding. You
> probably meant the route relations were broken by someone editing before
> you. Martin seems to have understood that you have to check all those route
> relations, after you edited them yourself.
>
> Jo
>
> On Fri, Aug 16, 2019 at 9:52 AM Peter Elderson 
> wrote:
>
>> Josm of course. Is there another relation editor that can handle large
>> nested route relations spanning up to say 4000 Km? In josm, before the edit
>> I open all the relations that may be affected, check if they are correct as
>> far as that section is concerned,  then perform the edit, then apply the
>> change to each relation and check again if all is well. When I am not in a
>> hurry and the affected relations have other gaps, I repair those as well.
>>
>> Mvg Peter Elderson
>>
>> > Op 16 aug. 2019 om 02:11 heeft Martin Koppenhoefer <
>> dieterdre...@gmail.com> het volgende geschreven:
>> >
>> >
>> >
>> > sent from a phone
>> >
>> >> On 16. Aug 2019, at 00:20, Peter Elderson  wrote:
>> >>
>> >> Not seldom I have to check and repair 10-15 route relations after one
>> edit (most often a split of a way to allow a route to attach there) on the
>> map.
>> >
>> >
>> > which editing software do you use?
>> >
>> >
>> > Cheers Martin
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jo]

Peter, I think Martin's question comes from a misunderstanding. You
probably meant the route relations were broken by someone editing before
you. Martin seems to have understood that you have to check all those route
relations, after you edited them yourself.

Jo

On Fri, Aug 16, 2019 at 9:52 AM Peter Elderson  wrote:

> Josm of course. Is there another relation editor that can handle large
> nested route relations spanning up to say 4000 Km? In josm, before the edit
> I open all the relations that may be affected, check if they are correct as
> far as that section is concerned,  then perform the edit, then apply the
> change to each relation and check again if all is well. When I am not in a
> hurry and the affected relations have other gaps, I repair those as well.
>
> Mvg Peter Elderson
>
> > Op 16 aug. 2019 om 02:11 heeft Martin Koppenhoefer <
> dieterdre...@gmail.com> het volgende geschreven:
> >
> >
> >
> > sent from a phone
> >
> >> On 16. Aug 2019, at 00:20, Peter Elderson  wrote:
> >>
> >> Not seldom I have to check and repair 10-15 route relations after one
> edit (most often a split of a way to allow a route to attach there) on the
> map.
> >
> >
> > which editing software do you use?
> >
> >
> > Cheers Martin
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jo]

On Thu, Aug 15, 2019 at 1:57 PM Sarah Hoffmann  wrote:

> Hi,
>
> (making this a new topic)
>
> On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote:
> > I strongly prefer to have one relation for the main route, and separate
> relations for alternatives. Put those together in a relation with roles for
> the member relations, not for individual ways. So the lowest level always
> contains only ways, the higher level contains only relations.
>
> Using subrelations is not consistent with the current use of
> forward/backward roles.
> I'd consider alternatives, excursions and access routes to be equivalent
> to those.
>
> By doing that, you're basically saying that alternatives can't have
forward/backward roles. To me that doesn't make sense. We are using those
forward/backward roles to indicate that there are 2 branches for each
direction of travel along the route. This could easily happen along an
alternative part of the route as well.

Polyglot
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Josm of course. Is there another relation editor that can handle large nested 
route relations spanning up to say 4000 Km? In josm, before the edit I open all 
the relations that may be affected, check if they are correct as far as that 
section is concerned,  then perform the edit, then apply the change to each 
relation and check again if all is well. When I am not in a hurry and the 
affected relations have other gaps, I repair those as well.

Mvg Peter Elderson

> Op 16 aug. 2019 om 02:11 heeft Martin Koppenhoefer  
> het volgende geschreven:
> 
> 
> 
> sent from a phone
> 
>> On 16. Aug 2019, at 00:20, Peter Elderson  wrote:
>> 
>> Not seldom I have to check and repair 10-15 route relations after one edit 
>> (most often a split of a way to allow a route to attach there) on the map.
> 
> 
> which editing software do you use?
> 
> 
> Cheers Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 16. Aug 2019, at 00:20, Peter Elderson  wrote:
> 
> Not seldom I have to check and repair 10-15 route relations after one edit 
> (most often a split of a way to allow a route to attach there) on the map.


which editing software do you use?


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Software needs a sorted or easily sortable relation. Currently, no software can 
handle sorting when the routes get broken. Routes with forward and backward 
roles don’t sort properly either. Routes get broken very easily all the time. 

Now the combine and sort routine waymarkedtrails uses when exporting routes 
actually does a fine job when e.g. a simple ordering problem is present. It 
fixes direction differences nicely. But if it encounters a more serious 
problem, it gives up and then all the simple things are not fixed either. So 
one wrong edit in Ireland can mess up the complete E2 over the entire length.

That’s why the only way to get reasonable outcome is to structure and sort the 
routes on the mapping level, then check and maintain all routes, all the time. 

Actually, nested relation are much easier for mappers to handle and maintain 
than long single ones. 

Roles in relations seem like a nice solution, but I don’t think it helps the 
sorting problem. Which in turn means no software can rely on Osm-route 
relations for other things than display.

I talk to many people about foot routes. I recommend waymarkedtrails, but when 
people want to use the gpx export I tell them to wait until I have checked and 
repaired the routes, or they will end up with a useless track that cannot be 
handled by a garmin or by OsmAnd.

Hardening against breaks? I would welcome that, but how? In Nederland, 
practically all ways are part of routes for walking, walking node connections, 
cycling, cycling node connections, PT. Not seldom I have to check and repair 
10-15 route relations after one edit (most often a split of a way to allow a 
route to attach there) on the map. If we simply prevent an edit if it breaks a 
route, we will lose a lot of mappers who simply want to maintain the road 
network.

Mvg Peter Elderson

> Op 15 aug. 2019 om 23:14 heeft Sarah Hoffmann  het volgende 
> geschreven:
> 
>> On Thu, Aug 15, 2019 at 04:50:26PM +0200, Peter Elderson wrote:
>> Sarah:
>>> There is relatively few software that can handle hierarchic relations.
>> One could argue that putting alternatives in separate relations makes it
>> actually harder to access those.
>> 
>> I think it's fair to say there is almost no software that does anything
>> with route relations except rendering and exporting as a gpx. Dislaying
>> elevation prophile is also one you can find, and it shows nicely what
>> inconsistency does: break up the prophile.  Rendering looks OK because in
>> the end you display the ways and it doesn't matter if they are out of
>> order, double, running in loops or whatever. For A to B navigation you need
>> single ordered chains without all the variations and reduplications.
> 
> There is a difference between what current software does and what software
> could reasonably do. Yes, software needs a sorted relation and it
> needs the information what the linear main route is and what diversions,
> alternaitves and accesses are and how they relate to the main route.
> Relations should contain enough information that software can extract
> the information with resonable efford and without resorting to guessing.
> But there is another side: relations are only useful when they are reasonably
> easy to maintain by mappers because otherwise there are no relations.
> 
> Now, sorting is a beast. I haven't found a way to support unsorted relations
> and guarantee a certain usefulness of the data even when relations get
> broken. I prefer hardning against data breakage. It's always a trade-off.
> 
> Adding alternatives, links etc. is a different matter. When they are marked
> with the proper role, than that is a very simple matter of filtering the
> members of a relation by their role. That is a very, very simple excercise
> for software. Much easier in fact than handling nested relations. So no need
> to burden the mapper with complications like nested relations. Just add the
> ways with the proper role and software can cope. We just need to come to
> an agreement between software and mappers what the roles mean. 
> 
> What I'd like to see clarified is: what roles can be expected and when should
> be used, i.e. I think we should make it clear that only a signed
> alternative/excursion/access is eligible. And even there are some nuances:
> is a single sign-post sufficient or should there be the same trailblazing
> along the path as for the main route.
> 
>> If that can be done at mapping level, datausing software could actually be
>> made to work with that. Now you can only export a track (losing the map
>> info), strip it in an editor to create your own route, and then move it to
>> the routing or planning software which then recombines it with a map.
>> That's why I say:
>> 1. Routes with only ways OR only part relations
> 
> I agree but more for making life of mappers easier.
> 
>> 2. No double ways
> 
> That cannot be avoided. There are routes that go past the same way twice.
> These routes should be mapped as they are.

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

[Sarah Hoffmann]

On Thu, Aug 15, 2019 at 04:50:26PM +0200, Peter Elderson wrote:
> Sarah:
> > There is relatively few software that can handle hierarchic relations.
> One could argue that putting alternatives in separate relations makes it
> actually harder to access those.
> 
> I think it's fair to say there is almost no software that does anything
> with route relations except rendering and exporting as a gpx. Dislaying
> elevation prophile is also one you can find, and it shows nicely what
> inconsistency does: break up the prophile.  Rendering looks OK because in
> the end you display the ways and it doesn't matter if they are out of
> order, double, running in loops or whatever. For A to B navigation you need
> single ordered chains without all the variations and reduplications.

There is a difference between what current software does and what software
could reasonably do. Yes, software needs a sorted relation and it
needs the information what the linear main route is and what diversions,
alternaitves and accesses are and how they relate to the main route.
Relations should contain enough information that software can extract
the information with resonable efford and without resorting to guessing.
But there is another side: relations are only useful when they are reasonably
easy to maintain by mappers because otherwise there are no relations.

Now, sorting is a beast. I haven't found a way to support unsorted relations
and guarantee a certain usefulness of the data even when relations get
broken. I prefer hardning against data breakage. It's always a trade-off.

Adding alternatives, links etc. is a different matter. When they are marked
with the proper role, than that is a very simple matter of filtering the
members of a relation by their role. That is a very, very simple excercise
for software. Much easier in fact than handling nested relations. So no need
to burden the mapper with complications like nested relations. Just add the
ways with the proper role and software can cope. We just need to come to
an agreement between software and mappers what the roles mean. 

What I'd like to see clarified is: what roles can be expected and when should
be used, i.e. I think we should make it clear that only a signed
alternative/excursion/access is eligible. And even there are some nuances:
is a single sign-post sufficient or should there be the same trailblazing
along the path as for the main route.

> If that can be done at mapping level, datausing software could actually be
> made to work with that. Now you can only export a track (losing the map
> info), strip it in an editor to create your own route, and then move it to
> the routing or planning software which then recombines it with a map.
> That's why I say:
> 1. Routes with only ways OR only part relations

I agree but more for making life of mappers easier.

> 2. No double ways

That cannot be avoided. There are routes that go past the same way twice.
These routes should be mapped as they are.

> 3. Always have one single strand main route; alternatives as separate
> single strand routes.

That's not possible unless you want to resort to separate relations for
backward and forward direction. (Think one-way streets along cycling
routes.) And we know to what kinds of hells that has led for PT mapping.

Sarah
(aka lonvia, maintainer of waymarkedtrails)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Sarah:
> There is relatively few software that can handle hierarchic relations.
One could argue that putting alternatives in separate relations makes it
actually harder to access those.

I think it's fair to say there is almost no software that does anything
with route relations except rendering and exporting as a gpx. Dislaying
elevation prophile is also one you can find, and it shows nicely what
inconsistency does: break up the prophile.  Rendering looks OK because in
the end you display the ways and it doesn't matter if they are out of
order, double, running in loops or whatever. For A to B navigation you need
single ordered chains without all the variations and reduplications.

If that can be done at mapping level, datausing software could actually be
made to work with that. Now you can only export a track (losing the map
info), strip it in an editor to create your own route, and then move it to
the routing or planning software which then recombines it with a map.

That's why I say:
1. Routes with only ways OR only part relations
2. No double ways
3. Always have one single strand main route; alternatives as separate
single strand routes.
4 If need be, put them together in a master relation which does NOT have to
be single strand, it's mainly there for the common tags. (This could
support network planners/routers).
5. Roles of alternative routes in the master relation could be used to
adapt display. Maybe it's easier to apply a role tag within the relation
itself to alter display of that relation, don't know.

If you have a subrelation which is part of multiple parent relations, roles
could conflict. Could be main route in one, excursion in another and link
in a third


Fr gr Peter Elderson


Op do 15 aug. 2019 om 13:57 schreef Sarah Hoffmann :

> Hi,
>
> (making this a new topic)
>
> On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote:
> > I strongly prefer to have one relation for the main route, and separate
> relations for alternatives. Put those together in a relation with roles for
> the member relations, not for individual ways. So the lowest level always
> contains only ways, the higher level contains only relations.
>
> Using subrelations is not consistent with the current use of
> forward/backward roles.
> I'd consider alternatives, excursions and access routes to be equivalent
> to those.
>
> > The ways in the main relation should form one continuous sorted
> (sortable) route, which data users can extract or link to for navigation or
> planner software.
>
> There is relatively few software that can handle hierarchic relations.
> One could argue that putting alternatives in separate relations makes
> it actually harder to access those.
>
> In the end, it doesn't really matter if you put the role on way or
> relation members. I'd just allow both. (Although I agree that ways and
> relation member shouldn't be mixed in a single relation.)
>
> The more important part is to agree on a couple of roles so that
> mappers and software know what to use.
>
> I did a quick count and that's what is in use most currently for roles
> on hiking routes:
>
> alternatives:  alternative(117), alternate(105)
> side paths:excursion(166)
> access paths:  link(85)
>
> and for cycling:
>
> alternatives:  alternative(74), alternate(64)
> side paths:detour(25)
> access paths:  link(78), connection(52)
>
> NB: They are used almost exclusively on way members.
>
> Sarah
>
> >
> > Note that rendering routes is not that critical, but data use is
> increasingly important.
> >
> > Fr gr Peter Elderson
> >
> > > Op 15 aug. 2019 om 09:35 heeft Warin <61sundow...@gmail.com> het
> volgende geschreven:
> > >
> > >> On 15/08/19 17:00, Peter Elderson wrote:
> > >> Where/to what exactly do you apply the role?
> > >
> > > In the relation.
> > >
> > > See https://www.openstreetmap.org/relation/1388126
> > >
> > > Here the 'normal' members are simple ways with no role, these form the
> route itself.
> > >
> > > Those that have a relationship role of 'alternate' in this instance
> are relations themselves but the could be more simple ways.
> > > These form alternate routes to the main route.
> > > They could be for any number of reasons - hight tides or flooded
> rivers.
> > > In this case the Hornsby original goes through a firing range, Little
> Wobbly is a cheaper alternative to a private water taxi,
> > > the other I am not certain of, possibly an 'access tack' from a train
> station - I would have to look.
> > >
> > > Note I am not the author here of 'alternate', but I have done some
> work on the OSM route.
> > >
> > >>
> > >> Mvg Peter Elderson
> > >>
> > >>> Op 15 aug. 2019 om 01:20 heeft Warin <61sundow...@gmail.com> het
> volgende geschreven:
> > >>>
> > >>> It would be usefull to document the method of  including alternate,
> side trips and access tracks to these routes.
> > >>>
> > >>> At the moment I and others are using the role 'alternate' for track
> alternative paths.
> > >>>
> > >>> For 'side 

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

[Sarah Hoffmann]

Hi,

(making this a new topic)

On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote:
> I strongly prefer to have one relation for the main route, and separate 
> relations for alternatives. Put those together in a relation with roles for 
> the member relations, not for individual ways. So the lowest level always 
> contains only ways, the higher level contains only relations. 

Using subrelations is not consistent with the current use of forward/backward 
roles.
I'd consider alternatives, excursions and access routes to be equivalent
to those.

> The ways in the main relation should form one continuous sorted (sortable) 
> route, which data users can extract or link to for navigation or planner 
> software.

There is relatively few software that can handle hierarchic relations.
One could argue that putting alternatives in separate relations makes
it actually harder to access those.

In the end, it doesn't really matter if you put the role on way or
relation members. I'd just allow both. (Although I agree that ways and
relation member shouldn't be mixed in a single relation.)

The more important part is to agree on a couple of roles so that
mappers and software know what to use.

I did a quick count and that's what is in use most currently for roles
on hiking routes:

alternatives:  alternative(117), alternate(105)
side paths:excursion(166)
access paths:  link(85)

and for cycling:

alternatives:  alternative(74), alternate(64)
side paths:detour(25)
access paths:  link(78), connection(52)

NB: They are used almost exclusively on way members.

Sarah

> 
> Note that rendering routes is not that critical, but data use is increasingly 
> important.
> 
> Fr gr Peter Elderson
> 
> > Op 15 aug. 2019 om 09:35 heeft Warin <61sundow...@gmail.com> het volgende 
> > geschreven:
> > 
> >> On 15/08/19 17:00, Peter Elderson wrote:
> >> Where/to what exactly do you apply the role?
> > 
> > In the relation.
> > 
> > See https://www.openstreetmap.org/relation/1388126
> > 
> > Here the 'normal' members are simple ways with no role, these form the 
> > route itself.
> > 
> > Those that have a relationship role of 'alternate' in this instance are 
> > relations themselves but the could be more simple ways.
> > These form alternate routes to the main route.
> > They could be for any number of reasons - hight tides or flooded rivers.
> > In this case the Hornsby original goes through a firing range, Little 
> > Wobbly is a cheaper alternative to a private water taxi,
> > the other I am not certain of, possibly an 'access tack' from a train 
> > station - I would have to look.
> > 
> > Note I am not the author here of 'alternate', but I have done some work on 
> > the OSM route.
> > 
> >> 
> >> Mvg Peter Elderson
> >> 
> >>> Op 15 aug. 2019 om 01:20 heeft Warin <61sundow...@gmail.com> het volgende 
> >>> geschreven:
> >>> 
> >>> It would be usefull to document the method of  including alternate, side 
> >>> trips and access tracks to these routes.
> >>> 
> >>> At the moment I and others are using the role 'alternate' for track 
> >>> alternative paths.
> >>> 
> >>> For 'side trips' (short paths to features of interest) possibly the role 
> >>> 'side_trip'?
> >>> 
> >>> For 'access tracks' (paths from common and signed places that leas to teh 
> >>> main track) possibly the role 'access_track'?
> >>> 
> >>> 
>  On 13/08/19 18:50, s8evq wrote:
>  Hello everyone,
>  
>  On the discussion page of the wiki entry Hiking 
>  (https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme.)
>   I have started a topic, but with little response so far. That's why I 
>  come here, before proceeding.
>  
>  
>  Currently, there are four tagging scheme tables describing how walking 
>  (or hiking) routes should be tagged.
>  https://wiki.openstreetmap.org/wiki/Hiking
>  https://wiki.openstreetmap.org/wiki/Walking_Routes
>  https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking
>  https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot
>  
>  Would it not be easier and more clear if we just keep one, and add a 
>  link to it in the others?
>  
>  Last month, I already started harmonizing these four tagging scheme 
>  tables. I changed the order, added some missing tags, adjusted the 
>  explanation etc... In my view, I only had to do minor edits. For those 
>  interested, here are my edits:
>  
>  https://wiki.openstreetmap.org/w/index.php?title=Hiking=revision=1878387=1873054
>  https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes=revision=1881156=1879580
>  https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking=revision=1878383=1853636
>  https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot=revision=1878384=1853797
>  
>  So these four tagging scheme tables are now almost 100% the