[talk-au] Should a "trail" route relation be one-way?

[stevea]

On Sep 4, 2022, at 8:10 PM, Ian Steer <iansteer at iinet.net.au> wrote:
> I am a volunteer with the Munda Biddi Trail Foundation, and do my best to keep the Munda Biddi Trail route relation (5810814) up-to-date.  The trail is 1,000km from Perth to Albany.
>  
> There is a child route relation (Munda Biddi Alternate, 8900679) that contains “odds and sods” not on the main route (typically spur trails into overnight huts).
>  
> There are a few sections of the main trail that have alternate routes – some for north-bound/south-bound, and one for summer/winter routes.
>  
> I don’t know enough about the potential consumers of route relation data to answer the following question:
> - should the sections of track with alternate routes (eg north/south, summer/winter) be in the main route relation? – or should I randomly select (say) north-bound and summer routes so as to keep the main route strictly a simple, point-to-point route (and shift the south-bound and winter routes into the Munda Biddi Alternate relation) ?
>  
> My suspicion is that they should stay in the main route relation.

For the "north only" and "south only" segments, I would certainly keep both of these "directional" segments in the one "main" relation, but tagged with role tags:  usually "forward" if the direction of the way corresponds to the direction of travel, if not, either correct that (by reversing the direction of the way), or use "backward" as the role tag.  Sometimes, a "backward" role tag can't be helped, but that's usually in rather complex scenarios with lots of ways.  It is a convention (and "nicety") — not a necessity — to prefer "forward" over "backward," but in either case, do what works / is correct.  To be clear, these tags mean "on this way in this route ONLY in this direction."

For a route=bicycle, I leave it at that, since most-often-used bicycle renderers (I think OCM is, I could be wrong), using forward and backward role tags adds "yellow arrows" that make directionality quite clear.  However, for non-bicycle routes, this is not as clear, so you might want to change the name of the way so it includes a something like "(name), northbound only" (or southbound).   This can be controversial, as some believe a name should be "name only," but it is still done.  Routers should always process directional role tags properly, though your mileage may vary.

For the summer / winter routes, you may want to see if you can coax the opening_hours syntax to properly reflect the "time" that these are to be / should be used, and also do a rename (suffixing the name=* tag) to make "summertime only" clear (again, perhaps with controversy).  You may choose to keep these in the "main" route relation, too, or you may choose to break them out into a separate relation, where you have relation-wide naming ability without re-naming each element way.

In short, you really have essentially full control, though how things are parsed by routers (and renderers) can be affected by your choices.  Those shouldn't shackle or force you into any particular choice, but do be aware of them.  It's better to be strictly "OSM database correct" (and perhaps have a less-desirable render or routing because of limitations in a renderer or router) than it is to be "pretty" for a renderer, for example (but not strictly correct in OSM as a database).

I wouldn't "randomly" select, although you are on the right track when you allude that you have a choice to keep a "main route" as a single (usually bidirectional) line fully from one end of the route to the other:  you do.  Making wise choices about how to enter into OSM all the "bristles, branches and spurs" of a complex route does come with some practice (and feedback about how use cases — including renderers and routers — will process them), but as you learn these and get a better feel for them, you can make good choices in how you structure the data (elements, tags) in the relation(s).