Restriction=no_u_turn, from and to roles are the same way. Do these serve any purpose?

The wiki says “Don’t map turn restrictions that are the default for a given jurisdiction and are not signed.” I would guess that any router knows better than to suggest such a maneuver unless it’s really necessary anyway. The only reason I ask is because there are 350 of these relations in my city. I checked several and they appear to have all been created by paid mappers from Amazon, Lyft and other companies. (Are these people paid per changeset? :roll_eyes:) The creators don’t appear to be active any more.

Well, are these no U turn restrictions signed, and are U turns allowed otherwise by default in your jurisdiction? Where I live (California, United States), U turns are by default allowed at intersections but are frequently restricted. If the road is undivided, the restriction relation necessarily has the same way in the from and to roles. Example: Relation: 5689125 | OpenStreetMap

This is what that looks like at street level, with a no U turn sign (from Bing).

So absent other information, these mappings seem perfectly valid to me.

2 Likes

Well, I thought they were always illegal in Oregon unless signed otherwise, but I just looked it up. Oregon law says U turns are illegal between intersections and at traffic signals unless signed otherwise. Many of these relations are at signals, and I’m not seeing signed restrictions for the ones that aren’t.

The wiki goes on to say:

If the absence of the traffic sign would not have been tagged, data users can only guess whether the situation in the field is compliant to the legal default or that this road segment has not yet been evaluated by a mapper.

It gives the example of maxspeed in the absence of a speed limit sign, but this caveat is even more relevant to U-turn restrictions. OSM-based routers generally go to great lengths to avoid issuing U-turn instructions at intersections, regardless of U-turn restrictions. In a typical scenario, the user has overshot a left turn they were supposed to make, so the router calculates a new route:

  1. In 500 feet, turn left.
    (wait a few moments)
  2. In 800 feet, turn right.
    (wait a few moments)
  3. In 500 feet, turn right.
    (wait a few moments)
  4. In 800 feet, turn right.
    (wait a few moments)
  5. In 500 feet, turn right.

It may take the user a while to cotton onto the fact that it’s effectively telling them to make an elaborate U-turn around the block. If it had just told the user about the U-turn upfront, it might’ve saved them a bit of time and frustration. Of course, a U-turn isn’t always allowed; instructing the user to make an illegal or impossible U-turn is also frustrating.

Unfortunately, the mainstream routers added support for turn restrictions back when coverage of U-turn restrictions was very poor, so even in a jurisdiction where U-turns are sometimes allowed, the router could not confidently tell you to U-turn without the running risk of telling you to do something illegal. Instead, routers were configured to take the easier conservative approach of almost never telling you to U-turn except at a dead end. This is actually the opposite of what many users need.

This limbo persists years later because of the patchwork of laws regarding U-turns. Indeed, some jurisdictions never allow U-turns anywhere, and local mappers fiercely defend the map against the scourge of U-turn restriction relations. Brazil is notorious among router developers as an example of this situation, but other countries and regions have similar laws and sentiments too.

There are some problems with the concept of not mapping local defaults related to turn restrictions. The wiki’s guidance on regional defaults only envisions traffic laws at the national level, not an aggressively decentralized system like in the U.S. Though U-turns at signalized intersections are generally legal in Ohio, the City of Columbus has completely outlawed them and posted educational signs to this effect in strategic locations around the city.

We can easily hand-wave and say that a router is responsible for allowing or disallowing U-turns based on local laws, but routers can’t honor these laws if they don’t know about them. Researching local laws on U-turns would require an inordinate amount of paralegal work. According to one legal publisher, there are 3,638 municipal ordinances related to U-turns in the United States alone, and they’re only one of several major publishers of municipal ordinances. At most, a data consumer might research the largest metropolitan cities, ignoring the rest, and maybe reserve that functionality for themselves in closed-source code. Meanwhile, the people who know their local laws are unable to do much about it.

Even if data consumers have access to a comprehensive database of local default rules about U-turns, it would be difficult to translate this database into correct routing behavior. Many jurisdictions, including Oregon, disallow U-turns unless otherwise posted (ORS 811.365). If data consumers are to assume the default of no U-turns, then how should one of these posted exceptions be mapped? There are only eight permission relations, all related to permission to turn right on red; no software understands these relations.

Approaching a left turn lane along a divided street, a sign in the median indicates that U-turns are allowed. (© 2017 justins83, CC BY-SA 4.0)

2 Likes

My Go-To MapFactor router has an option NOT to do U-turns in route computing (in case I missed a turn). A) prevents me from doing illegal things, not knowing the local laws to the T and B) Do dangerous things while the drivers from the opposite direction is busy with their router or the cellphone.

Been doing since a few months the divider tagging, solid or double solid in particular. Sure says here you’re not to cross / no- u-turn, albeit not all routers seem to know that… GraphHopper does not seem to when testing some routing with an absent U-turn rule. Maybe because it only sees connecting nodes and not evaluating what’s between those nodes, specially where there’s roundabout flares concerned making turns from off to on regardless the solid or double solid white line tagging. Some run blind on their router and do it.

this is nice idea, but problem is that it is extremely obnoxious/impossible for routers to know about all local laws

Personally, I disagree with this advise. Though in theory it may be possible to map legal u-turn status on some administrative areas? Then, in theory, routers can use this data to make assumptions.

I’ll leave these relations as is.

I can see the problem here. When a no_u_turn restriction exists, everything is fine. There is currently no way to specify that U-turns are allowed, which needs to be addressed. When there is no data to indicate whether they are allowed or not, the options are:

1: Assume U-turns are not allowed (current solution, not ideal)
2: Assume U-turns are allowed, (potentially suggesting illegal maneuvers, bad)
3: Refer to local laws (requires lots of research, likely impractical)
4: Let the user choose if they are allowed

If U-turns are assumed to be allowed, any region where U-turns are illegal would need restrictions everywhere. If the restriction is missing, the router would suggest an illegal maneuver. I doubt routers would opt for this. If they are assumed to be not allowed, relations with some new u_turn_allowed tag would be needed everywhere.

It may not be practical to refer to local laws everywhere, but maybe the most practical solution is to refer to local laws where they are known, and where they are not, assume U-turns are not allowed. We could tag administrative relations with traffic laws, but I feel like that’s opening a can of worms.

1 Like