Use of Subrelations and Superrelations[Quelltext bearbeiten <https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposed_features/hiking_trail_relation_roles&action=edit§ion=9> ]
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. My suggestion would be to establish a system that is able to handle both ways of mapping at once. [image: Proposed hierarchic structure of hiking relation .jpg] <https://wiki.openstreetmap.org/wiki/File:Proposed_hierarchic_structure_of_hiking_relation_.jpg> <https://wiki.openstreetmap.org/wiki/File:Proposed_hierarchic_structure_of_hiking_relation_.jpg> This diagram should help to better visualise the structure. - The squares are relations which can contain further subrelations or - ways which are displayed as smaller circles. - The yellow circles are tagged with the role main. That means that they are part of the main hiking trail. - 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 depth-first_search <http://en.wikipedia.org/wiki/depth-first_search>. 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. - 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. - 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 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. In this way both of the possible ways to map hiking trails are combined into one way.--Mfbehrens99 <https://wiki.openstreetmap.org/wiki/User:Mfbehrens99> (talk <https://wiki.openstreetmap.org/wiki/User_talk:Mfbehrens99>) 14:17, 8 December 2019 (UTC) Am So., 8. Dez. 2019 um 13:21 Uhr schrieb Michael Behrens < mfbehren...@gmail.com>: > I fully agree with this argument and I also wrote a comment on the Wiki > Talk page. > > What do you thing about using main:forward, main:backward, > alternative:forward and alternative:backward. > > 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. > > Michael > > On Sun, 8 Dec 2019, 10:48 Mateusz Konieczny, <matkoni...@tutanota.com> > wrote: > >> What about routes that have oneway segments, without paths having a legal >> restrictions >> on direction of walking? >> >> 6 Dec 2019, 19:28 by jan...@gmail.com: >> >> 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. >> >> We should just mark "oneway" ways as such, and leave the rest to the >> routers. >> >> 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. >> >> Janko >> >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
