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

Paul Johnson baloo at ursamundi.org
Thu Dec 29 14:34:30 UTC 2016

On Tue, Dec 27, 2016 at 3:53 AM, Peter Dobratz <peter at dobratz.us> wrote:

> 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".

Assuming you're in a situation that the route starts and ends on single
carriageway, or things get complicated on a level that the existing tools

> 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 far, so good.

> 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: "")

This makes it nearly impossible, on a level for which a relation for a
relation traversing a state roughly the size of the ones in the American
west can take 12-16 hours of work for someone who is familiar with the
route in question AND working with large relations.  Please don't do this,
it breaks the editors.  And I don't mean the tools, I mean the actual
people editing.  It's extremely discouraging to be rocking along on an edit
only to come to a screeching halt just to end up spending the rest of the
weekend validating a relation.

Cardinal directions should only be used on roles for relation members that
are themselves relations.  Example:  You have a super relation for a very
long highway.  It contains two relations, one for each direction, so the
relation roles would be, say, east and west, or north and south, or
clockwise and counterclockwise, or (in very rare edge cases) east and
north... (I know of only one example of this, though I haven't bothered to
re-survey this since it changed highway number to see if the directions
changed).  The child relations would have ways as members that are all
contiguous with forward/backward as roles, all pointing in the direction of
travel.  This is about the only way to get a relation that validates and
isn't a completely impossible to maintain situation on JOSM (and it gets
even worse on id and potlatch!) on situations that end on a dual
carriageway (such as motorways crossing state lines).  You touched on this
further down...

> 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).

I'd include forward/backward as the role as a relation that has a direction
can only be traversed in one direction.  I would also recommend this method
for any route that ends on a dual carriageway on one or both ends.  For
routes that end on a singe carriageway at both ends but have medians in the
middle, a single relation is easy enough to work with so long as the roles
used are empty, forward or backward with NO other values.

> 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.

 JOSM does a pretty good job of not breaking relations in the first place
for the most part.  Though the suggestions I mentioned above also greatly
help in not making it a tremendous pain when it comes time to check a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20161229/6e26e75e/attachment.html>

More information about the Talk-us mailing list