OpenStreetMap logo OpenStreetMap

Turn restrictions are pretty common to OSM, them being the second most popular relation type, after multipolygons. Usually a restriction is a relation with two highway ways, “from” and “to” and a “via” member connecting these. The value of “restriction” tag adds a meaning: which kind of turn is forbidden on this route. For example, “restriction=no_left_turn” (and any other no_* value) forbids going from “from” to “to” way using “via” intermediate objects. Alternatively there are “only_*” values, forbidding any routes from the “from” way except the one leading to “to”.

Usually “via” members are nodes, which makes them redundant for all types of restrictions except “no_u_turn” (which has the same way in “from” and “to” roles). Thus supporting them in a routing libraries has been easy. But — a “via” member can also be a way. For example, on a dual-carriageway, like the one pictured below. Supporting ways for “via” members is hard, but they constitute less than 3% of all restriction relations, so developers have often ignored these.

Screenshot of the new restriction editor in iD

On the 5th of March, a new major version of iD editor was released. Among the changes, one stands out: the restriction editor got a big update. Now — finally — it allows adding “only_straight_on” restrictions (and others of the kind). And using ways in “via” roles. It looks awesome, and I’d like to thank Bryan for this feature. It is very intuitive, and I like that the iD team puts user experience first.

This change will obviously affect the number of restriction relations that have ways in “via” roles. And these have been hard to deal with. I don’t know if all routing engines support such restrictions. MAPS.ME currently does not.

So to decide if supporting these restrictions should be a priority, I conducted a small research on how the change to the editor affected the map. First, I looked at the number of restriction relations by “last edited” date:

A chart of restrictions by four categories

The black vertical line marks the day before the announcement.

You can clearly see that after the announcement, mappers started adding all kinds of restrictions, not just the new supported types. The most popular kind are “no_*” restrictions (e.g. “no_left_turn”) with a node in the “via” role. But you can notice the surge in “only_*” restrictions (e.g. “only_straight_on”) after the announcement, which by now has almost receded to the pre-March levels, ~100 a day. And there is a clear rise in new relations having ways in the “via” roles, from 10-20 before the new iD version, to 50-200 (!) after. While coming in waves, the number does not seem to decline.

Let’s calculate percentages of these previously rare kinds of relations:

Percentages of only_* relations and ways in "via" roles

I have extended the period a bit, to account for a “calm” two-month period. Obviously, the rate of “only_*“-type restrictions did not change at all. The increase in their absolute numbers coincided with the similar increase in relations of other types.

But the percentage of relations with ways in “via” roles has definitely started to rise. From 3-5% before the new iD to 10% and rising after. It is entirely possible this line will settle on around 15-20%, which means around 300-400 new such relations every day. Which means, if you make a routing engine, you can no longer ignore relations with ways in “via” roles.

Traditionally such relations were made for restricting u-turns on a double-carriage highways. This chart confirms it:

Number of no_u_turn relations compared to others

The main increase is still in u-turn restrictions: as many as 260 a day the week after the announcement. Naturally, a developer might think they need to implement the support for only that type of a relation with a way in “via” role. It probably could be done with some kind of a shortcut patch.

Alas, other types of restrictions with ways as “via” are no longer virtually non-existent. From 1-2 a day, mappers now add 20-40 relations of other types daily. Here is the list of restriction types for relations with “via” member ways (thanks Roland and Martin for the Overpass stack!):

  • 23429 no_u_turn
  • 690 no_left_turn
  • 442 only_straight_on
  • 386 no_right_turn
  • 240 no_straight_on
  • 185 only_left_turn
  • 114 only_right_turn
  • 7 only_u_turn

Okay, no way around this issue. Looks like any routing engine that does not support ways in “via” roles won’t be able to route properly from now on. And we in MAPS.ME have to catch up.

But… Is that all? Let me show you this:

Chart of relations with more that one "via" member

Yay, iD editor supports restrictions that span two and more ways! We had 800 such relations in total before March, and in just two weeks mappers have added 150 more. I am pretty sure there are no more than two routing engines supporting such chains of “via” members, and that’s being generous. So — get to work, developers: the routing over OpenStreetMap has just got much more complicated.

Discussion

Comment from PlaneMad on 23 March 2018 at 05:06

Nice analysis. Goes to show the impact any feature on osm.org has on the data quality of the project.

Been following the development of this feature on iD, its an amazing effort by Bryan to get this out. Thank you from everyone!

Comment from Nakaner on 25 March 2018 at 12:26

@Zverik Thank you for counting the numbers.

Did you checked some of the new turn restrictions with a via way member manually to ensure that they really need a way as a via member? Maybe the UI of iD needs to be improved because its users understand it wrong? (I don’t remember a lot of real world examples where a restriction needs a via way)

Comment from mmd on 25 March 2018 at 13:03

I put together a small Overpass query to find such instances with exactly 1 from, 1 to element and at least 3 way members (that’s close enough for the purpose of this analysis):

http://overpass-turbo.eu/s/xjH

Caveat: query uses not yet released feature count_by_role (will be part of 0.7.55 release)

Comment from seav on 31 March 2018 at 17:36

For developers looking for algorithms on how to support via-ways, you could look at this issue at the OSRM GitHub repository. TL;DR: you need to preprocess the routing graph.

https://github.com/Project-OSRM/osrm-backend/issues/2681

Log in to leave a comment