<div dir="ltr"><span id="gmail-docs-internal-guid-c1759b80-7fff-0139-7eee-05efb175f866"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">I think the proposal is not ready for use or for voting, but there does not seem to be much progress.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The basics are clear enough I think.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Though I myself would have made things even simpler (e.g. not bother with functions like approach or excursion, but simply use alternative and branch as  roles), I am toying with the idea to move forward and start adding the roles:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">alternative</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">, </span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">approach</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> and </span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">excursion</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> for wellknown hiking routes in Nederland, next time I do a regular consistency check on the lot. No role=main, It’s up to me to ensure that one main route is present when alle the special roles are filtered out.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">I would not use forward and backward roles as these conflict with how they are used in cycling routes. I prefer all recreational routes to use the same (or at least compatible) tagging scheme. Same with all the other suggested refinements and niceties involving access, direction, starting points, POI’s and what have you: I see too many complications.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">I would use the roles on relation type members, not on way members. This way the maintenance burden is low. Most hiking routes in Nederland have been  sectioned and alternatives/branches already are separate relations. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">This basic role tagging would not conflict with current usage, and it would not affect current non-role renderings. It would be useful for rendering alternatives and branches differently e.g. dashed or dotted.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Worst case, nobody follows and I wil lose a few hours of work. Best case, some renderers might think “hey, that’s neat!” and start using the roles. Middle case, renderers test it and give useful feedback for a better proposal. If this proposal would lead to different roles, I could simply alter the roles in the course of regular route maintenance.</span></p></span><br class="gmail-Apple-interchange-newline"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Peter Elderson<br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op vr 28 feb. 2020 om 18:07 schreef Peter Elderson <<a href="mailto:pelderson@gmail.com">pelderson@gmail.com</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"><div dir="ltr">+1 for stating more clearly What to map and What NOT to map. <div><br></div><div>The first goal of the proposal, I think, is to separate the main (linear or circular) route from the extras, for display and some data use (e.g. export, length calculation and elevation profile). </div><div>Then render the extras as dashed route lines or something, but exclude those from calculations and main export. </div><div><br></div><div><div><div><div dir="ltr">Best, Peter Elderson</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op vr 28 feb. 2020 om 12:29 schreef Andrew Harvey <<a href="mailto:andrew.harvey4@gmail.com" target="_blank">andrew.harvey4@gmail.com</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"><div dir="ltr">I agree with Peter, it'll probably be better to start with the basics, get that approved so at least there is some improvement, then move forward with the more complicated parts of the proposal.<div><br></div><div>In terms of the role names proposed I noticed that it is a very similar to a schema I came up with for creating hiking routes from OSM data, <a href="https://gitlab.com/beyondtracks/beyondtracks-walks#ways" target="_blank">https://gitlab.com/beyondtracks/beyondtracks-walks#ways</a>. I have role=primary (main), sidetrack (excursion), altroute (alternate), transit_connection (approach) and find this covers most of what you need to represent.<div><br></div><div>Though I think the proposal needs more emphasis that these should only be mapped if these alternate routes,excursions or approaches are verifiable on the ground through signage, otherwise it's subjective based on opinion. It already says "Only add secondary trails to the relation that are really part of the trail route, not made up or other trail routes." but I think it needs to be clearer.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 28 Feb 2020 at 21:07, s8evq <<a href="mailto:s8evqq@runbox.com" target="_blank">s8evqq@runbox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
What is the status of this proposal? Should we go forward and start voting?<br>
Lots of people have added valuable information and insight. It would be a pity if this proposal yet again stays in "Draft" status for forever. <br>
<br>
On Fri, 6 Dec 2019 10:15:31 +0000, Michael Behrens <<a href="mailto:mfbehrens99@gmail.com" target="_blank">mfbehrens99@gmail.com</a>> wrote:<br>
<br>
> <a href="https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Proposed_features/hiking_trail_relation_roles</a><br>
> <br>
> <br>
> <br>
> There is no unique way to tag roles in hiking route relations although they<br>
> carry a high potential for the rendering of hiking trails. This proposal<br>
> was requsted by Sarah Hoffmann on the FOSSGIS conference. A only officially<br>
> marked trails should be added to the relations!<br>
> <br>
> Role nameExplaination<br>
> *None* or main The main "normal" roletype for the main section of the<br>
> hiking trails.<br>
> forward Section of the hiking trail that can only be hiked into the<br>
> direction of the way.<br>
> backward Section of the hiking trail that can only be hiked against the<br>
> direction of the way.<br>
> alternative or alternate Tags the members of an alternative path to *main*<br>
>  path.<br>
> excursion Can be used on parts of the trail that leads to a viewpoint, peak<br>
> or other. The path has to be hiked back again or else it will be a<br>
> *alternative*.<br>
> approach A path that is leading from a town, train station / bus station or<br>
> parking to main hiking trail or the other way around.<br>
> shortcut A trail that shortens the main trail.<br>
> <br>
> Please write comments here:<br>
> <a href="https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hiking_trail_relation_roles</a><br>
> <br>
> Greeting<br>
> Michael<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>
<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>
_______________________________________________<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></div>
</blockquote></div>