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

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

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 <[hidden email]> 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 <[hidden email]> 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&type=revision&diff=1878387&oldid=1873054
> >>>> https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes&type=revision&diff=1881156&oldid=1879580
> >>>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking&type=revision&diff=1878383&oldid=1853636
> >>>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot&type=revision&diff=1878384&oldid=1853797
> >>>>
> >>>> So these four tagging scheme tables are now almost 100% the same.
> >>>>
> >>>>
> >>>> My idea was to keep the tagging scheme table on one of the wiki pages, and put a link to it on the three other pages. I would like to have broader support before going further.
> >>>>
> >>>>
> >>>> Of course, we can discuss about the content of the tagging scheme. But that's irrelevant to my question about the organization of the wiki page.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>>
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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&type=revision&diff=1878387&oldid=1873054
> >>>> https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes&type=revision&diff=1881156&oldid=1879580
> >>>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking&type=revision&diff=1878383&oldid=1853636
> >>>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot&type=revision&diff=1878384&oldid=1853797
> >>>>
> >>>> So these four tagging scheme tables are now almost 100% the same.
> >>>>
> >>>>
> >>>> My idea was to keep the tagging scheme table on one of the wiki pages, and put a link to it on the three other pages. I would like to have broader support before going further.
> >>>>
> >>>>
> >>>> Of course, we can discuss about the content of the tagging scheme. But that's irrelevant to my question about the organization of the wiki page.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>>
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > [hidden email]
> > https://lists.openstreetmap.org/listinfo/tagging
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

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

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

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

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

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

Peter Elderson
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 <[hidden email]> 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.
>
>> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

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

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

dieterdreist


sent from a phone

> On 16. Aug 2019, at 00:20, Peter Elderson <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
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 <[hidden email]> het volgende geschreven:
>
>
>
> sent from a phone
>
>> On 16. Aug 2019, at 00:20, Peter Elderson <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

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

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

Jo-2
In reply to this post by Sarah Hoffmann


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

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

Jo-2
In reply to this post by Peter Elderson
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 <[hidden email]> 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 <[hidden email]> het volgende geschreven:
>
>
>
> sent from a phone
>
>> On 16. Aug 2019, at 00:20, Peter Elderson <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

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

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

Re: 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> het volgende geschreven:
>
>
>
> sent from a phone
>
>> On 16. Aug 2019, at 00:20, Peter Elderson <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

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

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

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

Andy Townsend
In reply to this post by Peter Elderson
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend <[hidden email]>:
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&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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

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

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

Peter Elderson
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.
b. 10 gaps. Needs investigating the cause; some just reflect wrong order.
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.
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). 

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?

Fr gr Peter Elderson


Op vr 16 aug. 2019 om 12:09 schreef Peter Elderson <[hidden email]>:
Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend <[hidden email]>:
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&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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

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

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

s8evq
In reply to this post by Jo-2

On Fri, 16 Aug 2019 09:54:01 +0200, Jo <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Kevin Kenny-3
On Fri, Aug 16, 2019 at 1:40 PM s8evq <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Richard Fairhurst
In reply to this post by Peter Elderson
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
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 <[hidden email]>:
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

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

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

Warin
In reply to this post by Peter Elderson
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 <[hidden email]>:
Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend <[hidden email]>:
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&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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
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 <[hidden email]>:
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 <[hidden email]>:
Op vr 16 aug. 2019 om 10:59 schreef Andy Townsend <[hidden email]>:
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&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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

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

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

Richard Fairhurst
In reply to this post by Peter Elderson
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 <x>", "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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Andy Townsend
In reply to this post by Peter Elderson
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12345