On Sep 5, 2022, at 5:25 PM, Ian Steer <ianst...@iinet.net.au> wrote:
>> 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,
>> JOSM's relation editor also pays
>> attention to forward and backward directional role tags, presenting them
>> (after a click of the sort button) in a visually clear way.
>
> I'm a bit confused here. Are you saying that even if the ways are in the
> correct direction (and even have oneway=yes), they should have a role in the
> relation of "forward" ? (I don't see forward and backward roles in the wiki?)
If you wish to keep the number of relations that describe a richly-flavored
route (with north- and south-only segments, summer- and winter-only segments...
you certainly DO have that here) to a minimum — and your "don't even suggest 4
relations" indicates you DO wish to do that — then choosing to make the route
"bidirectional" is the way to go. I'd say most routes ARE bidirectional,
whether their author knows this or calls them that or not, especially if there
are NO "directional role tags" (forward or backward role tags on elements),
which indicates the members are all "bidirectional" ways themselves.
That said, I'm sort of repeating higher-level aspects of route relation
practices as outlined here [1]. An earlier section of that same wiki [2]
describes the forward and backward role tags and how they would be used, for
example, in this case. (That wiki also describes how north, south, east, west
CAN be used as role tags, and as I mentioned earlier, this is frowned upon by
some, but the wiki notes this is only done in certain circumstances in New
Zealand, Canada and USA).
So, yes: I AM saying that making a bidirectional route as you (and I) are
"heading towards" (as the method by which you implement this route in the
"efficient" and "easier, with few(er) relations" way to do so, DOES include
using forward (and possibly backward) role tags on those member elements of the
relation upon which oneway travel must occur. Reading the wiki is one thing,
but you'll want to see other examples of routes that do this (bicycle routes
are a kind of route where this frequently happens, and so these frequently have
role tags if they are kept bidirectional).
The OTHER way to do this is to (begin to increase the number of relations it
takes to FULLY describe the route/routes) make UNIDIRECTIONAL routes, which do
not have ANY role tags, but are a "straight shot" in the given direction. But
you'll need at least two, one for north, one for south (or east and west, if
those are the predominant directions). Then, you tie together the two routes
with a "super-relation," which is a relation containing at least two OTHER
relations (of the same type).
Sorry if that's confusing; these are fairly complex topics, and you are out in
the far reaches of the technical possibilities of a relational database (which
is what OSM is) as we discuss relations, relations with members that contain
role tags, and especially super-relations. There are rules and conventions,
right and wrong ways to do things (if you choose "this" vs. "that") and often,
several "correct solution implementations." I think that's true here, and I
think you are expressing a preference to "keep low the number of relations."
OK, that implies a bidirectional route (not unidirectional routeS tied together
with a super-relation, that's three relations at least, though the
super-relation, simply containing the two sub-relations where all the "work"
gets done with many memberships, seldom changes once it is established).
So, get to know (from both wiki and real-life examples, I'd recommend both
hiking and bicycle routes) how bidirectional routes are constructed. There
WILL be role tags (usually forward, possibly backward) on those segments which
are "one-way in THIS direction only on THIS member way," but that's simply how
these are uttered into OSM. (Please use JOSM's relation editor to do this,
again, my opinion as to "the best tool to use," otherwise if you use iD to
build the relations and their role tags, you will drive yourself crazy. Some
iD editors will disagree with me there, that's fine with me).
But with hiking trails [3], there are all those ADDITIONAL roles ("main" is
assumed if empty, but there are also alternative, excursion, approach,
connection) which it sounds like for Munda Biddi, there may be some of these
(like spurs to campsites would be "excursion" and maybe summer or winter
"branches" would be "alternative"). So, you've got some homework to do about
the best way to structure this route. I don't want to seem hand-wavy, or like
I'm punting on helping you, but what you're doing is pretty advanced "relation
structuring design," and it could go a variety of ways for a variety of
reasons. How complex you might like it to be ("Ugh, 4 relations!..." isn't
really a good reason, as it may be this route really DOES need 4 relations, or
6 or even 8, maybe 9 when tied together with a super-relation. I'm making that
up, as I'm not real familiar with all the branching and specifics, but Munda
Biddi does sound like a high-complexity hiking route, and that is a "rich data"
challenge to enter into OSM "correctly." Yes, there could be a couple or few
different flavors of "correct" which seasoned hiking route relation editors in
OSM would look at and nod heads about, "Yes, that's one good way to do it, but
so is this other way, too.")
>> 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
>
> I think this is impractical because Parks & Wildlife divert the route
> depending on river levels, so it depends on the season.
OK, at least I mentioned it. This means that there will need to be either
static tagging that implies "check signs, or inquire at ranger station as to
dates or conditions that require summer or winter trail branching" or there
will be dynamic tagging that needs to be entered as conditions change. Most
opt for the former, as it's easier to maintain in OSM (enter once, require
trail users to be smart about inquiring as to conditions, then make a map
routing choice as appropriate).
>> Thinking about this .. and coming from 'public transport' routes ...
>> Use 2 relations
>> One from 'x' to 'y' (and public transports uses keys 'from' and 'to')
>> The other from 'y' to 'x'.
>> So you'd have 2 Munda Biddi Trail route relations.. similar to the India
>> Pacific train - one from Perth the other from Sydney.
>>
>> This would make clear the north only and south only routes...
>
> I am very reluctant to do this. The main reason is that 95+% of the trail is
> bidirectional, and route changes occur many times per year. This would mean
> having the edit two relations each time the route changes. The other reason
> is that creating 2 relations would not solve the summer/winter route issue
> (and don't even suggest 4 relations 😊)
Again, you've got your work cut out for you, I "feel your pain." But you are
asking the right sorts of questions, I believe I and others in the list are
giving you good resources to make good choices, and hopefully you can strike
the right balance of "good work up front to design and enter a 'smart' route
structure" and it isn't too much effort to "tweak" relatively-minor changes as
the route (relatively minor-ly) changes in the real world. OSM is map data
which reflect the real world, or strives to do so. We want to do our best to
do so without it being too much effort, but sometimes a fair bit of effort is
involved — at times in life there are no shortcuts.
Keep asking if you get stuck, there are good people who want you to understand,
do well, and help if you need it.
Steve
[1] https://wiki.osm.org/wiki/Relation:route#How_to_map
[2] https://wiki.osm.org/wiki/Relation:route#Members
[3] https://wiki.osm.org/wiki/Tag:route%3Dhiking
_______________________________________________
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au
