Re: [talk-au] Should a "trail" route relation be one-way?
Again, you folks are on the right track, here: keep discussing whether a single bidirectional route (with summer-winter alternates) is better, though that will require very careful role tag management — OR whether a single super-relation representing "the whole route, with all of its complexities" might be made up of at least a north, a south, a summer alternate, a winter alternate and campsite-spurs (where each of those is a relation, subordinate to the super-relation as members) is better. Could go either way, depending on how heads nod. Either way isn't terribly complex (though the latter might seem a bit scary if you haven't done that before, it's actually easier to think about it like this, in one sense). It's quite doable either way (or even another way...but nobody has gotten extra-clever and designed "another way," so keep these two basic flavors on the table and continue to discuss). "Maintain-ability" is doable with either kind of route, it simply takes some getting used to: look at other routes, especially hiking and I'd say bicycle, though railway, train and public_transport routes (their relations and how they are structured) can be instructive here. Big hiking routes are a best comparison. 1000 km is long, so you really want to think about the management of the number of members in a single relation if you choose the bidirectional method: don't go over 1000 members (in a single relation) if you can help it and absolutely don't go above 2000 no matter what (if so, you do need to break it up into sub-relations). "On the right track" includes talking about this (including fears, trepidation, difficulty of management / maintainability...) and carefully walking "steps along the way" — I'd say this sort of talking about things right here is excellent along those lines. And yes, if one particular approach doesn't seem to be working, change it so it does. But you'll know when it's working when everybody is nodding their heads together saying "oh, yeah, I look at how this route is structured in OSM and it makes perfect sense to me" (to the point where if it needed a tweak, it would be a relatively simply edit to fix things). That's what you're shooting for. Not any rank novice being able to do this, but the people on this list reading and paying attention (and like-minded OSM volunteers at an intermediate- or advanced-level of editing relations skill), yeah. You can agree. Keep up the good dialog / work, the pieces seem to be coming together! Don't rush things, it's better to dialog first, agree on a well-designed structure, and maybe chunk it up so everybody gets a chunk of work to do to make it all happen. Speaking from experience, this sort of "technical community building" can be one of the most fun ways we map together! > On Sep 10, 2022, at 9:38 PM, Ian Steer wrote: >> Date: Sat, 10 Sep 2022 16:39:39 +1000 >> From: Warin <61sundow...@gmail.com> >> To: talk-au@openstreetmap.org >> Subject: Re: [talk-au] Should a "trail" route relation be one-way? > >> Ideally the GPX file would have at least the trail as a contiguous conga > line ... >> with the 'extras' off to the end ... that used to make following it > easier? >> >> I would think that one file will all the variations (north/south bound, > season >> winter/summer) would be quite hard for the users to use and the >> maintainers to maintain... ??? >> > I have mused on the maintainability (since that is dear to my heart), but I > think having the north/south, summer/winter in one relation will be simpler > that breaking-out more sub-relations - and I think simplest is best. > Anyway, what I am proposing is a step along the way to a more complex > implementation which could be done if this approach doesn't seem to be > working. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
> Date: Sat, 10 Sep 2022 16:39:39 +1000 > From: Warin <61sundow...@gmail.com> > To: talk-au@openstreetmap.org > Subject: Re: [talk-au] Should a "trail" route relation be one-way? > Ideally the GPX file would have at least the trail as a contiguous conga line ... > with the 'extras' off to the end ... that used to make following it easier? > > I would think that one file will all the variations (north/south bound, season > winter/summer) would be quite hard for the users to use and the > maintainers to maintain... ??? > I have mused on the maintainability (since that is dear to my heart), but I think having the north/south, summer/winter in one relation will be simpler that breaking-out more sub-relations - and I think simplest is best. Anyway, what I am proposing is a step along the way to a more complex implementation which could be done if this approach doesn't seem to be working. Ian ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
Ian, That sounds like a plan and perhaps a final sub or a separate relationship for the huts. I am still not 100% sure that the continuous alignment will work overtime without Ian's eagle eye as other users not aware of the MB can make significant changes. Ewen On Sat, 10 Sept 2022 at 19:59, stevea wrote: > On Sep 10, 2022, at 2:21 AM, Ian Steer wrote: > >> What would people think about a structure that had a Munda Biddi > ... > > - and I would give the winter section, and northbound one-way sections > in the main route relation a role of “alternative" > > Outstanding! I step further aside and let you masters craft such a thing, > marvel from afar, nod my head and smile. > > Happy mapping. > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-au > -- Warm Regards Ewen Hill ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On Sep 10, 2022, at 2:21 AM, Ian Steer wrote: >> What would people think about a structure that had a Munda Biddi ... > - and I would give the winter section, and northbound one-way sections in the > main route relation a role of “alternative" Outstanding! I step further aside and let you masters craft such a thing, marvel from afar, nod my head and smile. Happy mapping. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
> > What would people think about a structure that had a Munda Biddi master > relation, containing only 3 sub-relations: > 1. the existing relation containing the main route (including both north & > south-bound one-way sections, plus the winter/summer routes) > 2. a new > "Munda Biddi Collie Spur" relation > 3. the existing Munda Biddi Alternate > relation (that is presently a sub-relation of the relation containing the main > route) containing all the hut spurs, huts etc > - and I would give the winter section, and northbound one-way sections in the main route relation a role of "alternative" ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
> From: Ewen Hill > Sent: Saturday, 10 September 2022 9:35 AM > To: Ian Steer > Subject: Re: [talk-au] Should a "trail" route relation be one-way? > >I have been thinking of this with the new Collie township spur and the > other oddities and especially the huts that scatter the route which apart from > one amazing hut that is smack bang in the middle of the trail, are normally > just off the trail on short spurs. > > Where it started with two relationships of MB-Main and MB-Alternative, I > believe a master MB would be preferable containing all the huts, spurs, > winter/summer variations and the main route. Where there is a spur like > Collie (~16km?), an additional MB-Collie-Spur might be worthwhile. > > Having a single master would allow users to easily extract the entire route > and huts in one go and prepare them for their garmin and whatever GIS > software they use.It would also give councils, emergency services, tourism > operators etc. easy access to all of the relevant data. I don't see the need > to > maintain any other spur relationships unless the spur is ~> 2km as it's > probably overkill and makes it more complex to maintain. > What would people think about a structure that had a Munda Biddi master relation, containing only 3 sub-relations: 1. the existing relation containing the main route (including both north & south-bound one-way sections, plus the winter/summer routes) 2. a new "Munda Biddi Collie Spur" relation 3. the existing Munda Biddi Alternate relation (that is presently a sub-relation of the relation containing the main route) containing all the hut spurs, huts etc I note that the hut spurs could perhaps be left in the main relation and tagged with an "excursion" role (rather than dragged-out into a separate relation as they are now). What are the pros and cons of leaving them in the main route and using the excursion role? I suppose one disadvantage would be that sorting the route would show discontinuities ? Ian ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On 10/9/22 11:34, Ewen Hill wrote: Hi Ian, Firstly, thank you to you and the Munda Biddi (MB) elves for providing an amazing 1000km cycling route, mainly off-road, sometimes on ball bearings, other times on sand and the rest mainly on fire trails and single track. It is an amazing asset and something that I will cherish completing. I have been thinking of this with the new Collie township spur and the other oddities and especially the huts that scatter the route which apart from one amazing hut that is smack bang in the middle of the trail, are normally just off the trail on short spurs. Please note that this route is not set in stone and sections are replaced on a regular basis. Where it started with two relationships of MB-Main and MB-Alternative, I believe a master MB would be preferable containing all the huts, spurs, winter/summer variations and the main route. Where there is a spur like Collie (~16km?), an additional MB-Collie-Spur might be worthwhile. Having a single master would allow users to easily extract the entire route and huts in one go and prepare them for their garmin and whatever GIS software they use.It would also give councils, emergency services, tourism operators etc. easy access to all of the relevant data. I don't see the need to maintain any other spur relationships unless the spur is ~> 2km as it's probably overkill and makes it more complex to maintain. The waymarker trails website uses the relation/s to generate a GPX file and an elevation display .. quite handy. If all the huts are in there too .. I think it ignores nodes .. other than guide posts? Possibly it ignore them too. It would be nice to have, yet more, roles for huts/campsites, toilets, water and a role for the trails leading to them.. At the moment these are not included in the relationship instructions .. so lack any support or organized thinking. I don't know how easy it is to have all that in a simple GPX file .. the newer ones do have more features... Ideally the GPX file would have at least the trail as a contiguous conga line ... with the 'extras' off to the end ... that used to make following it easier? I would think that one file will all the variations (north/south bound, season winter/summer) would be quite hard for the users to use and the maintainers to maintain... ??? ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
Nice. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
Hi Ian, Firstly, thank you to you and the Munda Biddi (MB) elves for providing an amazing 1000km cycling route, mainly off-road, sometimes on ball bearings, other times on sand and the rest mainly on fire trails and single track. It is an amazing asset and something that I will cherish completing. I have been thinking of this with the new Collie township spur and the other oddities and especially the huts that scatter the route which apart from one amazing hut that is smack bang in the middle of the trail, are normally just off the trail on short spurs. Please note that this route is not set in stone and sections are replaced on a regular basis. Where it started with two relationships of MB-Main and MB-Alternative, I believe a master MB would be preferable containing all the huts, spurs, winter/summer variations and the main route. Where there is a spur like Collie (~16km?), an additional MB-Collie-Spur might be worthwhile. Having a single master would allow users to easily extract the entire route and huts in one go and prepare them for their garmin and whatever GIS software they use.It would also give councils, emergency services, tourism operators etc. easy access to all of the relevant data. I don't see the need to maintain any other spur relationships unless the spur is ~> 2km as it's probably overkill and makes it more complex to maintain. Next time you are over east, let's have a chat about a MB east coast equivalent between Orbost and Canberra - and apols for my route checker code failing back in 2019. ;) Ewen On Mon, 5 Sept 2022 at 13:15, Ian Steer 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. > > > > Regards > > > > Ian > ___ > Talk-au mailing list > Talk-au@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-au > -- Warm Regards Ewen Hill ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On Sep 6, 2022, at 12:36 AM, Warin <61sundow...@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. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On 6/9/22 11:23, stevea wrote: I forgot to say earlier, so I add here and now: on really huge routes like this — thousands of kilometers long — it makes it more manageable for humans (and OSM software like JOSM and other tools / end-use cases like renderers and routers) to break up the route into logical sub-components. I'm thinking of examples I know in the USA, like Pacific Crest Trail or Appalachian Trail, where there are either "by state boundaries" kinds of "chunking," or designated by Trail Management (I think the PCT uses letters of the alphabet to denote segments). For Munda Biddi, you may want to inquire whether something like this "chunking" of the whole trail into smaller segments is already going on "officially," and mimic that in OSM. I will say that dealing with a single relation that contains thousands of elements (over 1500 things slow down and get unwieldy) are hard to deal with and do recall that there is a 2000-item limit for some data structures in OSM. I don't recommend putting more than 2000 ways into any single relation under any circumstances. I hope all this helps. 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 First relation: Perth to some point where the trail separates into a choice. This would be common for all variations. Second and third relations: from the above relation until they join Forth relation: common bit from the above to the next separation. Then I'd have 2 or 4 master relations: North, South etc. This makes changes to it easier as you have to change one section and that is then incorporated into each mater relation. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
I forgot to say earlier, so I add here and now: on really huge routes like this — thousands of kilometers long — it makes it more manageable for humans (and OSM software like JOSM and other tools / end-use cases like renderers and routers) to break up the route into logical sub-components. I'm thinking of examples I know in the USA, like Pacific Crest Trail or Appalachian Trail, where there are either "by state boundaries" kinds of "chunking," or designated by Trail Management (I think the PCT uses letters of the alphabet to denote segments). For Munda Biddi, you may want to inquire whether something like this "chunking" of the whole trail into smaller segments is already going on "officially," and mimic that in OSM. I will say that dealing with a single relation that contains thousands of elements (over 1500 things slow down and get unwieldy) are hard to deal with and do recall that there is a 2000-item limit for some data structures in OSM. I don't recommend putting more than 2000 ways into any single relation under any circumstances. I hope all this helps. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On Sep 5, 2022, at 5:25 PM, Ian Steer 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
Re: [talk-au] Should a "trail" route relation be one-way?
> 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?) > 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. > 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 ) ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On 5/9/22 17:41, stevea wrote: On Sep 5, 2022, at 12:23 AM, Warin <61sundow...@gmail.com> wrote: Be careful with the automated tool .. you can end up with the route comprising some 'north bound' bits with some 'south bound bits'. I'm not sure what you mean by "the automated tool," Warin. I'm only suggesting to use JOSM's relation editor window's "sort" button. Yes, those 'sort' buttons are automated tools ... and they don't always 'get it right'. Roles 'forwards' and 'backwards' refer to the direction of travel with respect to the direction of the way - not 'north', 'south' 'east nor 'west'. Yes, I know. I'm not sure whether Ian does, though thank you for pointing this out, as perhaps I wasn't clear. My intention was to convey my methodology (which works well) and to inspire Ian to discover (using wiki, practice and experience) whether it might work for him. Some Contributors DO add cardinal directions as role tags in relations, and that is NOT correct, let's be clear about that. (Sometimes they do this as "placeholders" during route construction, but this is not recommended as it is confusing to other human editors as these role tags are encountered). I'm guilty of adding 'constructional roles' to help me organize, understand and edit these kind of relations. I usually delete the roles .. sometime it takes a second try. Route roles are... See https://wiki.openstreetmap.org/wiki/Tag:route=hiking?uselang=en#Roles Yes, specifically for HIKING routes, this wiki and these role tags are crucial resources to read and use where appropriate. Ian, it is essential that you read, understand and apply this wiki as appropriate to the Munda Biddi route relations in OSM. I'd use the same for bicycle and horse routes .. as that would make sense? The one web render I use is https://mtb.waymarkedtrails.org/#route?id=5810814=relation=8.0/-33.4621/117.7741 I think that uses the same tools for all the routes. You may find that the renders of hiking/bicycle and horse routes will take no notice of 'forwards' and 'backwards'. Right: as the OP mentioned not "know(ing) enough about the potential consumers of route relation data..." it wasn't clear to me whether this included knowledge of humans as consumers or software like renderers and routers as consumers. Some renderers have "weak" support for role tags, but again: it is most important to get the data "OSM correct," not "pretty for a particular renderer" (or router). 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... Yes, I agree, this is another workable solution, thank you, Warin. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On Sep 5, 2022, at 12:23 AM, Warin <61sundow...@gmail.com> wrote: > Be careful with the automated tool .. you can end up with the route > comprising some 'north bound' bits with some 'south bound bits'. I'm not sure what you mean by "the automated tool," Warin. I'm only suggesting to use JOSM's relation editor window's "sort" button. > Roles 'forwards' and 'backwards' refer to the direction of travel with > respect to the direction of the way - not 'north', 'south' 'east nor 'west'. Yes, I know. I'm not sure whether Ian does, though thank you for pointing this out, as perhaps I wasn't clear. My intention was to convey my methodology (which works well) and to inspire Ian to discover (using wiki, practice and experience) whether it might work for him. Some Contributors DO add cardinal directions as role tags in relations, and that is NOT correct, let's be clear about that. (Sometimes they do this as "placeholders" during route construction, but this is not recommended as it is confusing to other human editors as these role tags are encountered). > Route roles are... > See https://wiki.openstreetmap.org/wiki/Tag:route=hiking?uselang=en#Roles Yes, specifically for HIKING routes, this wiki and these role tags are crucial resources to read and use where appropriate. Ian, it is essential that you read, understand and apply this wiki as appropriate to the Munda Biddi route relations in OSM. > You may find that the renders of hiking/bicycle and horse routes will take no > notice of 'forwards' and 'backwards'. Right: as the OP mentioned not "know(ing) enough about the potential consumers of route relation data..." it wasn't clear to me whether this included knowledge of humans as consumers or software like renderers and routers as consumers. Some renderers have "weak" support for role tags, but again: it is most important to get the data "OSM correct," not "pretty for a particular renderer" (or router). > 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... Yes, I agree, this is another workable solution, thank you, Warin. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On 5/9/22 15:52, stevea wrote: BTW, I very much recommend using JOSM as your preferred editor when editing relations, especially route relations. IMO, the route relation editor in JOSM is superior to all others. Don't forget to click the "sort relation" button as a last step in the relation editor window before you close it, that "neatens up" the elements so they connect with each other as best they can (the set of elements that are in the relation when you click it), and identifies any remaining gaps visually and readily. 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. With practice, once you "get it," you won't go back to any other way of editing (especially route) relations! Be careful with the automated tool .. you can end up with the route comprising some 'north bound' bits with some 'south bound bits'. Roles 'forwards' and 'backwards' refer to the direction of travel with respect to the direction of the way - not 'north', 'south' 'east nor 'west'. Route roles are 'main' 'excursion' 'approach' 'connection' 'alternate' See https://wiki.openstreetmap.org/wiki/Tag:route=hiking?uselang=en#Roles You may find that the renders of hiking/bicycle and horse routes will take no notice of 'forwards' and 'backwards'. 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... ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
BTW, I very much recommend using JOSM as your preferred editor when editing relations, especially route relations. IMO, the route relation editor in JOSM is superior to all others. Don't forget to click the "sort relation" button as a last step in the relation editor window before you close it, that "neatens up" the elements so they connect with each other as best they can (the set of elements that are in the relation when you click it), and identifies any remaining gaps visually and readily. 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. With practice, once you "get it," you won't go back to any other way of editing (especially route) relations! ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Should a "trail" route relation be one-way?
On Sep 4, 2022, at 8:10 PM, Ian Steer 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). ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Should a "trail" route relation be one-way?
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. Regards Ian ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
