I’m adding some MTB trails, one of them being:
This trail essentially starts on this road: Way: Route des Forts (808599059) | OpenStreetMap and then also returns to the starting point over the same piece of road (in the other direction obviously).
I read Mountain biking - OpenStreetMap Wiki but I didn’t find any reference to how to “fix” this? Any hints?
Thanks, Timo
Add the way(s) twice
a the beginning of the trail
at the end of the trail
assign a ‘role’ to the ways in the relation:
‘backward’ and ‘forward’ has nothing to do with the direction of the trail
In this particular case, you might leave the ‘role’ empty - then it is a perfect round-trip
‘role’ is useful if you take the same road twice, in each direction, but include the sidewalks/cycleways (separately mapped on either side) into the relation.
If it is true that the route is a “perfect round-trip,” any route relation can (helpfully) add the tag roundtrip=yes.
Also, a sort of “advanced” topic about routes is that they can be expressed using two different methods as relations in OSM. One is (colloquially, within OSM anyway) known as “bidirectional.” This means that forward and backward role tags are applied to those segments where “only one-way travel” is extant, meaning that a route could contain “eastbound-only” + “westbound-only” sections (or north-only and south-only), included in a single route, but both directions: hence “bidirectional.”
Conversely, a “unidirectional” route will never have such role tags, and will be one contiguous (unbroken) set of way elements that all connect seamlessly, but only in a single direction. Then, the opposite-direction route will need to be created (possibly not including segments that are in the first one); these two (opposite-direction) routes are tied together by including them both in a super-relation (relation containing relations).
The reasons? Bidirectional routes are “a single entity” and hence a bit more “compact” of a data structure within OSM. Because of “role tags,” they can be a bit more complex and harder to understand for novice route relation (human) editors, but they are prevalent in OSM, as they are “succinct.” Unidirectional routes are more simple to create and understand (for the human editor that creates them), but they have the complication that the other direction must be created in whole, AND both relations should be included in a super-relation.
I hope you enjoyed today’s Discourse-based “daily hygiene” lesson for good (robust) route relation creation.
@stevea hmm, I copied what others “around me” are doing TBH.
I’m not 100% sure I understand your post correctly, but this sounds like it means most routes here would need a “forward:” and " backward" role tags as they are circular, but one direction only…?
Thanks for the good question / posited “what you said is unclear,” to me: I am happy to respond.
For every case I can think of, a truly circular (roundtrip) route relation (whether hiking, bicycle, equestrian…) should have the roundtrip=yes tag upon it, and as if it is truly bidirectional (I don’t see why it wouldn’t be, but of course, I do have to say this), nothing else but the simple bidirectional route with that tag is required. True, there might be, say, something like a “very steep” portion or something which is appropriate in one direction, but not another, and then there would be a “longer, loop-around” portion which is appropriate in the other direction…and in that case, you’d use forward and/or backward role tags (depending on the direction of the underlying ways). How to do this is fairly well-documented and widely understood.
Then, there are the great majority of routes which are not roundtrip=yes. These can be entered into OSM as either bidirectional or unidirectional. The “optimal” circumstance is when there are no “different” (based on the direction you are going along the route) ways in the route as elements: in that case, make the route bidirectional (only one relation, travel in both directions is allowed on each and every single way), there is no need for forward or backward role tags at all, and you are done with the route. It is simple, simply entered, and easily understandable (as able to be traversed in both directions). AND there is no reason to “double the data” by adding another route (for the other direction) with two unidirectional routes: why do so when there isn’t any need to? (You’ve entered a bidirectional route).
So to directly answer your question, no, for roundtrip routes, UNLESS there are different ways where only “in this direction along the route travel is allowed,” there isn’t any need to add forward or backward role tags. For non-roundtrip routes, these role tags are only required where there are ways that require “only in this direction travel.” Does that make sense / help? Again, I’m happy to continue to engage so you understand things, but this can be tricky until you “get it.” Looking at existing route relations (with role tags) can be helpful, too. (And I recommend the JOSM editor to do so, as it has an excellent relation editor dialog window that, at least for me, visually makes these concepts fairly clear).
Edit: All of this really does take practice. I would say it took me many months, even a year, to fully encompass the differences between various flavors of route relations and how the forward and backward tags are correctly applied, as well as the distinctions between unidirectional and bidirectional route relations. Please persevere: while some in OSM might feel a steep learning curve, it is well worth it once mastered.
As you stated, I sometimes find it difficult to convert the theory of the wiki to a specific use case TBH. But responses like yours help a lot, thank you for that. 
I forgot to mention about the specific type of routes:
There is something “special” about them, they are pegged out in one direction. So you can in theory ride them in the opposite direction but without any signs and no guarantee they are actually rideable (down vs uphill).
AFAIK all other similar routes in the neighborhood don’t use forward and backward.
But from a routes database point of view this looks like missing data to me (?). I tried using OpenStreetmap before to analyse some of the MTB routes and I couldn’t see what direction they were meant to be ridden.
Most bicycle or mtb routes are / can be ridden in both directions, although specifically with mtb routes, there are often trails which are “more strictly” (by convention, rarely signed, but such signage DOES happen) specifically “uphill only” or “downhill only.”
Again, the only time when forward (or backward, when the direction in the route is OPPOSITE the direction of the way) role tags are appropriate on a route relation is in a bidirectional route relation where there is a “oneway=yes” on a way specifically meant for “in this direction of the route’s travel only.” I hope this makes sense; it does come with practice and seeing how more routes properly have role tags applied really helps. Role tags are kinda rare for mtb routes, but frequent with (urban, especially) route=bicycle relations.
Just to doublecheck.
I just added this way Way: Chemin des Vaches (1215573033) | OpenStreetMap and gave it a 5% incline, but there was no field to set the direction (it’s a 4X4 gravel/grass way that can be taken in both directions), so I gave it an up incline, but I’m not sure if it’s correct.
Feel free to let me know if/how I can improve this.
Thanks
Incline is related to the direction in which you mapped the line, so if the up slope is from west to east and you mapped the trail from west to east then incline=up or 5 (not sure % is required, I just do the number). Navigators will know if you go the other way it’s down hill.
Not sure I follow here. If a route goes A - B - C - D - B - A, and the connection from A to B is along the same way (i.e. not two different one-way ways), you add that way twice, once at the beginning and once at the end, sure. But do you add the first member with a forward/backward role (forward or backward depending on the direction of the OSM way) and then the last member with the opposite role, or do you leave them both without a role?
The Wiki says “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.” That sounds like these roles are segments where the way from A to B is different from the way from B to A… I also would have thought data consumers are clever enough to work out which direction to traverse a way in. But your answer is making me doubt that…
You’re right, in the particular case int the initial post, there seems to be an appendix, approach to reach the roundtrip section. Forward and backward are not reqired on that stretch. But I’d include that way at the beginning and end of the relation.
Just for your information. There is a wiki about roles in recreational route relations. Several types of roles are mentioned there (e.g. approach). I’ve made a (overpass) map that hopefully gives a better view on this matter.