<div dir="ltr"><h2 style="color:rgb(0,0,0);background-image:none;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial;font-weight:normal;margin:1em 0px 0.25em;overflow:hidden;padding:0px;border-bottom:1px solid rgb(162,169,177);font-family:"Linux Libertine",Georgia,Times,serif;line-height:1.3"><span class="gmail-mw-headline" id="gmail-Use_of_Subrelations_and_Superrelations">Use of Subrelations and Superrelations</span><span class="gmail-mw-editsection" style="font-size:small;margin-left:1em;vertical-align:baseline;line-height:1em;font-family:sans-serif;white-space:nowrap;unicode-bidi:isolate"><span class="gmail-mw-editsection-bracket" style="margin-right:0.25em;color:rgb(84,89,93)">[</span><a href="https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposed_features/hiking_trail_relation_roles&action=edit&section=9" title="Abschnitt bearbeiten: Use of Subrelations and Superrelations" style="text-decoration-line:none;color:rgb(11,0,128);background:none">Quelltext bearbeiten</a><span class="gmail-mw-editsection-bracket" style="margin-left:0.25em;color:rgb(84,89,93)">]</span></span></h2><p style="margin:0.5em 0px;line-height:inherit;font-family:sans-serif;font-size:14px">Some user requested to use subrelations to map parts of hiking trail and then assign a role to the subrelation instead of each member of this subrelation. In some cases this makes a lot of sense (long alternatives) however in other cases (an excursion trail to a viewpoint made up of two ways) it seems a little overdone.</p><p style="margin:0.5em 0px;line-height:inherit;font-family:sans-serif;font-size:14px">My suggestion would be to establish a system that is able to handle both ways of mapping at once.</p><div class="gmail-thumb gmail-tright" style="clear:right;float:right;margin:0.5em 0px 1.3em 1.4em;width:auto;font-family:sans-serif;font-size:14px"><div class="gmail-thumbinner" style="border:1px solid rgb(200,204,209);padding:3px;background-color:rgb(248,249,250);font-size:13.16px;text-align:center;overflow:hidden;width:302px"><a href="https://wiki.openstreetmap.org/wiki/File:Proposed_hierarchic_structure_of_hiking_relation_.jpg" class="gmail-image" style="text-decoration-line:none;color:rgb(11,0,128);background:none"><img alt="Proposed hierarchic structure of hiking relation .jpg" src="https://wiki.openstreetmap.org/w/images/thumb/1/1c/Proposed_hierarchic_structure_of_hiking_relation_.jpg/300px-Proposed_hierarchic_structure_of_hiking_relation_.jpg" width="300" height="208" class="gmail-thumbimage" style="border: 1px solid rgb(200, 204, 209); vertical-align: middle; background-color: rgb(255, 255, 255);"></a><div class="gmail-thumbcaption" style="border:0px;line-height:1.4em;padding:3px;font-size:12.3704px;text-align:left"><div class="gmail-magnify" style="float:right;margin-left:3px;margin-right:0px"><a href="https://wiki.openstreetmap.org/wiki/File:Proposed_hierarchic_structure_of_hiking_relation_.jpg" class="gmail-internal" title="vergrößern" style="text-decoration-line:none;color:rgb(11,0,128);background-color:initial;display:block;text-indent:15px;white-space:nowrap;overflow:hidden;width:15px;height:11px"></a></div></div></div></div><p style="margin:0.5em 0px;line-height:inherit;font-family:sans-serif;font-size:14px">This diagram should help to better visualise the structure.</p><ul style="margin:0.3em 0px 0px 1.6em;padding:0px;font-family:sans-serif;font-size:14px"><li style="margin-bottom:0.1em">The squares are relations which can contain further subrelations or</li><li style="margin-bottom:0.1em">ways which are displayed as smaller circles.</li><li style="margin-bottom:0.1em">The yellow circles are tagged with the role main. That means that they are part of the main hiking trail.</li><li style="margin-bottom:0.1em">If you want to extract the main hiking trail from this hierarchic structure, you have to flaten out the hole structure into one big one-dimensional list of ways. That means that you follow down the hierarchie until you find the first way and then take the next one. This is called <a href="http://en.wikipedia.org/wiki/depth-first_search" class="extiw" title="wikipedia:depth-first search" style="text-decoration-line:none;color:rgb(102,51,102);background:none">depth-first_search</a>. An example is also indicated by the red line in the diagram. After that you ignore everything that is not a way and is not tagged with the role main (forward and backward can be considered later). This should give us a linear route that contains all elements from the main route in the correct direction.</li><li style="margin-bottom:0.1em">The three white ways in the bottom right corner could be an alternative. For everything to be neat and tidy it has been put into a subrelation. Because it is just not tagged with the main role it has simply been ignored when we tried to figure the main trail out.</li><li style="margin-bottom:0.1em">The fourth way in our main relation is also white. This one represents a short and very simple excursion to a viewpoint. This one is also ignored in the main trail procedure</li></ul><p style="margin:0.5em 0px;line-height:inherit;font-family:sans-serif;font-size:14px">Additionally roles can also be assigned to relations. In this case all the elements in this relation which don't have a role inherit the role from their relation. With this feature it is possible to create a relation with all the paths of an alternative and only assign the role to the newly created relation. Still, all the ways are considered as alternatives.</p><p style="margin:0.5em 0px;line-height:inherit;font-family:sans-serif;font-size:14px">In this way both of the possible ways to map hiking trails are combined into one way.--<a href="https://wiki.openstreetmap.org/wiki/User:Mfbehrens99" title="User:Mfbehrens99" style="text-decoration-line:none;color:rgb(11,0,128);background:none">Mfbehrens99</a> (<a href="https://wiki.openstreetmap.org/wiki/User_talk:Mfbehrens99" title="User talk:Mfbehrens99" style="text-decoration-line:none;color:rgb(11,0,128);background:none">talk</a>) 14:17, 8 December 2019 (UTC)</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am So., 8. Dez. 2019 um 13:21 Uhr schrieb Michael Behrens <<a href="mailto:mfbehrens99@gmail.com">mfbehrens99@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="auto"><div>I fully agree with this argument and I also wrote a comment on the Wiki Talk page.</div><div dir="auto"><br></div><div dir="auto">What do you thing about using main:forward, main:backward, alternative:forward and alternative:backward. </div><div dir="auto"><br></div><div dir="auto">Another problem is that whenever there the main trail has a forward or backward we automatically have two main trails what could be considered as alternative. However now you can still create a elevation profile from the main route. One for forward and one for backwards.</div><div dir="auto"><br></div><div dir="auto">Michael<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, 8 Dec 2019, 10:48 Mateusz Konieczny, <<a href="mailto:matkoniecz@tutanota.com" target="_blank">matkoniecz@tutanota.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">
  
    
  
  <div>
<div>What about routes that have oneway segments, without paths having a legal restrictions<br></div><div>on direction of walking?<br></div><div><br></div><div>6 Dec 2019, 19:28 by <a href="mailto:janjko@gmail.com" rel="noreferrer" target="_blank">janjko@gmail.com</a>:<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div dir="ltr"><div>I think the "forward" and "backward" don't belong in a role of a relation. Oneway=yes on a way should be enough. In the Wiki discussion it is said that if there is one little "oneway" way in a big branch, then all the ways in a branch should be checked to see if the whole branch is oneway. But that means we are doing the work of a router directly in the tags.<br></div><div><br></div><div>We should just mark "oneway" ways as such, and leave the rest to the routers.<br></div><div><br></div><div>Also, "main" and "alternative" are orthogonal to "forward" and "backward". We should then have "main:forward", "alternative:backward", and so on. That doesn't make sense, and is not what "role" is traditionally used for. Public transport routes used to use them, but not in the new scheme.<br></div></div><div><br></div><div>Janko<br></div></div></blockquote><div><br></div>  </div>

_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" rel="noreferrer" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div></div></div>
</blockquote></div>