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 gpx-exports. 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 nodes. 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 <[email protected]>: > 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 > [email protected] > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
