[Talk-us] Relation roles for two-way way segments carrying routes in a single direction

Peter Dobratz peter at dobratz.us
Tue Dec 27 09:53:46 UTC 2016


There's a bit of confusion around this and it took me quite a while playing
around with the relation editor in JOSM ("Select Next Gap") to understand
how the "forward" and "backward" roles work.

https://i.imgur.com/RGV2XOX.png

First, consider how you would create a road route relation for your example
if the red segment didn't exist.  Also, for the moment ignore the signed
cardinal directions of the route.  In that case, you would arbitrarily
chose to start from the left-most or right-most segment in the picture.  If
you chose to start with the right-most segment:

right-most (role: "")
blue (role: "")
green (role: "")
left-most (role: "")

All of the roles would be empty and you would not need to use the roles
"forward" or "backward".

Now consider that the red segment exists and you need to indicate that the
road route splits in two and then reconverges.  In this case, you would do
the following, again starting at the right side of the picture:

right-most (role: "")
blue (role: "backward")
green (role: "backward")
red (role: "forward")
left-most (role: "")

You traverse the segments where the road splits first following the
direction of the route and then backtracking to the point where the road
splits and then start adding segments with empty roles.  If either blue,
green, or red is reversed in direction, then they would need to have the
role "backward" instead of "forward", but would still retain the same
position in the list (by convention red should not be reversed since it has
oneway=yes).


So now consider that you want to change the route to indicate "east" and
"west" signed cardinal directions.

One idea is to leave the roles as "forward" and "backward" and just add a
direction=west tag on the relation object.

One idea is that "east" and "west" become synonyms for "forward".  First,
reverse the direction of blue and green and change their roles to
"forward".  Then change the roles to "east" and "west":

right-most (role: "")
blue (role: "west")
green (role: "west")
red (role: "east")
left-most (role: "")

In this case, it is critical that blue and green are not reversed again.


Another approach is to create separate route relations for each direction
of the route.  In that case, you would have one relation with
direction=east:
left-most (role: "")
red (role: "")
right-most (role: "")

And a separate relation with direction=west
right-most (role: "")
blue (role: "")
green (role: "")
left-most (role: "")

In this case, it will also help to update the name tag of the relation to
include "(East)" or "(West)" to more easily tell the route relations apart
in the editor.  Also, the relations can be added to a route_master relation
(type=route_master  route_master=road).


Overall, I think it is cleanest to create 2 route relations, 1 for each
signed cardinal direction of the route.  You don't have to arbitrarily
decide whether to start the route at the eastern or western terminus as
each route relation has a natural starting point based on the signed
cardinal direction.  You don't have to deal with roles on member Ways,
which are very confusing.  You don't have to worry about the direction of
each member way either (again in practice many of them will be marked
oneway=yes and have the direction following the flow of traffic).


Note that whatever approach you chose, the route relations will often break
when the member Ways are split or combined.  Not all OSM editors do the
right thing to preserve the contiguousness of the route relations when
performing these operations.  When people decide to add lane or speed limit
information to the roads that make up the route, they may inadvertently
break the route relation.  In the rare case where multiple users are
concurrently splitting Ways that belong to the same route relation, the
relation usually breaks.

Peter

On Mon, Dec 26, 2016 at 9:29 AM, Albert Pundt <roadsguy99 at yahoo.com> wrote:

> So I understand that one-way ways carrying a route (e.g. a one-way pair or
> divided highway) should have relation roles of north/south/east/west, but
> say you have a situation like this <https://i.imgur.com/RGV2XOX.png>. Say
> you have an east-west route that follows the primary roads in that picture.
> The eastbound direction follows the channelized right turn slip ramp,
> marked with a red arrow. The westbound direction follows the blue-arrow
> way, before turning left onto the green-arrow way.
>
> How should relation memberships and roles be assigned here? I would think
> that the slip ramp would be part of the relation, since right-turning
> traffic must follow it. Ideally, that would be given the role "east", but
> what about the green and blue ways? It might seem right to give them the
> role "west", but how then is it differentiated which direction is westbound
> for it? Since all the ways in this picture are arranged "pointing" north or
> east, the green and blue ways would need to be given the role "backward",
> which is the older way of doing things that can't specify cardinal
> direction. Is replacing the single relation with separate relations for
> each direction the only good way to do this, or are such two-way segments
> the only times that "forward" and "backward" roles should be used?
>
> I checked the wiki page
> <https://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States#Role.3Dforward>,
> but it doesn't seem to specify. Instead, it just says such cases are very
> rare (which is only true relatively speaking, as routes very commonly turn
> at intersections with channelized right turns, making situations like the
> linked example very common.
>
> --Roadsguy
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20161227/aa4dd72b/attachment.html>


More information about the Talk-us mailing list