[Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

Michael Behrens mfbehrens99 at gmail.com
Sun Dec 8 14:25:02 UTC 2019

Use of Subrelations and Superrelations[Quelltext bearbeiten

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]

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 <
mfbehrens99 at 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, <matkoniecz at 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 janjko at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20191208/77fd21d8/attachment.html>

More information about the Tagging mailing list