[Tagging] Walking Routes, how to tag alternatives/additions/shortcuts/approach tracks etc.

Peter Elderson pelderson at gmail.com
Tue Apr 23 10:56:05 UTC 2019

Rendering is one thing. The other purpose I consider is routing, where you
need to have one continuous route. Currently, OSM route relations are not
routed directly, so the concern is to be able to produce singe-route
I think a branch way or branch route relation with role excursion does not
fit in that scheme.
Currently I make main route relations consisting of either a single chain
of ways, or a single chain of segment routes, resulting at the lowest level
in a single chain of ways. No branches, no shortcuts, no alternatives, no
doggy/scenic/wheelchair/hightide/seasonal routes, no additionals, no single
Beside that, I make a route relation containing all the variants (including
the main route). This is in fact more like a collection than a route. This
one is for rendering, not for routing. Here the member roles make sense to
me, to indicate main vs not-main. I think the reason why a member is not
main is not that important at this level.
Tagging a member segment to indicate purpose (seasonal, link, doggy) or an
attribute such as scenic, looks fine to me. When someone uses the segment
relation as a route in itself, the role is not there, but the functional
tag is.

If this makes sense for rendering as well as routing and single chain
exporting, I would like to agree on the values for a. role and b. the
route_segment key.
Where role should IMO not contain the reason for the segment, just how it
should be handled within the "superroute" relation, and route_segment
should indicate what is so special about this route relation.

Vr gr Peter Elderson

Op di 23 apr. 2019 om 09:47 schreef Sarah Hoffmann <lonvia at denofr.de>:

> Hi,
> On Mon, Apr 22, 2019 at 11:47:35PM +0200, Peter Elderson wrote:
> > Long walking routes often have a main route and several additions of
> > various types. If these additions are not waymarked, they are not
> recorded
> > in OSM. Easy.
> >
> > But often, they are. On maps these are usually shown as a striped line,
> > while the main route is usually a continuous line.
> That´s actually quite similar to the problem of sections and superroutes
> we had previously. They are basically sections that serve a special
> purpose.
> > I would like to enable OSMrenderers and data users to render/process the
> > additions/alternatives differently than the main route.
> >
> > One solution just for rendering would be to optionally add "striped" to
> the
> > colour tag. Or dotted.
> Please don't tag what you want to see rendered. Tag the function
> and then let the renderer decide how to show it.
> > A more general solution would be something like alternative=yes,
> > additional=yes, approach=yes. A tag that covers all the variants, I can't
> > think of a suitable word.
> > the other way around: main_route=no?
> At the moment it is mostly done via the role. This has the advantage that
> you don't need to create extra relations for short sections. Simply add
> a role 'excursion' to a single way leading to that viewpoint that belongs
> to the route and that's it. If the alternative is longer then it is still
> possible to create an extra relation and add this with the appropriate
> role.
> For subrelations, I'd still like to see them tagged with their function
> as well, so that it is obvious that it is not a main route (and makes it
> easier to render routes differently. Preferably use one tag for all of
> them,
> e.g. route_segment=part/alternative/scenic.
> That leaves the actual functions. For hiking routes there is:
> alternative (1179 times)
> main (945)
> excursion (452)
> alternate (420)
> link (369)
> part (310)
> alternate_route (197)
> access (196)
> detour (150)
> and a couple of others with even less use. That obviously needs some
> sorting out.
> Sarah
> _______________________________________________
> 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/20190423/22188912/attachment.html>

More information about the Tagging mailing list