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

[stevea]

On Sep 6, 2022, at 12:36 AM, Warin <61sundowner at gmail.com> wrote:
> The Bicentennial Nation Trail is broken by states (and that is a horse trail, a mtb trail and a hiking trail). It is not well mapped.
> 
> The Overland Track is broken into segments - the 'normal' day lengths for hikers.
> 
> The Munda Biddi could also be broken into segments -
> For example
...

Yes, to sort-of quote myself, "Yes, that's one good way to do it, but I'm sure there are other ways, too..." (which would make good sense for well-articulated reasons).

I think there might only need to be one "master" relation, that's the one (a kind of super-relation) that ties them all together.  Distinctions between north and south would be made as sub-relations, "one each" and both in the master.  (I'm more familiar with bicycle and public transit routes, not so much hiking routes, which have their own peculiarities with the various flavors of role tagging the give rises to "alternative" and "excursion"...).

> This makes changes to it easier as you have to change one section and that is then incorporated into each mater relation.

This IS the idea for both "chunking" a big route into smaller components, as well as WELL crafting it according to the conventions for that type of relation (here, a hiking route):  smaller components are "more manageable" and where one (designer / author) decides these edges of structuring can either simplify future management as changes occur, or make it more complex because it wasn't designed with those changes very well.  Bottom line, take some time to design how a large, complex data object in OSM is designed and entered into OSM:  its structure does matter, for both purposes of "how does this present to people?" (is it easy to understand?, as entered:  does it render and route well?...) and "how sensible are the data to manage going forward?"

Let me make the point clearly if I haven't already:  these sorts of "good route relation design criteria" are not easy, come with practice, are aided by exactly this sort of community discussion (and eventual consensus) we are doing here now, and can go multiple directions and still be "widely correct."  We are data architects of a sort here, and the way the thing is eventually designed and finally put together "only" has to "work," it doesn't have to be "perfect under all criteria, for everybody, forever."  Any number of solutions can work just fine.