<div dir="ltr">Sarah:<div>> 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.  </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>That's why I say: </div><div>1. Routes with only ways OR only part relations</div><div>2. No double ways</div><div>3. Always have one single strand main route; alternatives as separate single strand routes. </div><div>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).<br></div><div>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. </div><div><br></div><div>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....</div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Fr gr Peter Elderson</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op do 15 aug. 2019 om 13:57 schreef Sarah Hoffmann <<a href="mailto:lonvia@denofr.de">lonvia@denofr.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
(making this a new topic)<br>
<br>
On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote:<br>
> 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. <br>
<br>
Using subrelations is not consistent with the current use of forward/backward roles.<br>
I'd consider alternatives, excursions and access routes to be equivalent<br>
to those.<br>
<br>
> 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.<br>
<br>
There is relatively few software that can handle hierarchic relations.<br>
One could argue that putting alternatives in separate relations makes<br>
it actually harder to access those.<br>
<br>
In the end, it doesn't really matter if you put the role on way or<br>
relation members. I'd just allow both. (Although I agree that ways and<br>
relation member shouldn't be mixed in a single relation.)<br>
<br>
The more important part is to agree on a couple of roles so that<br>
mappers and software know what to use.<br>
<br>
I did a quick count and that's what is in use most currently for roles<br>
on hiking routes:<br>
<br>
alternatives:  alternative(117), alternate(105)<br>
side paths:    excursion(166)<br>
access paths:  link(85)<br>
<br>
and for cycling:<br>
<br>
alternatives:  alternative(74), alternate(64)<br>
side paths:    detour(25)<br>
access paths:  link(78), connection(52)<br>
<br>
NB: They are used almost exclusively on way members.<br>
<br>
Sarah<br>
<br>
> <br>
> Note that rendering routes is not that critical, but data use is increasingly important.<br>
> <br>
> Fr gr Peter Elderson<br>
> <br>
> > Op 15 aug. 2019 om 09:35 heeft Warin <<a href="mailto:61sundowner@gmail.com" target="_blank">61sundowner@gmail.com</a>> het volgende geschreven:<br>
> > <br>
> >> On 15/08/19 17:00, Peter Elderson wrote:<br>
> >> Where/to what exactly do you apply the role?<br>
> > <br>
> > In the relation.<br>
> > <br>
> > See <a href="https://www.openstreetmap.org/relation/1388126" rel="noreferrer" target="_blank">https://www.openstreetmap.org/relation/1388126</a><br>
> > <br>
> > Here the 'normal' members are simple ways with no role, these form the route itself.<br>
> > <br>
> > Those that have a relationship role of 'alternate' in this instance are relations themselves but the could be more simple ways.<br>
> > These form alternate routes to the main route.<br>
> > They could be for any number of reasons - hight tides or flooded rivers.<br>
> > In this case the Hornsby original goes through a firing range, Little Wobbly is a cheaper alternative to a private water taxi,<br>
> > the other I am not certain of, possibly an 'access tack' from a train station - I would have to look.<br>
> > <br>
> > Note I am not the author here of 'alternate', but I have done some work on the OSM route.<br>
> > <br>
> >> <br>
> >> Mvg Peter Elderson<br>
> >> <br>
> >>> Op 15 aug. 2019 om 01:20 heeft Warin <<a href="mailto:61sundowner@gmail.com" target="_blank">61sundowner@gmail.com</a>> het volgende geschreven:<br>
> >>> <br>
> >>> It would be usefull to document the method of  including alternate, side trips and access tracks to these routes.<br>
> >>> <br>
> >>> At the moment I and others are using the role 'alternate' for track alternative paths.<br>
> >>> <br>
> >>> For 'side trips' (short paths to features of interest) possibly the role 'side_trip'?<br>
> >>> <br>
> >>> For 'access tracks' (paths from common and signed places that leas to teh main track) possibly the role 'access_track'?<br>
> >>> <br>
> >>> <br>
> >>>> On 13/08/19 18:50, s8evq wrote:<br>
> >>>> Hello everyone,<br>
> >>>> <br>
> >>>> On the discussion page of the wiki entry Hiking (<a href="https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme</a>.) I have started a topic, but with little response so far. That's why I come here, before proceeding.<br>
> >>>> <br>
> >>>> <br>
> >>>> Currently, there are four tagging scheme tables describing how walking (or hiking) routes should be tagged.<br>
> >>>> <a href="https://wiki.openstreetmap.org/wiki/Hiking" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Hiking</a><br>
> >>>> <a href="https://wiki.openstreetmap.org/wiki/Walking_Routes" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Walking_Routes</a><br>
> >>>> <a href="https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking</a><br>
> >>>> <a href="https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot</a><br>
> >>>> <br>
> >>>> Would it not be easier and more clear if we just keep one, and add a link to it in the others?<br>
> >>>> <br>
> >>>> 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:<br>
> >>>> <br>
> >>>> <a href="https://wiki.openstreetmap.org/w/index.php?title=Hiking&type=revision&diff=1878387&oldid=1873054" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/w/index.php?title=Hiking&type=revision&diff=1878387&oldid=1873054</a><br>
> >>>> <a href="https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes&type=revision&diff=1881156&oldid=1879580" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes&type=revision&diff=1881156&oldid=1879580</a><br>
> >>>> <a href="https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking&type=revision&diff=1878383&oldid=1853636" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking&type=revision&diff=1878383&oldid=1853636</a><br>
> >>>> <a href="https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot&type=revision&diff=1878384&oldid=1853797" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot&type=revision&diff=1878384&oldid=1853797</a><br>
> >>>> <br>
> >>>> So these four tagging scheme tables are now almost 100% the same.<br>
> >>>> <br>
> >>>> <br>
> >>>> 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.<br>
> >>>> <br>
> >>>> <br>
> >>>> 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.<br>
> >>>> <br>
> >>>> <br>
> >>>> <br>
> >>>> <br>
> >>>> _______________________________________________<br>
> >>>> <br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > Tagging mailing list<br>
> > <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
> > <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
> <br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>