Hello,
I’m a bit confused about the right sequences for the role:forward role:backward
Let me explain:
I have a long road (I want to manage in a relation), where sometimes it gets 2 oneway carriages (with bridges, tunnels, etc…).
In the oneway parts I add role:forward or role:backward.
While for the role:forward there isn’t any problem, I’m not sure how to sort the backwards members. In the following drawn I put the 2 cases.
In a logical way, in the relation I would sort members in the same direction as I drive, so travelling in the backward direction I’d sort as in the case 1.
Uh, as the schema doesn’t keep formatted, I add the link for the schema’s image https://ibb.co/BfTh1cc
Hello! As far as I understand, there is no need for forward / backward roles on street relations. Just for confirmation: what kind of relation are we talking about (because route relations differ from street relations)?
And as @Elefant_aus_Wuppertal says below, I also strongly advise to use JOSM for relation edits.
I think the editor JOSM is helpful in such cases, because this editor visualises these situations when opening a relation with such members. But sorry I cannot give you a more sufficient answer at the moment
I’m talking about a National route, WHERE road split into 2 oneway carriages (as already written in my original post).
Don’t be rush to give an answer, try to read all the (not so long) post
I was also confused how to map such roads. But I’m set “forward” role on all parts where the road splits to 2 oneway carriages. I was told the order of all members doesn’t matter for routing, but it’s easier to see if these (in the relation JOSM relation editor) are sorted in same order as in reality.
I think it is easiest for maintenance to have 2-3 relations, one for forward, one for backward, and if you want one that contains the other two relations, just like we do it for public transport routes.
Yes, I read your post, but was confused about what kind of relation you were referring to.
The header of your post says “route” which would be Relation:route - OpenStreetMap Wiki and has forward / backward roles sometimes. In this case it would be a type=route and route=road.
There are also street relations in OSM, and I was trying to make sure we are talking about the same issue .
The role “forward” indicates the route only uses the forward direction of the way and not the backward direction.
The role “backward” indicates the route only uses the backward direction of the way. This is rarely needed for dual-carriageways, because the driving direction of one-way ways is conventionally the forward direction of the way.
Let’s face it. Roles forward and backward are used in many but not all type=route relations. They are needed if the relation can be followed in both directions and different ways are used per direction. The role depends on the direction the way is followed depending only on the direction of the way:
forward is used if the way is only followed in the way’s direction
backward is used if the way is only followed in opposite direction of the way’s direction.
If we are talking about dual carriage route with oneway=yes ways it is all the time forward.
Properly sorting the members by connectivity is very much appreciated as QA often depends on it and e.g. elevation profiles are not possible without it.
Yes, if we are talking about route=road and most or all ways are only followed in one directions it might be useful to use one relation per directions and group them in a type=superroute relation. Even then the roles are still useful.
Using one (or several) relations per direction is useful to reduce the numbers of members per relation which turn quite unfeasible with too many members. The maximum is around 4000 members but I usually try to stay well below 2000 as with adding more details ways are usually split and therefore the number of members will rise.
The roles are the information that the way is only used in one direction. Unlike type=route, public_transport:version=2 we have no written rules for route=road and superroute might contain alternatives. Looking at the members demands to dive deeper into the data which is not needed with roles.
.