Recently, I was using a navigation app that uses OSM data, for driving directions. I was driving north on a divided road trying to enter a freeway, at a partial cloverleaf interchange:
Instead of directing me to take the ear ramp towards the northeast, it directed me to make a u-turn onto the ramp on the northwest, which is intended to move people from southbound Southeast Cary Parkway to US-1 Southbound. This is obviously wrong to me as a driver (that’s what the ear is there for!) but it is not signed.
The wiki page on Relation:restriction says " Don’t map turn restrictions that are the default for a given jurisdiction and are not signed." With that said, is this case a reasonable use of a no_u_turn restriction? I think it is, but one could say it’s the default - but then I struggle to see how navigation apps would be able to gather (as a human can intuitively by understanding the rules of the road) that you can’t u-turn there.
I’m seeing this behavior in GraphHopper but not when changing the routing engine to OSRM or Valhalla. I don’t think any of these router instances have updated to ingest the new U-turn restriction yet. Maybe the cause is suboptimal weighting in the FOSSGIS GraphHopper service’s car routing profile, since the on-ramp to the left results in a router 710 feet (216 m) shorter.
I just added advisory speeds to the cloverleaf ramps, which might not help matters. According to this debug map, OSRM assumes both ramps have a speed of 27 miles per hour (45 km/h) but penalizes the cloverleaf ramp only very slightly due to its curvature, but with my change, the penalty would be much more severe.
There has been some debate about whether implicit turn restrictions are acceptable. I don’t think the U.S. community has ever come to a clear consensus against them. At least the relation should have implicit=yes so we can easily identify it for future discussions like this one, and so that data consumers can distinguish them from explicit turn restrictions if necessary. The inability to make this distinction is one of the reasons we have a guideline against tagging for the renderer router.
Many routing profiles already try to avoid U-turns if possible, but the way this intersection is modeled, they may not recognize that it’s a U-turn due to the geometries involved. It’s notoriously difficult to detect and collapse a complex intersection involving dual carriageways, and the major routing profiles aren’t factoring in the road width when calculating turn angles. This is one kind of ambiguity that the manoeuvre relation type was designed to mitigate.
In theory, a router should heavily penalize a left turn across a multilane road where the cross street has even more lanes – a signal that you’d potentially have quite a bit of traffic volume to wait for. Some routers do penalize left turns in general, especially those optimized for larger vehicles like delivery trucks and buses. However, it’s quite a balancing act in general, because the difficulty of making a left turn depends on so many factors. Local delivery companies get away with it because they don’t want the most direct route anyways.
North Carolina seems to be particularly unhelpful in this regard. Other states where I’ve lived either disallow U-turns unless explicitly allowed or always mark allowed U-turns in case of any ambiguity, allowing us to simply look for a sign or road marking. The left lane’s left turn arrow clearly refers to a left turn onto Kirkshire Circle, but this Stack Exchange answer makes a compelling case that we can’t assume the lack of a U-turn sign means U-turns are prohibited here.
For what it’s worth - the new U-turn restriction was one I added, with a “check this edit” flag, just after making this post.
Makes sense on the implicit=yes flag - will edit the restriction to add this. Thanks for the background.
I wonder if an alternative solution is not to mark the on-ramp as being part of the intersection, but starting slightly after it, as other maps on the internet seem to do.
That crossed my mind too – it would certainly be a reasonable thing to do, though it’ll require a bit of surgery with the existing connectivity relation. Might as well remodel that bit of Cary Parkway into a single roadway instead of a divided highway (dual carriageway), since there seems to be no “physical separation” between the northbound and southbound lanes, only a painted crosshatched area. Still, I don’t think the turn angle would work out to be steep enough that a router would naturally avoid it. It might even consider it merely a sharp turn instead of a U-turn. An implicit turn restriction would still be needed to have the effect you’re looking for.
I would like to know, what navigation app using OSM data could be deploy in west africa ? Why? we are struggling to implement few urban highways and may be soon, our city town street could have a so complex roads. Subsequently, OSM data for navigator app would be more than essential tool for drivers.
