Wrong Relations

I responded here, so others can also view and respond if they feel like…

And to the matter, I’m not sure what what it should be. restriction=no_u_turn, as it is now seems more logical to me.

  1. there is no real left turn there, that line that goes left (27615524) is simply the the crossroad on Emek-Bracha St. It’s only there because the rest of the street has a fence, and at that point the fence is gone.
  2. If I’m not mistaken there is a no-u-turn sign there. and if not, it is certainly so in some other places nearby.

It depends what you want to achieve.
If you want to reflect the street sign, then restriction=no_u_turn is correct.

However, routing applications doesn’t “see” this intersection as a u-turn, because of the small way (20665664),
so they do not restrict you, and might instruct you to do a u-turn there, which happened to me…
With a restriction=no_left_turn as described in my original message, routing applications will know that you cannot turn there to go to the opposite of Emek Bracha.


I want to follow an official tagging system that must provide enough data to routing applications. Routing is much more important that the street sign.

As I said, I do not know what is the official proper way to tag these places, in a manner that is routing friendly.
There are ways for the routing application to know that two one way streets are in fact one two ways street: special relations, guessing based on proximity of two one ways with the same name and maybe other methods I’m not familiar with. I want to follow the accepted solution, if such exits.

Also note, that no_left_turn can not replace no_u_turns in all the possible scenarios. Consider very common case of a left turn with a no_u_turn sign.

Well, as I said - Mkgmap (for Garmin) doesn’t understand the current tagging, and my proposal above fixes it.
I didn’t try Traveling salesman though.


This might be of some interest:

Regarding Mkgmap, I don’t think that replacing no_u_turn with no_left_turn is a good solution, even if it fixes a particular problem at a specific place.

A better workaround, if one you want to temporarily take this route, is to search & replace no_u_turn with no_left_turn in planet.osm, before feeding it to Mkgmap. Or, patch Mkgmap to handle both these tags the same way.

How do you suggest patching planet.osm?
By using way id’s? This isn’t a value to rely on, as it can be changed if the ways are edited.

I don’t understand why you’re looking for workarounds, when you can choose one of two perfectly good solutions.
No need to patch Mkgmap (and all the other routing applications…) and no need to patch the osm data if it’s wrong…

Mkgmap’s routing code works well. It does exactly what is defined in its input.
The input (if used for routing) is wrong, and not just for Mkgmap.
There is a “problem” (see definition below) with the osm data there. It doesn’t defined the restriction “correctly” (see below)


It depends what you want to achieve.
If you want to reflect the street sign, then restriction=no_u_turn is correct, and there’s no problem with the osm data as it is now.
But routing applications won’t restrict the user.

However, if you want to map the restriction to reflect the actual meaning of the road sign posted there, then it’s a different story.
As the roads are mapped there, there is no u-turn.
It’s a left-turn from the small road (to the other side of Emek Bracha).


Look at feature called Specialized Junction Editing by Cloudmade (under opensource development)

Blog : http://blog.cloudmade.com/2009/07/22/mapzen-an-easy-to-use-editor-for-openstreetmap/

Seems like a easy solution to build up complicated junction with several restrictions.