Is the wiki documentation on routes is ambiguous with respect to forward/backward roles?
In the table it states:
If a route should be followed in only one direction for some or all of its length, the role can indicate this for some or all of the constituent ways. forward means the route follows this way only in the direction of the way, and backward means the route runs only against the direction of the way.
yet at the end it states
Note: to ensure a route is properly connected when using a two alternative directions (alternative route A1 and A2, using the forward and backward roles), make sure the element before the branch connects to the first element in A1 and the element after the branch connects to the last element of A2. Also note that the forward and backward roles refer to the directionality of the ways in A1 which need to be going in the same direction; if not all ways in A1 run in the same direction it may be necessary to use both forward and backward for the same alternate route A1.
I seem to have got myself into a pickle regarding the Fife Coastal Path. I have applied the forward/backward roles (as per the note) only on the portions that have two options to ensure the ordering is coherent (using JOSM editor).
Have I done it wrong? Is the documentation ambiguous?
My understanding has always been that the roles only apply to sections of the route that traverse different ways in the forward / backward direction of the route. Say a route with one way sections in it that require splitting the route up so that it can be travelled in both directions. Not to alternatives or anything similar.
But in the mean time Iāve more or less given up on the subject.
That page is very generic, attempting to cover a variety of route relations from buses to hiking routes. I suspect it has received less attention over the years than the pages for more specific route types.
It might be worth looking at the page on hiking routes, especially on roles such as āalternativeā. Generally itās rare for forward/backward roles to apply to hiking routes, although it can happen e.g. on very narrow sections where access is controlled to ensure everyone walks in the same direction. I donāt think that is what you are trying to map though.
Thank-you. Using the role=alternative look like what I ought to be doing. Interestingly it still results in a disconnected route according to the JOSM Edit relation tool.
I do need to apologise to some fellow mappers for getting confused with this. Mea culpa!
this is also my understanding, but generally, if the directions are not the same, particularly for bus routes, it is more common nowadays (at least here) to have a relation for every direction and group them with a route master, even more you should do this for alternatives (if they have the same ref, which is not common around here).
Forward and backward roles are pretty much used only for bicycle routes. I guess this makes sense because many, if not all, bicycle routes have sections using different OSM ways for the two travel directions.
The forward/baclward method is a clever way to enter both travel directions into one relation, even if sections use different ways for the travel directions. Maybe a bit too clever, because it confuses both mappers and data users! Even if you got the hang of it, itās still hard every time you try!
A few tips that have helped me understand this stuff (JOSM is assumed!)
All the ways are entered once (with a few exceptions for very complicated situations)
Only the ways that are different for the two travel directions get a role. Ways that serve both travel directions donāt get a role.
And the detailed workflow that was suggested to me:
Enter the ways of the main travel direction in the right order; when there is a split section, at the end of this split section pan your map back to the start of the split and enter the ways of the return direction, up to the rejoin point.
Then go again at the split point, in JOSM and the map. You need the map to see the drawing direction of the ways, and you need to imagine you are traveling along the ways.
Give a role to all the ways of the split section. Start with the main direction.
ā If the way is drawn in the main travel direction: forward. Meaning: for the main travel direction, you use this way in the drawing direction.
ā If the way is drawn against the main travel direction: backward. Meaning: for the main direction, you use this way against the drawing direction.
When you have done the split ways of the main direction, move to the rejoin point and go upwards in JOSM. Imagine you are traveling the return travel direction, and apply the roles to the ways of the return direction.
ā If the way is drawn in the return travel direction: forward. Meaning: for the main travel direction, you use this way in the drawing direction.
ā If the way is drawn against the return travel direction: backward. Meaning: for the main direction, you use this way against the drawing direction.
Still, I get confused, especially when there is an error in the relation and the main direction is south to north! I sometimes still find myself redoing sections instead of fixing the error.
One thing has changed since I started doing this: the sort function in JOSMs relation editor sorts these bidirectional routes correctly. So if the ways are all ther and the roles are alright, you can sort it. This even works when the ends of the route are split (which happens when a superroute or network relation with subrelations is used).
Hi JamJar_II. Following our discussion, Iāve realised that perhaps you were sort of right, in terms of having slightly different roles for relation members where there are two possible routes. Iāve therefore tweaked one of the alternates at Inverkeithing Bay. I will check WaymarkedTrails.org tomorrow to see if it has made any difference. In any case, per the documentation, it seems that where alternative routes exist in a relation, they should be tagged as such. If I donāt see any problems, I will go ahead and adjust the role of one each of the alternate routes by adding āalternativeā to the ānon-primaryā route of each pair of alternates. Maybe this will even keep JOSM happy?
Thanks for the heads up. Fingers crossed it provides you with the right result. Looking just now at your Inverkeithing Section on Waymarked Trails it looks coherent.
It has been a useful learning exercise for me. Waymarked Trails usually updates in under an hour but maybe longer for routes the size of FCP.
Some might say that getting the order right does matter and downstream algorithms should unpick routes. My personal opinion is that having more ordered, coherent routes is worth the effort as it allows for easier sanity checking.
Anyway, thanks again for humouring my interference!
Iām not really sure what you mean by ordering - Iām guessing you mean the order that the various ways are listed in the relation. There doesnāt appear to be any way to change or view this in iD - the in-browser editor - which is what I normally use. The way I have been working is to just make sure that the hiking routes I look after are continuous - i.e. there are no gaps, by visualising them using e.g. https://www.openstreetmap.org/relation/10841122 and WaymarkedTrails.org, and make sure that the relation is as accurate as possible to what the route actually is on the ground.
I think I need to have another look at JOSM, and also export the relations using overpass turbo and go through them to see how the data is actually being stored in the database to understand this.
Normally you donāt need to worry about the member order in iD, because it automatically sorts the members of a relation when you modify the relation by adding or removing a member or by splitting or merging members. This functionality is effective as long as the members form a linear or ring geometry based on the forward and backward roles, but it can result in counterintuitive ordering if the route has any segments that double back, loop, or fork. If you do need to customize the order for any reason, you can select the relation and drag the members around in the member list.
You should not mix roles forward/backward with the new roles for recreational routes like alternative in one relation. If you need both and/or have a longer alternative, I suggest to use a relation on its own for the alternative and group the relations using a superroute relation and the role alternative for the appropriate member in the superroute.
Yes, you should take a look as the relation editor in JOSM nicely visualizes the continuation and offers to sort the members accordingly which works well most of the time. Though, I am not sure if other roles than forward and backward are supported, yet.
Yes, this missing feature is another short come of iD and the automatically sorting had a lots of bugs and still fails if the relation has already a gap or if the order of members is messy, prior to your edit.
I always wonder how I can explain to users of iD that the order is incorrect or that there is a gap without relying on external sources. Uploading first and than checking and fixing (possibly several times in a row) only expands the relationās history with all its side effects like getting less readable (understandable) and using more resources that first the OSM page and than more and more tools til finally JOSM are joking up.
This thread is about walking and cycling routes I think, and Iām not sure there is a particular reason for these to be ordered ācorrectlyā. Bus routes perhaps, because a bus can traverse the same road twice within the same route and it might be helpful to know where itās going next each time it does it. But as a fairly in-depth consumer of cycle route relations Iām not sure how ordering would help me.
I think it is useful to have most of the common relations sorted. Even boundarys and MPs profit from being order as you can more easily find gaps if the continuation is displayed.
For route relations the order is important as it saves a lot of resources if you do not have to order them yourself all the time. Talking about recreational routes finding gaps without order is visually impossible and I do not know of any QA which works with unsorted relations. Some consumers try to display an elevation profile and some rely on the order.
While you could say, that is not your problem and that consumers including editors could sort the members internally, I would say that keeping it ordered and having better support from the editors and their internal QA is the better way.
Most of my recent edits here are when āsomeone has accidentally broken a boundary, or walking and cycling route relationā.
In the case of boundaries, thereās a really easy test - is it a valid (multi)polygon? When something is no longer valid (like happened with this relation) it falls out of the multpolygon table in a rendering database and a script sends an email out. Trying to validate the relation in JOSM will then show where the problem is.
For route relations you can count the number of linear pieces in the database, and then when that goes up, send an email and use this site to see where any gaps might beā¦
It simply doesnāt make sense to sort any boundary and route relations more complicated than one ring or one line - how on earth could you sensibly sort this?
Iām not sure what youāre referring to as a missing feature. You can rearrange the members manually, by dragging them around in the list. If you need to trigger an automatic resort of the whole member list, I suppose you could split and rejoin a member way or something. Maybe there could be a button to trigger this functionality more explicitly. I donāt see an existing feature request about it in iDās issue tracker.
When you hover over a member in the list, iD highlights the member on the map. You can scrub the mouse cursor over the members to get a sense of where the route goes and whether there are any gaps. It isnāt as straightforward as a validator rule that detects gaps, but at least the mapper doesnāt have to upload first and verify later.
Also, for oneway roundtrips the order shows the travel direction. For two-way trips with split sections (most cycling routes), the order show main and return directions. Export of a route in gpx format can correct some minor ordering issues, but it relies on continuity as shown by the continuity line in JOSM.
I agree it would help a lot if OSM sported an export method with ordering included - then again, I think it would be very hard to create an ordering method capable of handling all variants of routes, including handling of roles, hierarchy and the collection type ārouteā relations, which is necessary for functions like elevation profile and gpx files for transport to navigation apps and devices. I think itās unrealistic to expect data users to do this, especially since the order in the route actually reflects ground truth: the order in which the ways are used when you travel the route.
Unordered routes can be rendered without problems, I guess because the rendering is done at the way level, so the only thing that matters for rendering is that all the ways are there.
Currently routes do not contain enough information to order them correctly independent of the ordering in the list of the relation members. It isnāt ādifficultā, it is literally impossible for the general case.
This mainly affects public transport routes because they are most likely, as @Richard pointed out, to have loops etc.
This is the PTv2 way. Relatively easy to implement if youāre importing data or actually riding the routes to map them, but often very unweildy if youāre trying to build up bus routes while doing other types of surveying.
Post-sorting might be possible for most cases, but some cases remain that canāt be sorted, especially when the line crosses itself. So yeah, impossible for the general case. On the other hand, Iāve witnessed how someone solved the (for me) seemingly impossible task of sorting bidirectional cycle routes with split sections and split ends. Someone like that might also come up with the essential information necessary to solve the general sorting puzzle.
forward means the route follows this way only in the direction of the way, and
