Talk:Relation:restriction

Splitting Ways

Does as comment need added to explain that ways may need splitting in order to add the restriction? Do you even have to split the way? --RobJN 23:57, 22 October 2012 (BST)

Yes, we do need to split a way at the via junction otherwise the direction of restricted flow can be ambigous ambiguous on two way roads. For purposes of data maintainance, it would also be good practice to keep the from/to members as small segments split at road junctions and not long ways that span multiple kms. Is there any reason not to split? --Planemad/Talk 06:51, 21 September 2017 (UTC)

Every time somebody has a proposal that requires more splitting of ways, people complain that it makes data maintenance harder. For example, it might be easier to add a speed limit to an entire road if it is not split. Germyb (talk) 21:29, 22 September 2017 (UTC)

Time based restrictions

The following comments have been taken from Talk:Relation:restrction/Archive. How do we handle turn restrictions that apply at two separate times of day (typically morning and afternoon rush hour)? These are very common here in Toronto. Andrewpmk 23:51, 8 October 2007 (BST)

With regard to the times of applicability for a tag value (for example a turn that 'can not be made between 8am and 10am and between 4pm and 6pm on weekdays', or a gate that is closed from 'dusk til dawn', or a street that is closed on 'market days and monday', or 'during school holidays from 8am to 10am' etc etc, can I suggest we used the tag 'Validity Period' to contain a free-form text expression that will have its own syntax and be parsed as required. It might seem a bit of a cop-out, but I don't think anything else will be flexible enough. Incidentally this is the tag name and also the approach that GDF uses (see section 6.4.4). For tags that change during a defined period (the validity period) I suggest that the default value should be coded into the feature itself (the way, the node or the relationship), and that a Composite Tag (another relationship) will be used to hold both the Validity Period and also the overriding tag(s) value(s). User:PeterIto 29Oct07

iD

Can't figure out how to put hours range on part of a junction in iD. Jidanni (talk) 00:17, 2 August 2023 (UTC)

Specifying time of day

The hour_on/hour_off tagging for part-time turn restrictions is inflexible because it does not allow for multiple time periods. I suggest that these tags be replaced with the more flexible syntax on Key:opening_hours. For example, for a turn restriction that is effective from 7-9am and from 4-6pm Monday-Friday: hours="Mo-Fr 7:00-9:00,16:00-18:00". Andrewpmk 07:04, 2 June 2008 (UTC)

I agree. FWIW, I currently tag the example given as:

hour_on=07:00;16:00
hour_off=09:00;18:00

AM909 20:33, 20 July 2010 (UTC)

I've created a proposal (Proposed features/Conditions for restriction relations) that would solve this problem by adding a tag like if:time=Mo-Fr 7:00-9:00,16:00-18:00 to the restriction relation, using opening_hours syntax. --Tordanik 14:25, 10 July 2011 (BST)

iD

Can't figure out how to put hours range on part of a junction in iD. Jidanni (talk) 00:18, 2 August 2023 (UTC)

Different restrictions for different vehicles

If a restriction applies only to a vehicle type (e.g., hgv), the 'except' tag with all other allowed vehicle types is not really useful, if the list of vehicle types will be expanded in the future. A positive form for which vehicle types the restriction applies is needed. The usual access tags are possible to be used, but there meaning in this context is not really intuitive. New tag 'apply_to', or 'vehicle_type'? --BerndR 26 Oct 2007

I think I see what you mean about the "access" tags--if the restriction has a tag "psv=yes", does that mean the restriction applies to a bus or does it mean the bus is unrestricted? (I think the latter makes the most sense.) However, in the interest of preventing tag proliferation, I think this could be handled by using the "access" tags with good documentation. --SiliconFiend 20:24, 26 October 2007 (BST)

Since using psv/motorcar/...=yes is ambiguous (per above comments) and the tag 'except' is defined for this relation type, we could allow only the value 'no' e.g. psv=no to explicitly list that psv are not allowed to turn to be in line with other uses of psv/motorcar/..=no - no means no access for that type.

I have the following example:

    | 1
    |
====+=====
2   |    3
    | 4

and the following rules: it is only allowed to go from 1 straight forward (to 4), and from 2 you are only allowed to turn left to 4. How schould we tag this? Why is it not allowed to put two "to" Members in the Relation? Sven Anders 11:56, 27 June 2008 (UTC)

As we discussed on the talk-de mailing list, I understood the relation for the only_* types in the way, that the to member is the street where you are allowed to continue your way. That way you do not need multiple to members. If multiple continuations are allowed, you just add a relation for each allowed continuations or use a no_* type relation if that is shorter (in case of the crossing of just two streets you would always only need either on no_* or one only_* relation for any given access to the crossing; multiple relations are only needed if more streets meet at the crossing). Note: a renderer should render a no_turn_left relation as [[1]] in countries that show the allowed ways instead of the forbidden ways on their signs (and should show forbidden directions where only_* relations are used in countries that do not sign what is allowed but what is forbidden). -- Mawis 15:30, 27 June 2008 (UTC)

I would interpret the access-style tagging opposite to Sven. Since the whole thing is about restriction (as it stands currently), I take psv=no to mean that the restriction does not apply to psv (and have been using it in this way). Since the "except" role is currently defined, I support extending this to include an "only" role to avoid having to list every other possible vehicle type (and figure out what those are) when a restriction applies only to trucks, for example. AM909 20:42, 20 July 2010 (UTC)

Specifying an alternate route

Some restrictions will suggest an alternative route to use before you arrive at the junction. Should we tag this or assume the routing software will handle it itself? I'd propose that a route relation be created for the alternate route with route=restriction_alternative, and add it to the restriction relation with the role of 'alternative_route'.

--Thomas Wood 16:02, 8 June 2008 (UTC)

Allowed directions for each lane

This relation can be applied to define allowed directions to move for each lane. I propose to add tag "lane" to specify lanes where this rule applies. Lanes of from way will be numbered from outer one to inner one. This can be used to give suggestions to change lane on junctions.

You do not need to number the lanes to do that. If the lanes are mapped individually and your gps is good enough to determine the lane you are one, it can give relative guidance, e.g. "switch two lanes to the left". If you grouped the mapped lanes into a relation, an absolute offset can be used too, e.g. "use the third lane" (leftmost lane being the first), else the routing software has to do distance calculations to find nearby lanes.

For example, we have road with 3 lanes. Outer one is to turn right only. From next you can go straight and turn right if you on passanger car. And from innermost you can go straight and left. Left is only allowed from 21:00 to 7:00.

Than there will be 3 restriction relation, one for each lane, describing each situation, as if it was a different roads. It is also possible to add 4th restriction to whole turn, but it can be combined from first 3 one.

Software will check common restriction first, get default allowed directions for each lane and than override them by applying lane-specific one. --LEAn 13:46, 1 July 2008 (UTC)

+1 If we define a numbering system for lanes, e.g. 1 for the almost right lane, we can extend the Turn restrictions (e.g. by lane=<from>;<to>) for defined lanes.

Example:

Way A: oneway=yes lanes=4

Way B: oneway=yes lanes=3

Way C: oneway=yes lanes=1

Node n: shared node between the ways

TURN RESTRICTIONS:

TR1: type=restriction restriction=only_right_turn lane=1;1 Members: from: A via: n to: C

TR2: type=restriction restriction=only_straight_on lane=2-4;1-3 Members: from: A via: n to: B

(With a numbering system we could split or merge lanes with one additional tag within the shared end node of two ways, e.g. lanes:fork=2;2-3).

This ist IMO better then that new proposal: Talk:Proposed features/Turn Lanes Another scheme would be introduced for turn restrictions with that proposal. Because the relation-based turn restrictions scheme is already well-established, I would NOT introduce a new one. I am against the concurrent use of two basically different schemes Unnecessary Proposal. --bkmap 09:22, 17 October 2011 (BST)

Or just draw each lane individually, use a star topology and route turn restrictions over the node in the middle (or the resulting road_links, as you like). See Talk:Lane_tagging_comparison..

No, don't do this. Only map separate roadways as separate roadways. --NE2 01:58, 5 March 2012 (UTC)

Symbols for turn restrictions

There are much more different traffic signs in use than the value set for the key restriction suggests. E.g. besides only right there is an only half right. Several combinations are also in use, e.g. only right or half left.

Therfore we should not limit the values for this key to a few different traffic sings. It would be better to set up a rule for building this value instead.

I would like to suggest that - following one of the prefixes only and no - every direction may be added. Examples:

only_right
only_left_right
only_straight_left
no_left
no_back (this means no U-turn)
only_halfleft_right
only_halfright

The renderer has to parse this value. It must recognize the following words:

only, no
straight, left, right, halfleft, halfright, back

The renderer does not need to consider country specific rules because the type of the sign is layed down by the value. E.g., at a rectangular intersection of two ways the values no_left and only_straight_right have the same logical meaning for navigational devices but are displayed as traffic signs of different types.

Furthermore, the renderer does not need to have all symbols ready for every possible turn combination. It can assemble several arrow symbols as they are needed by simply overlaying their images.

How do you think about this? --Gypakk 06:54, 2 July 2008 (UTC)

A only_left_right is sufficiently defined if driving straight on is forbidden. Likewise only_straight_left is no_right_turn. A renderer interested in showing such signs would have to check all roads leaving the intersection (and all the restriction relations, too) and then combine the appropriate signs, just as a router needs to check all roads leaving the intersection. Knowing the side of the traffic seems likely, as a no_left_turn (or a no_right_turn) also forbids u-turns in some countries but not in others where the traffic uses the other side of the road.Alv 06:46, 21 July 2008 (UTC)

As crossings do not always have 4 streets only, I prefer a clockwise numbering system instead of using "left" and "right". --Lulu-Ann 10:13, 2 July 2008 (UTC)

Numbers? E.g. 1=only_right, 2=only_halfright, 3=only_straight, ... 11=no_right, 12=no_halfright? Why such cryptic? We talk about the description for the traffic sign representation. Nothing more. A navigation algorithm will (hopefully) ignore this information. The relation itself (from, via, to) is all what it needs. (Why did OSM Wiki server run this awfully slow today?) --Gypakk 22:10, 2 July 2008 (UTC)

Turning restrictions are interesting for routing only. Why should I map them for a paper map? I agree that a speech representation is needed, but three kinds of left, three for right, a U-turn and a straigh-on is simply not enough for existing crossings. Driving schools can tell you about the problems, how to tell the student where to drive on a complicated crossing, which is important for the test. If we want to map for the speech output, we should map the allowed ways, not the forbidden, so the speech output knows "which kind of left" to tell. --Lulu-Ann 12:03, 3 July 2008 (UTC)

So what if I'm driving in a city I don't know very well, and I plan a route using my paper OSM map - only to find out that there are restricted turnings, and now I have to divert 3 miles to get to a place where I can get to my destination? The AA map of London that I had a while back had turn restrictions marked. I don't see why someone can't plot a route using a paper map and expect something like this to show up. Richard B 12:07, 8 July 2008 (UTC)

The only purpose of the restriction=* tag is to store information about the traffic sign. This tag will be useless for every other purpose because it contains redundant information only: The number of a specific outbound edge can be easily retrieved by a simple mathematical operation in the database. Same applies to the angle of every allowed or forbidden turn. So, the navigation software does not need the restriction=* tag at all.
If we come to the conclusion that it's not useful to store the type of traffic sign within this type of relation, then we'd better get rid of that tag... --Gypakk 13:36, 3 July 2008 (UTC)

Oh, OK, if this proposal does not help with routing, it is totally useless to me. I won't print a single map with a bunch of traffic signs plottet around each and every junction. Go ahead, I will propose something useful instead. What is the opinion of the others? Is this for routing? --Lulu-Ann 15:04, 3 July 2008 (UTC)

You're misunderstanding Gypakk's comment. The restriction relation is of course meant for routing. However the restriction tag on the restriction relation is an extra bit of information that is not required (nor usable) for routing, it just makes it easier to symbolize the kind of restriction. Symbolizing the restrictions, through traffic sign icons or something else, makes sense as a "debugging tool" so people can see which turn restrictions are in the database. --Frederik Ramm 09:35, 15 July 2008 (UTC)

For routing the only used and required information from restriction tag is in my opinion prefix no_ / only_ --*Martin* (talk) 12:26, 24 May 2013 (UTC)

OK, I think I got it now. I would have expected the redundant information which traffic sign is used in a tag called "description" or similar. Well, can anybody please make some photos and create 2 or 3 examples, so we can learn by copying? --Lulu-Ann 13:09, 15 July 2008 (UTC)

In some cases it is necessary to either 1) use the tag restriction=* on the relation or 2) define multiple nodes in the role via. Example, an intersection of two ways (way A in directions N and S, and way B, directions E and W). Both ways continue on both sides of the intersection and both are not oneway, but only turning left from N to E is forbidden. Defining only ways in roles from and to and the intersection in the role via effectively forbids any turns from S and from N. Including an another node just before the intersection on the N-bound section still leaves the turn N->W forbidden. Then either adding a restriction=no_left_turn or still another node, one on the E-bound way, again with the role via, makes the turn restriction unambiguous. Thus an unambiguous restriction for aforementioned intersections requires three via nodes or two via nodes and the tag restriction. If turning left were forbidden coming from both directions N and S, a single restriction with the restriction=no_left_turn and single via node would suffice. Alv 06:23, 21 July 2008 (UTC)

suggestion: multiple to members

There are many junctions where not only one possible turn is forbidden. With the current definition, you have to create multiple restriction relations. I wouldn’t see any problem with allowing multiple to members. --Tordanik 21:25, 22 September 2008 (UTC)

I'd like to see that acknowledged, too. Even if it were only allowed for unambigous cases. Alv 20:35, 17 October 2008 (UTC)

restriction=

This particular field looks like tagging for the renderer to me. Ideally, this should be rendered not as a road sign, but as arrows on the ground, leading from and to the places where you can't go. I remember seeing a number of maps in my time which showed prohibited turns roughly like the image to the right, which would require only knowing the core values of "from", "via" and "to". The tag isn't useful for routers (I would hope a talking router doesn't bother me with irrelevant details such as where I can't go, and concentrates on where I can and should be going), and a rendering like the one on the right doesn't depend on being able to tag the right sign or needing a usable icon. It scales to more than one prohibition at the same location. Chriscf 14:25, 17 October 2008 (UTC)

- i don't get what you mean, the router should know about where you can't go, to be able to determine where it CAN go.

Without the tag restriction=* on the relation we would have to either 1) split all the related ways at the intersection or 2) have at least three via nodes in every restriction, when we wanted to unambiguously describe a restriction applying only from one incoming direction to one outgoing direction and the ways were not tagged as oneway=yes. Alv 15:10, 17 October 2008 (UTC)

Splitting isn't too cumbersome, especially as junctions usually are the place where other things (such as names, maxspeeds, number of lanes, width …) change, too, and necessitate splitting anyway. Also, in some cases (more than two „rights“ etc.), splitting is inevitable. Thus I tend to consider this tag an unnecessary burden for software handling restrictions and would prefer it to be redefined to pure rendering information. But that's just my opinion. --Tordanik 16:25, 17 October 2008 (UTC)

Routing restrictions should always be described unambiguously. If that means extra "via" points, or redefining the relation to include the possibility of allowing nodes to be the "to" and "from" locations (since ways can already be "via"), so be it. The tag also has the ability to be misleading (when does a right turn become a half-right or a u-turn?). It should not be included as an aid to rendering, since not only do we not tag for the renderer, a renderer already has enough information - restrictions should be rendered along a path (as illustrated), since this is unambiguous when viewed from all directions. Chriscf 08:29, 20 October 2008 (UTC)

Proposed changes

Remove day_on, day_off, hour_on, hour_off and replace them with the better opening_hours=*! This tag should shows the times when the turning-restriction does NOT apply. See Specifying time of day!
Use restriction=* only with the two values "permissive" and "restrictive" to tell if this relation is a "only_*" or "no_*"-rule.
Move the various text values from the old "restriction"-key to road-sign-nodes or a "sign"-key. Those nodes are not needed for routing but useful for renderers.
Replace "except" with the optional and unmistakable access=*-values "affected", "unaffected" and others. See Different restrictions for different vehicles!
Only tag the to/from-ways and not the junction-node. In most cases it is obvious where ways cross. If a from-way crosses a to-way more than one time, it should be split!

Why

The proposed tags are better parse-able by software
";" is a widely accepted value-separator while "_" is not
No problems with ambiguous values like "no_half_right_left"
Other access-values like designated, destination, permissive and private can be used
Less relations needed, because you can use several "to"-ways
Can handle highway=*_link driveway where a straight-sign is used for a right turn

Logic

If restriction=permissive is used, unlisted ways are restricted.
If restriction=restrictive is used, unlisted ways are free to use.
If several relations overlaps, the most restrictive rule should be used and validation tools should show a bug!

If a no access-tag is used, access defaults to affected.
If only *=unaffected access-tags are used, access defaults to affected.
If only *=affected access-tags are used, access defaults to unaffected.
If *=unaffected and *=affected are used (should be avoided) access defaults to affected.
Exactly one node should be shared by all member-ways and that note should build the start or end-point of each of those ways, if not the relation is invalid and validation tools should show a bug.

Example

   1|
    |
====+=====
2   |    3
    |4

You are on 2 and are only allowed to turn left to 1, bicycles are not affected by this rule. There are two ways to tag the logic, but they could result in different rendering.

<relation>
 <member type="way" ref="2" role="from"/>
 <member type="way" ref="3" role="to"/>
 <member type="way" ref="4" role="to"/>
 <member type="node" ref="5" role="roadsign"/> # optional
 <tag k="type" v="restriction"/>
 <tag k="restriction" v="restrictive"/>
 <tag k="bicycle" v="unaffected"/>
 <tag k="roadsign" v="only:left"/> # optional
</relation>

or

<relation>
 <member type="way" ref="2" role="from"/>
 <member type="way" ref="1" role="to"/>
 <member type="node" ref="5" role="roadsign"/> # optional
 <tag k="type" v="restriction"/>
 <tag k="restriction" v="permissive"/>
 <tag k="bicycle" v="unaffected"/>
 <tag k="roadsign" v="only:left"/> # optional
</relation>

--Phobie 05:12, 13 November 2008 (UTC)

Discussion

That seems like a good idea, though the "directions" tag should be left out. We don't tag for the renderer. In particular, it opens up a whole new can of worms over how they're rendered in the first place. There should already be enough information in the relation without it to determine a suitable rendering. The vehicle descriptions should be consistent with what we use elsewhere, though whether this is better dealt with using a "psv"="no" or an "except"="psv;bicycle" should be looked at. Chriscf 09:12, 24 November 2008 (UTC)

"Yes sir! I mean no sir! I mean yes to the first part, and no to the second part! Sir!"

I removed "directions" and replaced it by "sign"-nodes which should be part of the relation. (There we can use those evil "no_turn_right")

The "except"-thing is not possible, because we need stuff like hgv=delivery + motorcar=permissive + bicycle=unaffected! With a except key that would lead to three overlaying relations, which will not be understand and tagged by anybody. --Phobie 10:18, 8 December 2008 (UTC)

In that case, the usual access tags is the way to go. I still think the "sign" nodes are tagging purely for rendering, and likely to be of little use in that scenario anyway, so should probably go. The from/via/to should unambiguously describe the permitted or prohibited paths - this already gives us enough information to render it - see the example above. Rendering a path as a sign is a very, very bad idea. Chriscf 11:45, 9 December 2008 (UTC)

We have a junction here with all ways access=yes but only psv is allowed to turn left. It would be a bad idea to mix vehicles and permissions in one "except"-key like except=psv;bicycle;delivery;permissive! The sign-key is an optional value, it could be useful for routing-software to show the user the exact same sign as seen on the street. From the turning restriction path it is sometimes impossible to guess the sign used. --Phobie 12:44, 10 December 2008 (UTC)

Sorry, perhaps I wasn't making myself clear. We should represent the vehicle types in the relation using the same style as the access tags (as you suggest) - so a "no left turn except buses" would be a relation tagged type=restriction access=no psv=yes. We have no need to use the specific sign, because the potential applications don't call for it. An end-user will not want to see their satnav telling them which directions they can't go - they're more interested in which way they need to go. Similarly, the software shouldn't need it to establish the specific direction, since if it can't work it out from the from/via/to combination you haven't put enough information in. Chriscf 14:19, 10 December 2008 (UTC)

Ok, it sounded like you want to forbid access-keys in the relation. restriction=permissive is needed because access=yes for a permissive restriction would not imply access=no for the other ways of that junction! To keep the access=*-style we could use restrictive=yes/no instead of restriction=permissive/restrictive. I used the restriction-key because it defines the basic type of the restriction. --Phobie 20:23, 10 December 2008 (UTC)

I have seen tools which show road-signs on a display as a guide in bad sight conditions. Those signs should be exactly as seen by the driver and not generated from the angles between ways. For me it is perfectly ok to tag the exact position of every road-sign or at least set the roadsign=*-key of a junction-relation --Phobie 20:23, 10 December 2008 (UTC)

I just wanted to make the same suggestion. I don't like the only_* rules much. This is especially the case when trying to define, that a 150 degrees turn is forbidden, a 120 degrees turn is allowed and a 90 degrees turn is forbidden again... And tagging a restriction like "from 1 to 2 only_straight_on" (taking the way numbers in the sample above) is driving me crazy. And tagging "from 1 to 3 only_straight_on" says nothing about the ways 2 and 4... I would also say, that a permissive rule is optional since all is allowed until it's forbidden. The via-tag is also optional except for u-turns where it is necessary. Like Chriscf I'm also not seeing any necessity for the direction=* tag. The renderer should be able to find enough information. Furthermore I'd like to suggest to drop the restriction=* tag and instead set hgv=forbidding, foot=permissive (optional), motorcar=forbidding, ... -- Andre68 23:54, 25 November 2008 (UTC)

Hmm... I'd like to revert the last sentence since the restriction-tag is probably useful for the except-situation (e.g. restriction=forbidding and foot=permissive). -- Andre68 00:25, 26 November 2008 (UTC)

1. I aggree, 2-3. I strong agree, 4. I agree, 5. I don't agree. I think, there is the danger, that an user, than does not notice the restriction or does not know the syntax will combine the two ways and we get an unvalid restriction and it will be difficult to reconstruct the original situation. --Langläufer 21:35, 16 January 2009 (UTC)

1. I don't agree. It will be easier to make mistakes to calculate time when restriction not apply. And how you offer to show that restriction apply on weekdays from 7am to 10pm? 2. Yes, for this one I agree. 5. Yes, via is rarely necessary. I propose to allow restriction to have one from and many to and otherwise many from and one to. -- Aleksejs 20:44, 28 June 2009 (UTC)

@Aleksejs, 1.: opening_hours can express everything the current solution can express, and some things the current solution cannot express. "weekdays from 7am to 10pm" can be expressed as "Mo-Fr 0:00-7:00,22:00-24:00; Sa-Su 00:00-24:00". I've corrected my answer, I somehow got it backwards. And yes, we should think about whether it would maybe make sense to invert the meaning. --Tordanik 22:10, 28 June 2009 (UTC)

Ok. It looks more flexible and easier to use. But idea about This tag should shows the times when the turning-restriction does NOT apply is inconvenient. I think opening_hours=* (or may little better name for tag) must show restriction apply, because it will contains exact information what signs shows. Otherwise, you need to inverse time, and it will easier to make mistake and harder to check it, need additional brain-time. ;) -- Aleksejs 15:23, 16 July 2009 (UTC)

The opening_hours=* syntax is good, the name is not. For my proposal it would be good to use time:active=* and time:inactive=*.In most cases it would be better to use time:active=* and change the restriction=* to fit the active time. --Phobie 03:19, 18 July 2009 (UTC)

Legal but worth avoiding

There are some intersections where a u-turn might be allowed but recommending that would make the router seem stupid - especially a case where a left turn is forbidden (D below) and is avoided by going around the block before that intersection and not doing a turn right + u-turn + straight over: (tram tracks in-between A & B)

Recommended: Start-C-A-B-D-Destination (even by street signs at Start)
Routed: Start-E-A-B-D-Destination

             Destination
            ||
      ------++--
Start -+----ED--
       |    ||
       C----AB
            ||

Actually, making a u-turn at the next intersection ("below" the AB in the diagram above) would make more sense since there's traffic signals and a dedicated turn-left signal. Any thoughts of a recommendation on how to deal with such cases? Alv 07:43, 17 December 2008 (UTC)

It is because the router is stupid. It does not assign a high penalty in U-turning. --Miklcct (talk) 15:25, 7 February 2015 (UTC)

OSM Restriction Analyser

I've made a prototype of a restriction anlayser. The script checks the syntax, members, oneways (against) and directions (left, right, straight, u-turn) of the restriction relations. It use the trafic signs for Germany. Restrictions with more than one via-nodes will be interpreted as error. Restrictions with no via-node will be ignored. --Langläufer 10:16, 20 January 2009 (UTC)

Already very smart and useful tool. I like it. One observation: An error is also shown for restrictions inhibiting driving against oneways, even if the latter is tagged with "cycleway=opposite*". In this case however the restriction provides additional benefit as it inhibits also bicycles to enter from a particular way. Can the tool be adapted to check only for "oneway=yes" without "cycleway=opposite*"?--Rs 21:55, 20 January 2009 (UTC)

In a later version i want to differentiate between errors and warnings. I think this is a warning, because it is in most cases not necessary to define such a restriction. In this case I guess the restriction is wrong. If it is allowed for cyclist to turn left, I can not thought that it is not allowed to go straight into the one-way, where it is allowed to go opposite for cyclists. --Langläufer 09:49, 21 January 2009 (UTC)

OK, a warning sounds more reasonable for differentiating from real errors. And of course each individual case needs to be checked.--Rs 21:23, 3 February 2009 (UTC)

Wishlist

It'd be nice if it displayed some kind of mark (could be something as simple as a small dot or a lighter blue background) for restrictions with hour_on/off=* or times=*/hours=*. Alv 19:26, 12 February 2009 (UTC)

ways and nodes for "via"

The specification as it stands allows for multiple "via" members that may be ways or nodes. I have removed the note about using nodes rather than ways to make routers work better, since if a router doesn't understand a way as a "via" member or multiple "via" members, etc. then it's the router that's broken, not the relation. Don't tag for the applications. Chriscf 16:11, 26 February 2009 (UTC)

If, however, some problem isn't simply a bug in a single application, but that way of mapping is harder to evaluate in general, you should indeed use the method that is easier to handle. Situations where you need via ways are rare and limited to a few cases that might very well be irrelevant for some applications, which could then simply ignore via-ways without producing incorrect results. Thus the advice to avoid via-ways where they are unnecessary is justified -- why make data harder to evaluate unnecessarily just because the specification allows for it? Not telling mappers which method works simply leads to frustration when they find out their restrictions don't work in their favourite app.

Also, the "Don't tag for X" statement is not appropriate in this context: Mappers shouldn't enter data that does not match reality to deal with application shortcomings. When there is more than one valid way to map reality, however, it's entirely sensible shortcomings. When there is more than one valid way to map reality, however, it's entirely sensible to prefer the one with better application support. --Tordanik 16:44, 26 February 2009 (UTC)

"Don't tag for X" is perfectly appropriate in this context, unless you have some solid evidence to support the "harder to evaluate" claim. Chriscf 16:52, 26 February 2009 (UTC)

Well, effort(nodes) + effort(ways) > effort(nodes), no matter how small effort(ways) is -- if, of course, effort(ways) > 0, but I guess you can't doubt that. ;-)

More seriously: When dealing with node-vias, you only need to look at a single node, and ways and restrictions containing it. You could integrate those restrictions by "splitting" the node -- that is, having each incoming way end with a different node with the same position -- and adding connections for all legal turns (this method also makes it possible to nicely assign different costs, and possibly routing instructions, for the different possible turns, btw). I dare say that's a rather simple algorithm. (Note: I haven't addressed the problem of turning to circumvent restrictions, but that could be solved by splitting nodes (or entire ways) once more.)

With via-ways, on the other hand, you can't just look at a single node or a set of nodes that is either completely affected by a restriction or isn't, because one via way might contain nodes A and B, another one nodes B and C, etc. Extending the split&reconnect-concept to this situation is possible, but the check becomes far more difficult than nodes' "all 'only's with x as from must contain y as to, no 'no's with x as from must contain y as to", at least I haven't seen a similarly easy way of handling it. Unlike the node case, you also have to do the reconnecting in a way that preserves the original geometry if you want to draw lines or something to mark your route.

Of course, I'd prefer to get feedback from authors of routing software that is actually in use, but I find it plausible that handling via ways is significantly harder. --Tordanik 17:34, 26 February 2009 (UTC)

Your first statement is a tautology, and therefore irrelevant. It is more effort to parse a way than a node, since it involves parsing all the nodes in between, but you have to do this for all ways, not just those ways that are specified in the relation. Of course, it's true that you can simply add an additional node to the prohibited way to unambiguously describe it, but as things stand, if the specification says that ways are allowed, then ways are allowed. They are either allowed or disallowed - "allowed but discouraged" is unnecessarily awkward. It's effectively a licence to cut corners. We want developers to do The Right Thing, and we achieve this by not letting them cherry-pick only those parts of the specification they can be bothered to implement. Chriscf 18:08, 26 February 2009 (UTC)

To sum up: All you want is to persuade developers to adhere to The Specification by increasing the amount of via ways beyond what would be necessary. And of course you don't want to tell mappers that one method is easier to implement, because their informed decision wouldn't help your plans. --Tordanik 19:54, 26 February 2009 (UTC)

keep it as simple as posible. --Langläufer 20:32, 26 February 2009 (UTC)

The current note is the exact opposite of "as simple as possible". "As simple as possible" means either ways are in the spec or they are not. Make up your mind. Chriscf 21:07, 26 February 2009 (UTC)

If you read Langläufer's statement as "for any given situation, use the least complex mapping method describing it correctly" it perfectly makes sense. The note doesn't add any complexity to the specification, because it does not alter the specification. It's simply there to help mappers identify the least complex mapping method. --Tordanik 22:38, 26 February 2009 (UTC)

what is the problem? is it the word application? It is only a hint to use the more simple model to support more applications - not only one specific, but most routing algorithms routes from node to node with restrictions at the node. please do not change the article if you could not find some more users with your "problem". --Langläufer 05:34, 27 February 2009 (UTC)

have anybody some real-world examples, where you realy need a via-way exept for u-turns? Think it's less than 0,1%. Not a big problem, when routing algorithms do not support it. But if mapper use it in cases it is not nessesary the data will be worthless for more than 50% of routing tools. Think on importing the data on a standard PNA. You will not have the chance to change the algorithm. --Langläufer 05:49, 27 February 2009 (UTC)

Here:

79516, described in http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/000894.html. Robx 08:07, 27 February 2009 (UTC)

And here:

71051 --Plasmon 16:26, 28 February 2009 (UTC)

The fact that we cannot change the rules that other routing engines use is very much not our problem. No matter how you word it, the caveat you want on this page effectively says "Some applications might not comply with our spec, so make your relations such that broken applications can read it". There are two and only two options: either ways are allowed, or ways are not allowed. If ways are allowed, then we have no business telling people not to tag ways as "via". If using ways as "via" really makes things that much harder, then they should not be allowed, and I'd be happy to support that change. They are either all in or all out, no ifs or buts. Chriscf 15:38, 3 March 2009 (UTC)

Could the following be acceptable to all: 'You should not avoid using ways in the role "via" where necessary, even though some current applications do not yet support them.' ?Alv 21:13, 3 March 2009 (UTC)

No, "not avoid somethning that is necessary" is not a useful information. --Langläufer 21:38, 3 March 2009 (UTC)

Between the lines it reads "some might remove them anyway" and "it's not a 'should' either way where they're not necessary". But I'm rather mapping them than attempting any more wordplay. Alv 21:49, 3 March 2009 (UTC)

For the umpteenth time, "applications do not support them" is a problem with the application, and avoiding them for that reason is tagging to the application. If they're a problem, remove them from the spec. Chriscf 15:36, 4 March 2009 (UTC)

only_u_turn

You may smile at this one, but apart from the fact that no_u_turn ist the only tag which has no "only" counterpart, I've actually discovered a road with this sign in Vienna, Austria. It's a separate lane for the sole purpose of allowing cars to turn in sync with the traffic lights without disrupting other traffic. ----wolfbert 17:48, 28 February 2009 (CET)

'except' must have complementary pair, 'only' (for vehicle types)

It is quite common to have hgv routed forcefully only to a direction (not to enter a town/city) but other types of traffic can be allowed to go either way.

      B
      |
A-----X-----C

For instance hgv must drive only_left (from=A, via=X, to=B).

So the simple way to write it is in the relation:

type=restriction restriction=only_left only=hgv

from=A to=B via=X

We need a reverse of except since the restriction applies only to hgv and we don't want to restrict possible future types of vehicles to be added. ---- EddyP 13:02, 4 March 2009

IMO, access=* style tags are better, and don't create contradictions (e.g. except=hgv only=hgv). This means the restriction could be from=A via=X to=C access=yes hgv=no. Chriscf 15:57, 4 March 2009 (UTC)

access=* style tags are not usable since you might have access allowed from one direction for hgv, while not allowed from the other EddyP 10:52, 5 March 2009 (UTC)

Only the forbidden direction would be entered as a relation. Alv 11:34, 5 March 2009 (UTC)

That is not scalable for multiple reasons. In an intersection with n ways you need n-1 relations to express a mandatory direction. Imagine an intersection with two different mandatory paths for two different types of vehicles, in that situation you'd have 2n-2 relations to express them correctly, when what happens is that you simply need just two. Also, the problem of the expansion of the vehicle list is not handled either. EddyP 9 March 2009 20:02 (UTC)

I confirm that we need an "only" with the actual specification. But I would like the #Proposed changes more. --Langläufer 12:03, 5 March 2009 (UTC)

I used exclusive=hgv on

139064 (only hgv's must turn right). --Michi 23:36, 21 June 2009 (UTC)

how would you tag this with access?

restriction	description	with except/only
only_*_turn	A is allowed to follow all directions	except A
no__turn	A is allowed to follow all directions	except A
only_*_turn	only A is not allowed to follow other directions	only A
no__turn	only A is not allowed to follow this direction	only A

--Langläufer 12:03, 5 March 2009 (UTC)

Allowed/not allowed confusion

It's generally agreed that the value of restriction=* can be ignored, since it would appear that its primary purpose is to determine the sign that is placed, due to the ambiguity that may arise from a restriction=no_right_turn in a relation that actually depicts an overall bearing that is to the left. It should be possible to determine the meaning of a restriction relation without recourse to this tag, since the nodes and ways on the ground will already define the direction of the restriction. To do this, we need to determine whether the relation will only contain prohibited moves or mandatory moves. I propose that parsing the restriction=* value for starting with "only" or "no" is not a workable solution. Chriscf 15:51, 4 March 2009 (UTC)

I would like the #Proposed changes more. --Langläufer 12:04, 5 March 2009 (UTC)

Complex routing restrictions

How to tag complicated turn restrictions? Like intersections where several roads pass, where allowed routing and restrictions call for something more than simple only_turn or no_turn. Can for example several only_turn share the same from and via members? --Skippern 01:15, 7 June 2009 (UTC)

Why not add as many relations as the intersection requires? There is no limit on how many times any object can be referenced in relations. That's for the data. The evaluation in tools might be something different. But as long as your relations reflect reality - that's their problem. --Gary68 10:19, 8 June 2009 (UTC)

I can't imagine a real-life situation that is properly represented by more than one "only_" restriction relations on the same from and via members, unless they have different "except" tags. "only_" is inherently exclusive. Multiple "no_"s are, of course, possible. --Tordanik 22:05, 8 June 2009 (UTC)

I had to be inventive in an intersection with 4 options, two allowed (as only_*) and two disallowed (as no_*). I solved it by making 4 relations, all with the same from way and via node, but different to nodes. The suggested sign at the intersection says now only_left, no_left, no_straight, only_right, the from way is an one lane oneway, the no_left and the only_right is the same road (in oposite directions), and due to trafic regulations, you cannot cross. The from way is not governed by traffic signals, while the other are. Sounds complicated? --Skippern 12:35, 22 August 2009 (UTC)

I'd like to see a link to this place once the servers are up again.

Regardless, I still don't think it makes sense to have two or more only_* restrictions with the same from and via members unless they have additional tags (for restricting them to lanes somehow, or except tags). "I will not let you go anywhere except to A" and "I will not let you go anywhere except to B" combined necessarily prevent you from going anywhere at all. So unless you are trying to find a creative way to describe a wall across the street, this cannot model any situation correctly. --Tordanik 15:23, 22 August 2009 (UTC)

If there are different restrictions for different lanes, then the lanes need to be split up into two ways, which will be OK for some meters since there is probably a line you are not allowed to cross. This also solves the problem that you are informed by your navi software that you need to choose a certain lane :-) --Lulu-Ann 00:28, 23 August 2009 (UTC)

No, it should be possible to define lanes in the relation, without the need of splitting the road. We have the lanes=* to identify how many lanes there is, and this together with this identification should be enough to tell the routing software what goes on. See a later topic on the talk page for Lanes Truning Restrictions. --Skippern 00:57, 23 August 2009 (UTC)

@Tordanik: If you enter a junction on a single lane, but are able to leave the junction on two lanes (in the same direction) and if the two leaving lanes are mapped individually, there is a situation where you might either need multiple only_s or the possibility to add multiple ways in the to-role to the relation.

I'd opt for the later, as it simplifies the multiple no case as well. If we may use 1+ ways in the to role, describing a turn restriction for a single, entering lane is easy. Say, it allows you to turn right or go straight, but denys u_turn and turning into the two lanes leaving to the left, then a relation with

from .. input lane
via .. node in the middle (or ways, as you like)
to .. the leaving lane in the opposite direction
to .. the first lane of the two lanes leaving left
to .. the second lane of the two lanes leaving left

will do..

Progress ?

So is there any further progress here? The proposal is old, it sneaked into an established state by now. As far as I understand there is no voting/approval process for restrictions, so these things go merely unnoticed. By now the restrictions are widely used and understood by renderers, format converters (Garmin) and routing tools. Nevertheless turning restrictions are still one of the things most annoying when missing (wrong in-car routing) and a pain in the a** if you have to edit them. So they are missing in a lot of places, as they seem to be to complicated (annoying?) to most mappers. The proposed changes could have brought a bit of ease, but as there is no official approval process, they were never voted on or anything (and they are not noticed now cause they only reside somewhere in the middle of the english discussion page).

As I am no veteran here, I would like to make a simple question: Do you (all the osm activists and full time mappers) think it is still possible to change anything about this relation? Or are these to widely used by now? Do you think a new 'proposal' would be more of use then new discussion about changing the old one? Or do you even think all is fine with the turn restrictions and all problems should be solved in the editing tools? I was writing a long summary of problems and possible solution here, but momentarily I think it might be futile and a waste of time. Do you think otherwise?

Chaos99 07:46, 3 July 2009 (UTC)

Do a wikisearch on "Relations/Proposed/". I think relation proposals should be moved to the "Proposed_features" namespace! It is always possible to change everything ;) ! In the case of my proposal it could be done by a bot. But here in the wiki we have a big movement against everything which could change the current state as long as it is not the mysterious "perfect solution". We should create a proposal-page and set a link from here to it. --Phobie 21:04, 18 July 2009 (UTC)

I think there is no need to change immediately after approval of your proposal. Need just to define, that restriction=only_* must be proceeded as restriction=permissive and restriction=no_* as restriction=restrictive. I think you need to add your proposal to Proposed features. -- Aleksejs 10:25, 22 July 2009 (UTC)

Lanes Turn Restriction

Reffering to discussion on mailing list regarding lanes turn restriction, can this be implemented in this? The only difference is that we need to identify lanes in the to and from roles. I would suggest something like from.1 and to.2 if there are dedicated lanes in the restriction. Lanes can be identified by lanes=*, and I suggest numbering from left to right. That would for example allow a only_left_turn with from.1, no_right_turn (left or forward) with from.2, only_straight_on with from.3 and only_right_turn with from.4. This corresponds with intersections I know.

So my proposed change is allowing from.{number} and to.{number} as members of turn restrictions. --Skippern 00:30, 21 August 2009 (UTC)

I oppose this - it hides information, is hard to understand and hard to map. The simple solution is just mapping the lanes individually and using established turn restrictions (one for each lane entering the junction). --Cmuelle8 02:01, 5 March 2012 (UTC)

Unclear description of only_*

The current wording of the description of only_* restrictions is

"...if it is "only_", then you know that the only routing originating from the "from" member leads to the "to" member. The "from" and "to" members must start/end at the "via" node (see 1)."

This prohibits routing from the "from" way to all connected ways except to the "to" way. However, the "via" node is important here and the "only_*" restriction should only affect ways connected to the "via" node. Otherwise the following would prevent routing from way be to way de or way ef. Note that way be NOT is oneway.

a---------b-----------------c      type=restriction
          | ,->                    restriction=only_right_turn
          | |                      Members: * be: from
          |                                 * bc: to
  d-------e-------------f                   * b:  via

My suggestion is to change the description to

"...if it is "only_", then you know that the only routing originating from the "from" member via the "via" member leads to the "to" member. The "from" and "to" members must start/end at the "via" node (see 1)."

This might be the intended usage, but I think it is important to point it out. --Erik Lundin 23:51, 20 November 2009 (UTC)

I don't understand why it is a special problem of only_*_restriction? All restrictions are only working at the via node! --Langläufer 07:58, 21 November 2009 (UTC)

'no_left_turn' from a to b via P

Actually, the description for no_* isn't literally correct, either. Routing is possible from the from to the to member - it's just not allowed to use exactly via as a connection between them. (For example, look at the image on the right: It 'is' allowed to turn right at the junction coming from A, drive around some blocks of houses, come back to the junction from the map's upper border, and turn right to B.)

Regardless, I agree with Erik's improved description for only_*. Providing a clear definition is better than just relying on correct interpretation of the via role. --Tordanik 17:49, 21 November 2009 (UTC)

What name to use for a more complicated restriction?

At some places on a roadway with two carriageways, both in the same direction, one cannot switch from one to the other at an intersection (example). What name should be used in restriction=* for these? --NE2 19:57, 23 January 2010 (UTC)

you cannot use the established turn_restrictions for this. just map the lanes individually (one way per lane) and use one turn restriction relation on each way entering the junction..

no_change_lane for example? --Skippern 20:24, 23 January 2010 (UTC)

No, that would imply you can't change between any two lanes. A roadway specifically for the purpose of changing between roadways is sometimes called a slip road, but no_slipping doesn't sound right. no_z_turn? :) --NE2 20:46, 23 January 2010 (UTC)

You'd likely add a only_straight_on to both of those ways that don't allow drivers to use the gap (and the connecting way used by turning traffic) for moving sideways. Alv 13:47, 24 January 2010 (UTC)

Sorry, didn't take time to see your example, and misunderstood your problem. only_stright_on should cover this, besides, no_left_turn and no_right_turn can also be used. If you draw your intersection on a piece of paper and draw arrows where you are allowed to drive, than you can count yourself to how best tag it with the current only_' and no_ tags. I include no_left_turn and no_right_turn as as it might be allowed to change from the inner to the outer way but not the other way. --Skippern 19:41, 24 January 2010 (UTC)

The question is more general, however; I believe there are cases where you can turn right from the inner roadway but not right and immediate left (maybe not, though). Another complicated case is where a freeway onramp merges on the right side, and signs prohibit cutting across to a left-hand exit. --NE2 20:07, 24 January 2010 (UTC)

The "no cutting across" can be described with a only_straight_on with the section (way) where the lanes are parallel but the cutting across is forbidden, in the role via. Current software that the wiki knows of, do not yet know how to handle such cases, but when it's necessary to use a way via, then it has to be used. At least the Garmin converters could be made to alter the produced routing grid to account for that, by connecting the onramp to the main road only after the left side exit way has started. They have already experimented with various ways to make the routing topology different from the displayed map, for example for bicycle routing (oneways and bollards and such). And for the right then left, if the left turn is forbidden also for vehicles that didn't do a right turn just before, it's simple; when not, I don't know what to suggest. Alv 07:56, 25 January 2010 (UTC)

Is there a way to tag a 'recommended' route?

OK, I know we don't normally include recommendations for which road to use, whether personal or based on signage, other than the trunk/primary/secondary/tertiary classification. But there's a very special case that can be problematic for routing. A motorway_link splits in two before merging with a one-way primary road. The right fork simply merges into the right side of the primary, but the left fork bridges over the primary and merges into its left side. Soon beyond these merges is an intersection with a secondary road. There's enough room to legally cut across from one side of the primary to the other, but it's better for traffic flow to use the right fork when turning right and the left fork when turning left. Signs make this clear, saying primary east/secondary south for the right fork and primary east/secondary north for the left fork. But routing from motorway_link to secondary will probably use the shortest route, no matter which way you are turning. Is there any way to tag it so it prefers to use the correct fork, but can use the other one if necessary? --NE2 22:46, 18 February 2010 (UTC)

If it is possible to tag that section of the primary with some sort of no_change_lane and make turning restrictions lane dependent, than the problem is solved. I have long wanted to see a way of making turn restrictions lane dependent, as I have seen many strange cases of these turn restrictions. One interesting I have seen (cannot recall location) was 3 lanes, left lane only_straight_on, middle lane with no_right_turn, and right lane was only_left_turn. Yes it was marked with signs and regulated with lights. --Skippern 10:14, 19 February 2010 (UTC)

(Your case sounds like a hook turn.) Except that this isn't a restriction. You can take the 'wrong' ramp; it's just a lot easier to take the correct ramp. If someone takes the wrong ramp, we want routing software to recognize that and tell them to (carefully) cut across the road to the correct side. --NE2 13:32, 19 February 2010 (UTC)

A real clever router would add a time penalty for crossing several lanes in a short section of a road. Additionally, for the example case given above where the preferable lanes are signposted, a Relations/Proposed/Destination_Signs could be used (prior the forking point) to slightly favor the signposted fork for each direction. But as long as no router takes any such tags into consideration, one can use about anything that is comprehensible so it can be converted to whatever scheme someone might implement. Alv 13:45, 19 February 2010 (UTC)

Traffic signals

Could the restriction relation be used for multilane higways where only some of the lanes have traffic signals? For example a road with two lanes forward has one lane going straight and one lane for turning left which is controlled by traffic signals. I'd like to tag the junction with something like "restriction=traffic_signals_left_turn". --Mikalaari 10:16, 24 April 2010 (UTC)

I think the proposed lanes relation was aiming to tag such insances --Skippern 14:24, 24 April 2010 (UTC)

Usually in this case the road is dual carriageway, so you'll only put the light on one side. Or there's a raised barrier of some sort keeping traffic turning left onto the highway from entering the right lanes, so you might split the way with a separate one-way roadway to the right of said barrier, and only put the light to the left.

This is actually similar to cases where a right turn need not pay attention to the light - usually but not always there's an island separating the movement from the light. And there's Pennsylvania, where you'll see "stop except right turn": http://www.pacode.com/secure/data/067/chapter212/s212.107.html --NE2 22:41, 24 April 2010 (UTC)

No Turn On Red

I think we need a new relation for "No Turn On Red". The problem is sometimes the "No Turn On Red" sign doesn't always come stating a specific direction. How do you think we should deal with it? I was thinking, for any that don't have a specific turn mentioned, we could just add all the intersecting ways in the "to" area. As for the tag, it would be restriction=no_turn_on_red. I even know some of these are time restricted (there's one in Pittsburgh, PA, USA). So, what would I do to get something like this approved if people think it's a good idea? --Rickmastfan67 03:42, 2 September 2010 (BST)

It's not really a restriction any more than "no straight on red". It just means that you have to wait to make a movement. --NE2 08:51, 4 September 2010 (BST)

But it could be interesting to map exceptions from restrictions such as left_turn_on_red --Skippern 13:03, 4 September 2010 (BST)

Left_turn_on_red can already be mapped by mapping the sign number. Lulu-Ann

I really like this idea. One observation is that, generally, the traffic which the sign is facing, is the one to which it would seem to apply. The second is that, on most of the local streets where I have been, these signs are usually located by a noticeable right-of-way on the right, not by barely noticeable side roads and the like. The third is that this likely does not affect non-motorized-vehicle roads, since the road signs in general seem to be tailored for cars (for example, roads marked "dead-end", with a road-named pedestrian staircase at the end). This being said, maybe each intersection could have its own relation, since that is a simple way for any system to understand the restriction. If most of intersections are no-turns-on-reds in a locality, then maybe a default could be used for them collectively, instead of tagging each and every intersection. If necessary, tooling can help to tag each no-turn-on-red relation (for something similar, see Michigan Left). Abbafei (talk) 05:26, 31 March 2014 (UTC)

Somehow I think this should be handled as part of improving traffic sign mapping in general. Right now we can't even map the traffic signs at more complex junctions very well. Starting with the exceptions from the traffic signs seems counterintuitive. --Tordanik 15:41, 31 March 2014 (UTC)

I'm not a huge fan of this tag; personally, I would not use it and do not see much benefit, however there do appear to be about 180 such relations now in use. ~80 of these are in my own city, Toronto, and they are causing me big problems because OSRM currently treats them as right turn restrictions. Meaning no turns allowed. Can I get some thoughts on whether they should be removed or altered for causing problems, or whether they should be retained and the router's settings changed? The tag I'm referring to specifically is "restriction"="no_right_turn_on_red" Nate Wessel (talk) 18:01, 26 June 2016 (UTC)

OSRM acts as expected and follows the definition of restriction relations, specifically: If the first word is "no_", then no routing is possible from the "from" to the "to" member. I think it would be best for your community to agree on a new relation type rather than using "restriction" relations. 80 relations are still easily correctable as long as there is community consensus. --Tordanik 17:21, 27 June 2016 (UTC)

I can say this: I don't like the idea of 'No turn on red' being used in a restriction, relation or otherwise and I'm on the fence about whether it should be mapped at all. It provides no useful data for point to point navigation. At BEST it can display a sign on the screen that the driver should easily be able to see out their windscreen, and may influence the ETA from a source to destination point by a matter of a few seconds. Here's what no turn on red is NOT: it is not 'You can't make a left turn at all between time X and Y', and that's what time restrictions are for. 'No turn on red' sounds like the kind of thing you'd want to map with a 'sign' point, in the same way you might 'Deer crossing ahead', etc.. It doesn't affect routing or probably shouldn't even affect what's displayed on a map, but might be useful to put on a screen for a driver, if it isn't considered completely redundant. (I'd be in the camp of it's basically redundant.) Skybunny (talk) 20:41, 29 June 2016 (UTC)

Incidentally, I have been working on a possible non-relation solution for this situation. Please see Proposed features/turn signals and comment there to improve the proposal. --Biff (talk) 07:53, 4 July 2016 (UTC)

For anyone still reading this: Toronto seems to have settled on type=restriction:on_red + restriction:on_red=no_right_turn as seen for example in https://www.openstreetmap.org/relation/3750117/history. Taginfo. I'm on the fence about this myself but that's what's mapped now. --Jarek Piórkowski (talk) 17:24, 12 February 2019 (UTC)

How to map No U Turn on Dual carriageways

N Wickham Rd (CR 509) (Secondary, NS) intersects Post Rd (Tertiary EW). How am I supposed to make it so N Wickham Rd cannot make U turns at this intersection? --Panther37 16:43, 23 March 2011 (UTC)

Use a piece of Post Road as a via way (rather than the via node you'd use on a single carriageway). --NE2 05:09, 24 March 2011 (UTC)

no straight on

"moving straight on is prohibited"

Example of a road with sign "moving straight on is prohibited" without one way

c is a oneway restriction, not a turn restriction - it is a mistake. This road sign can be used at the roads with one way, but not every road with such road sign has one way. Dinamik 15:20, 9 July 2011 (BST)

road sign 3.1.svg On Wikimedia Commons it's categorized in Category:Do not enter signs. Is this incorrect? I can understand File:Downpatrick signs (06), August 2009.JPG meaning no straight on, but the 'do not enter' symbol by itself? Where would it be posted? If it's before the intersection, wouldn't it mean that you can't enter the intersection, period? If it's after the intersection, it would prohibit entry from any direction. Can you give an example of a place that it's used to mean no straight on? --NE2 19:53, 9 July 2011 (BST)

"road sign 3.1.svg On Wikimedia Commons it's categorized in Category:Do not enter signs. Is this incorrect?" - it is correct, because this sign means "do not enter from this direction". Sometimes road has one way, sometimes, road is allowed only to public transport, sometimes, road is allowed for everyone, but moving near some point in some direction is prohibited. "Where would it be posted?" - it can be posted elsewhere, because it means "do not move near this sign in such direction". "If it's after the intersection, it would prohibit entry from any direction" - this sign can be posted not only near intersection (when it prohibits entry from entry direction), but, for example, 50 meters after intersection or in the center of part of road. "Can you give an example of a place that it's used to mean no straight on?" - for example, authorities don't want cars going through "Улица Мира" (central horizontal road), they want cars going through "Советская улица" (horizontal road at the bottom), they made 2 signs "moving straight on is prohibited" in 2 points at "Улица Мира". So we have road, that doesn't have one way and we have points, near which we can't go in some directions. Another example: there is some building, which owners wants cars to have access to go to this building from 2 sides of part of road, but don't want cars to go near this building - they posted 2 road signs near the building. So road has no one way, but cars can't go near the building, they have to make U-turn before road signs. Dinamik 01:39, 10 July 2011 (BST)

In your example, it looks like the short piece of Улица Мира where the sign is posted is one-way. Split the way at the sign and at the first place a U-turn is allowed beyond the sign. What city is this screenshot of? --NE2 07:11, 10 July 2011 (BST)

"it looks like the short piece of Улица Мира where the sign is posted is one-way" - no: one way roads in Russia are marked with signs 5.5 and 5.6, there are no such road signs at "Улица Мира". There is big difference between going the wrong direction at one way road and going near 3.1: at first case police will take away your driver license, at second - you will pay a fine. Public transport can go near 3.1 road sign, but can't go at one way road at wrong direction. "What city is this screenshot of?" - "Кадуй". Dinamik 12:17, 10 July 2011 (BST)

So (going with the east one of the two restrictions) you can go eastbound right up to the point at which the sign applies and make a U-turn, thus passing the sign? No, you can only U-turn before the sign, thus making a very short piece of oneway. --NE2 16:52, 10 July 2011 (BST)

If there is a short piece of oneway, moving in appropriate direction is prohibited for all vehicles (because all other vehicles drive opposite to you), if there is a sign "moving straight on is prohibited", public transport can use road in both directions, because road is not one way. If there is a short piece of one way, you can park you vehicle on the both sides of the road, if there is no one way, you can park you vehicle only on the right part of the road (except cases, when road's width is rather small). If you suggest to mark such road as having virtual piece with one way, I think, that it is not a good idea, because, for example, in Russia (I don't want to say about all states, because, in some states, perhaps, there is no difference) there is an essential difference between one way roads and roads, having only road sign 3.1. As I know, we should mark in OSM that, what we really see. If we have one way road, we should mark it as a one-way road, if we have a restriction "moving straight on is prohibited", we should mark it as a restriction "moving straight on is prohibited", don't you agree? Dinamik 18:25, 10 July 2011 (BST)

You can use oneway:bus=no if buses can go the other way. --NE2 19:22, 10 July 2011 (BST)

Do you think, that situation, when we, firstly, add non-existing in reality object, and, secondly, try to liquidate problems, which appears because of this non-existing object, is normal? What does prevent us from adding real object at once? Dinamik 20:50, 10 July 2011 (BST)

Whatever, if you want to mark it as a restriction, do so. But I still disagree with putting it in the list, because it doesn't mean no straight on any more than it means no right turn if you see it to the right. --NE2 22:37, 10 July 2011 (BST)

"moving straight on near this road sign is prohibited (this road sign also can be used at one way roads) (disputed - see Talk:Relation:restriction#no straight on)" - what is disputed? Do you want to say, that moving straight on near this road sign is allowed or this road sign is never used at one way roads? What will you do, if you see this road sign in front of you? Do you continue your moving straight on or do you make a U-turn? Dinamik 01:46, 10 July 2011 (BST)

This sign means entering disallowed. It is often used in conjunction with oneway-signs on the other end of the street. Here we should use oneway=*. In other cases (unreal oneways without oneway-signs) we should use the relation type=restriction with restriction=no_entry/no_exit. no_entry has several from-rules and one to-rule. no_exit has one from-rule and several to-rules. Until now this has been handled by splitting a very small part out of the way and tagging it with oneway=* which is IMHO not the best solution to this problem. We could also merge no_entry and no_exit into no_access and allow several from or to-rules. --phobie m d 10:12, 25 July 2011 (BST)

I think, it is a good idea to add such type of restriction.

	Road Sign	Restriction	Remark
9		restriction=no_entry	It is used for not one-way roads, where entering across some point is permitted. Relation can have several from members and one to members.
10		restriction=no_exit	It is used for not one-way roads, where exiting across some point is permitted. Relation can have one from members and several to members.

Is it normal? Dinamik 09:04, 28 September 2011 (BST)

It can all be modeled by other means. There is no need to introduce another tag. All routing information can be expressed with the given notation. The only thing is that you have a special road sign which is used in your country for those cases, so it may be a problem for the renderer to visualize the exact road sign that is used in this case. However, other countries have similar problems with rendering their country specific road signs (Brazil, Sweden, etc.), but as they aren't rendered anyway (so far), this is less of a problem than it might seem to be. There may be a solution to the rendering problem in the future. For now we should stay with the given means. I'm going to remove the tags no_entry and no_exit. --Gauß 18:15, 8 October 2012 (BST)

This is what it effectively means, and how these were drawn up to this discussion, and how most mappers still continue to draw. Because your vehicle is never without length, there is a short length of the road where you can't legally turn around, because you would immediately drive past the "no entry"/"forbidden direction" sign, either during the manouver to turn around, or just after it. Also, when your car or other vehicle is parked on that stretch of road, you effectively can only start driving away from the sign - for all practical purposes, the bit of road between those black dashes/nodes is oneway. The fact that some country has a blanket allowance for all public transport vehicles to drive past those signs, is merely worth a oneway:psv=no tag or similar. Alv (talk) 12:37, 7 October 2013 (UTC)

Removal of the key "only"

I added only in conjunction to the except key to the list of keys to be used within the relation and Tordanik reverted my addition with the comment "only" is used only 18 times and is a bad key name. It fails to indicate that you are supposed to use *vehicle types* as the value..

Yes, 18 times is not much. But is is the most used key for this. (It was not my idea and I tagged none of them until now.)
The name is not worse than except or your new if:mode (Proposed_features/Conditions_for_restriction_relations). None of them indicates that we are supposed to use *vehicle types* as the value.

--phobie m d 11:57, 26 July 2011 (BST)

If the most frequently used key for a problem has no more than 18 uses, then no solution of that problem is established enough to be added without a vote.
"if:mode" indicates that you should use it for the "mode of transport", which is a fancy way of saying "vehicle type" without excluding pedestrians and horses. "only" doesn't tell me anything - just by looking at the key name, there's no indication that you are not supposed to do something like "only=18:00-20:00".

--Tordanik 15:58, 26 July 2011 (BST)

There is no duty to vote. It is a tool to help finding a consensus. Just like discussing on the mailinglist, forum or talk pages.
"only" is the best we have currently, so why not use it until we find a consensus for a better key?
"if:mode" does not make me thing about "mode of transportation", but about values like "(in)active" or "allowing/forbidding".
If you don't like "only", why are you not trying to change "except"?

--phobie m d 21:43, 26 July 2011 (BST)

We don't need to vote if it's already clear that there is a broad consensus, but you have provided no indication so far that this is the case. To me, the low number of uses suggests that the community has not yet thought about the issue a lot, and the fact that two proposals for other tags exist does not support the assumption that there is a consensus either.

Changing existing solutions is, unfortunately, not easy to do due to OSM's fuzzy processes, which is why I'm reluctant to suggest deprecating "except". For the same reason, I don't like the idea of "temporarily" documenting a key - there would be no easy way to get rid of it later.

I can see, though, that "mode" doesn't make everyone think of vehicle types right away. So what about "if:vehicle = ..." - any arguments against that? --Tordanik 22:49, 26 July 2011 (BST)

"except" can only be deprecated if there is an alternative. AFAIK you named none.

Users are searching the wiki for solutions. And a temporary solution like this is better than no solution at all. If there is a consensus on a better value, it is easy to fix this later.

I had a look on all values of "except" on tagwatch and while there are not only transportations, all values are easily parseable!

"only" is used seldom because it is not documented and not needed very often. Most turning-restrictions, I know off, are only using exceptions...

"if:vehicle" does not fit to "foot". "excepted_transportations" and "only_transportations" would be clearer, but where to put destination and other access-values than?

--phobie m d 23:58, 28 July 2011 (BST)

comment: I think, that people speak in "different languages", because road signs' system is different in different states. For example, in Russia, in my opinion, exceptions are used rarely, but description of type of vehicles, for which restriction is operating, is used rather often. In Western Europe, perhaps, they usually use exception. So there is need in marking exceptions, and there is need in marking type of vehicles, for which restriction is operating. It is rather hard to mark road sign in OSM in Russia, because we have to mark in except all types of vehicles, except those, for which restriction in operating, because often restriction is operating only for one type of vehicles.

So, I don't agree with "..."only" is used seldom because it is ... not needed very often. Most turning-restrictions, I know off, are only using exceptions". In some countries most turning restrictions use only exceptions, in other countries - most turning restriction use only marking types of vehicles, for which restriction is operation.
We have tag except - we should have opposite tag (only, for or analogous). Dinamik 18:37, 29 July 2011 (BST)

Thanks for your perspective, Dinamik. This emphasizes that we clearly need both "except" and "only" (or one of the synonyms).

I think the arguments provided in this section of the talk page can be summarized into two decisions:

How should the keys be called? "only"? "if"? "for"? This seems to be just a matter of taste, and I suggest to have it decided by a poll.
Should we have one key for all types of values or different keys? In other words, do we want a concept like "except=hgv", "except=customer" and "except=18:00-20:00"? Or do we want "except:vehicle=hgv", "except:user=customer", and "except:time=18:00-20:00"? This decision clearly matters more than the name of the keys, and as you know, I favour the second variant - it makes values easier and less ambiguous to parse, and you can also combine two or more of these keys to express something like "except delivery from 08:00-11:00", which would otherwise be impossible.

What does everybody think - does this describe the decisions we have to make? How to you suggest to proceed? My proposal will obviously fail, and I might just cancel the vote, but I would still be happy if we could solve this tagging problem. --Tordanik 21:15, 29 July 2011 (BST)

restriction:<type of transport>=<restriction>

I suggest to add a form restriction:<type_of_transport>=<restriction> for marking restrictions, which refer only to one type of transport.

Example 1:

type=restriction
restriction:hgv=no_u_turn

Example 2:

type=restriction
restriction:caravan=only_straight_on

Example 3:

type=restriction
restriction:motorcar=only_right_turn

Example 4:

type=restriction
restriction:bus=no_right_turn

Example 5:

type=restriction
restriction:agricultural=no_straght_on

Example 6:

type=restriction
restriction:motorcycle=only_left_turn

Example 7:

type=restriction
restriction:bicycle=no_left_turn

Example 8:

type=restriction
restriction:hazmat=no_right_turn

If restriction refers to all type of vehicles, except one, it is easier to use except with marking one type of vehicles, but if restriction refers only to one type of vehicle, it is easier to mark only this type, to which restriction is refered. Dinamik 08:36, 28 September 2011 (BST)

That feature is broken, as it could lead to the following tagging:

type=restriction

restriction:hgv=no_right_turn

restriction:caravan=no_left_turn

I am going to replace this with a new tag: applies_to:<type of transport> --Gauß 18:33, 11 October 2012 (BST)

Practice showed, that tagging restriction:<type>=... is not the best idea. I think, I should delete text, which was added after my this proposal. Dinamik 22:58, 28 January 2013 (UTC)

type=restriction:<type of transport>

I suggest to add form type=restriction:<type of transport> for marking restrictions, which refer only to one type of transport.

Example 1:

type=restriction:hgv
restriction=no_u_turn

Example 2:

type=restriction:caravan
restriction=only_straight_on

Example 3:

type=restriction:motorcar
restriction=only_right_turn

Example 4:

type=restriction:bus
restriction=no_right_turn

Example 5:

type=restriction:agricultural
restriction=no_straight_on

Example 6:

type=restriction:motorcycle=
restriction=only_left_turn

Example 7:

type=restriction:bicycle
restriction=no_left_turn

Example 8:

type=restriction:hazmat
restriction=no_right_turn

If restriction refers to all type of vehicles, except one, it is easier to use except with marking one type of vehicles, but if restriction refers only to one type of vehicle, it is easier to mark only this type, to which restriction is refered. Dinamik 20:40, 2 November 2011 (UTC)

I am going to replace this with a new tag: applies_to:<type of transport> (see previous section). --Gauß 18:32, 11 October 2012 (BST)

Why? Dinamik 22:59, 28 January 2013 (UTC)

Incorporate 'give_way/yield' and 'stop' as possible restrictions

I think the current highway=yield/highway=give_way and highway=stop tags could benefit from being integrated with the current restrictions. There are multiple tagging proposals for these, and some of them can be hard to interpret (the "node besides way" and "node in intersection" in particular). Using the restriction relation would simplify their tagging and make its interpretation error-proof, especially for routing software.

Simply adding them to the possible restriction=* key values should be enough, i.e. restriction=stop and restriction=yield (or restriction=give_way). --Emepunto 15:35, 6 April 2012 (BST)

These should be tagged as something else, since they're not restrictions. --NE2 16:57, 6 April 2012 (BST)

Maybe it's stretching the definition a bit too far, but they can be considered restrictions: both of them prohibit you from "entering" another way without stopping before the intersection or at the place designated by road signals/marks (in the case of a yield, only if there are vehicles on the destination way). This relation fits them like a glove (stop on the via when going from the from way to the to way). After all, restriction=no_exit and restriction=no_entry, in general, aren't turn restrictions, so I think the same idea could apply to stops and yields.

no_exit and no_entry (if I'm interpreting the broken English correctly) are for restrictions on where you can go. Stop and yield are not restrictions; they simply add a bit of time to your trip. --NE2 01:41, 7 April 2012 (BST)

I agree that stop and yield are not "restrictions". Of course you could still use a relation with from/via/to members for them - it just shouldn't be called type=restriction. --Tordanik 13:06, 7 April 2012 (BST)

Perhaps, type=priority, type=advantage, type=privilege or type=superority? What english word is used in traffic rules for situations, when one car has a bigger privilege to move than another car? Dinamik 19:49, 8 April 2012 (BST)

Right-of-way (at least in US English). --NE2 22:53, 8 April 2012 (BST)

I found the proposal I was searching for: Right of way proposal—I knew I stumbled with something about a 'maneuver' relation. There is a suggestion on the proposal about merging that proposal with turn restrictions, renaming it to maneuver. Perhaps the best way to handle this is reviving (the draft is from 09/2010) and renaming the right of way relation to maneuver. --Emepunto 17:56, 9 April 2012 (BST)

I think, that we should use some relation for mapping a trajectory of main road, too. Sometimes, there are several lines in one intersection and a turn of main road. I think, that the easiest way to mark it is a relation (for example, type=priority) with intersection node with role via, trajectory of main road with role main and road with lower level of priority with role give_way or stop. Dinamik 19:57, 8 April 2012 (BST)

Dozec

What is Dozec? Dinamik 14:59, 28 May 2012 (BST)

It's very suspicious that other prominent search results for the term are 3D models of "Dozec Traffic Signs" at the Sketchup repo by a user with the same nick as the one responsible for that edit, and a "Dozec road signs" page on Wikimedia Commons that was deleted as a "Blatant hoax created by a sp of an indefinitely blocked (in august) user and crosswiki vandal (Jermboy)". It also links to this notice, calling this person "the wizard of road signs: creator of tables of signs into invented countries (as Hotsapore, Badziki, Dozec, Rafid etc...), crosswiki vandal into the same field with an impressive number of multiple IPs, uploader of down-scaled copies of existant files of signs".

Add to this that the user's wiki activities are limited to adding "Dozec" to some pages and images, and creating copy-paste "translations" (obviously machine-translated or even completely untranslated) of some other pages, and we can safely treat this as vandalism. --Tordanik 15:24, 28 May 2012 (BST)

Road signs: restriction=only_left_turn_or_right_turn, etc.

I suggest to tag restriction=only_left_turn_or_right_turn instead of restriction=no_straight_on. (Similar cases: only_straight_on_or_right_turn, only_straight_on_or_left_turn.) Reasons:
1. OSM doesn't decide how to render things. So, if someone decides to let it render as traffic signs, then the correct local traffic signs that are used in a certain place, can be rendered.
2. As was pointed out earlier, there are more possibilities than those signs currently in use, e.g. "half right", etc., which means only_left_turn_or_right_turn isn't exactly the same as no_straight_on.
--Gauß 16:42, 1 October 2012 (BST)

All current routing software, that have disclosed how they use the osm data, only look at the start of the value of restriction=* ("is it only_*, or no_*"), and only expect one member in the to role. Your suggested values would either break the logic of looking at the first part of the value (if the current no_straight_on way is still the to way), or, if all the allowed next ways are included as to members, would break all software that rely on the relation having only one to way departing from the via node. Which ways would the relations with restriction=only_straight_on_or_right_turn include as the to members?

If the sign is different from the implied restriction, better add a new tag to the relations; for example restriction=no_left_turn + traffic_sign=only_straight_on_or_right_turn. Alv 17:18, 1 October 2012 (BST)

I wonder why routing software needs the information restriction=... at all. It would be enough to define the roles only_to and not_to. Though u-turns may be special cases and have to be treated differently. If more than one member in the ..._to role were possible, then it would be even simpler: Only the not_to role would be necessary and u-turns would be covered by adding the way of the from role to the not_to role.

One problem with the current concept may be that it mixes routing and rendering information. Your suggestion to use a tag traffic_sign=... could be a better alternative. It would also help to render traffic signs in Brazil and Sweden appropriately.

--Gauß 21:45, 1 October 2012 (BST)

Routing software needs that information because the documented roles for this relation don't include "only_to" and "not_to". And although I agree that the restriction value is currently a strange mix of different concepts, it is still established and used by mappers, editing tools and end user applications. So if your changes would indeed be incompatible with these programs, then imo the place for such changes, even if they are improvements, is a proposal - not a documentation page. --Tordanik 22:49, 1 October 2012 (BST)

The beginning of the page starts with the words "This is a proposal [...]". Is that an error? --Gauß 23:42, 1 October 2012 (BST)

Yes, de facto it has become an error over time. This relation type is now used more than 100.000 times (3rd most used relation type) and has been featured everywhere from presets, to an editor plugin developed by commercial routing providers, to printed books, to navigation web services. That's why I consider it established even though there never was a vote or some other clearly defined line for transition from "proposal" to "established practice". --Tordanik 13:06, 2 October 2012 (BST)

I changed the wording. However, I think it is worth writing a proposal for the improvements. --Gauß 14:08, 2 October 2012 (BST)

u-turns

How are u-turns currently marked and how are they processed by routers? I am asking this because earlier on this page I read that the API doesn't accept relations where any one way is included more than once. So u-turns can't be marked by including a way into the from role and the to role at the same time. --Gauß 12:31, 3 October 2012 (BST)

Such a constraint doesn't exist any more. Let's hope it's not claimed elsewhere, other than my old 2008 comment on this talk page. Alv 12:41, 3 October 2012 (BST)

Ok, I think that relaxation simplifies things. A related question is: Is it possible to mark only_u_turn? It doesn't appear in the table, but apparently it would fit consistently into the rest of the current rules. --Gauß 13:27, 3 October 2012 (BST)

Ok, so even if the API allows it, what is the use of a no_u_turn restriction where 'from' and 'to' are the same and 'via' is a node on the end of the road? I've seen those cropping up in OSM (even when there was no restriction signed on the junction). Are these useful for anything? Does any router really suggest to u-turn back onto the same way (of course the way is oneway=no) e.g. on a T-shaped junction? Aceman444 (talk) 12:28, 2 July 2016 (UTC)

Aceman444:"...Are these useful for anything?..." So far I know no. So i did this change on the main page, if i'm wrong feel free to revert it. --MalgiK (talk) 17:39, 17 April 2020 (UTC)

See also: corresponding JOSM validator rule & information message: https://josm.openstreetmap.de/changeset/9244/josm --MalgiK (talk) 18:50, 17 April 2020 (UTC)

@Aceman444 and MalgiK: I edited the note to hedge a bit. Indeed, routers like OSRM generally tend to recommend a series of left or right turns on side streets instead of a single-point U-turn on a single carriageway. So in regions where implicit turn restrictions aren't mapped, it wouldn't be advisable to map U-turn restrictions. However, that's not to say editors should necessarily make it difficult to add such restrictions, as suggested in this iD feature request. OSRM is designed to avoid U-turns because historically there hasn't been comprehensive U-turn restriction data in OSM. (Old Garmin units would say "When possible, make a U-turn" for the same reason.) Using that design as a reason to avoid mapping U-turn restrictions creates a chicken-and-egg situation.

As a counterexample, truck routing would benefit from knowing where it's legal to U-turn at an (undivided) intersection, versus making left or right turns on side streets that are less likely to accommodate long vehicles. [2] Even for passenger cars, it may be desirable to U-turn at a mini-roundabout, which is represented as a single node, but there could conceivably be a local restriction against a U-turn at a particular mini-roundabout. [3]

In regions where U-turns are allowed, U-turns are restricted based on whether the size of the intersection can accommodate a passenger car making a U-turn without having to back up. The size can be influenced by a dual carriageway but could be influenced by other factors like lane counts and line-of-sight obstructions. In California, where most signalized intersections explicitly state whether a U-turn is allowed or disallowed, it's easy to find examples of U-turns prohibited along dual carriageways [4], prohibited along single carriageways [5], allowed along dual carriageways [6], and allowed along single carriageways [7]. It's important to allow mappers to make these same distinctions in the database so that data consumers can decide whether to make use of them.

– Minh Nguyễn ^💬 19:47, 26 December 2020 (UTC)

I understand that it is important to map u-turns where they are signaled. In countries where they are normally allowed it is necessary to map prohibitions but where they are normally prohibited I doubt the solution is to flood the database with relations. Even if we do this I don't expect routing software one day will trust and behave differently than OSRM and Garmin. I would rather find convenient to somehow map the cases in which the inversion/turn is allowed when normally it’s not. --sorcrosc (talk) 14:13, 27 December 2020 (UTC)

@Redrat: Right, I map in some places that generally allow U-turns and other places that generally don't. Fortunately for me, this is easier in countries that conform to the MUTCD than those that conform to the Vienna Convention. The MUTCD generally relies on lane diagrams to affirm allowed U-turns, so it's pretty straightforward to tag the from way with turn:lanes=reverse;left| and call it a day. (However, Ohio does have a standard U-turn affirmation sign. [8]) If you're mapping in a region that doesn't use lane diagrams this way, perhaps a manoeuvre relation would suffice for now? – Minh Nguyễn ^💬 19:25, 27 December 2020 (UTC)

Interesting but doesn't seem appropriate because there is no problem with hints. I don't think you can go wrong with a hint for U-turn :) Are turn:lanes also used to determine turning possibilities along with proper turn restrictions? --sorcrosc (talk) 21:19, 27 December 2020 (UTC)

Unfortunately, not yet in OSRM, but it should: [9].

In jurisdictions that allow U-turns, it would be useful for routers to give U-turn instructions with confidence. For example, on an undivided road with three lanes in each direction, it can be difficult and unsafe to turn left across opposing traffic into a driveway; you'd obstruct the leftmost (fastest) lane while waiting for opposing traffic. It would be much easier to make a U-turn then turn right into the driveway.

As an aside, in some jurisdictions that allow U-turns, you can U-turn anywhere, not necessarily at an intersection. [10] In California, it's common for schools to post signs like No U Turn Next 500 Feet to apply to the entire block. Presumably that would be tagged as a uturn=no along the roadway, rather than an infinite number of artificial nodes and U-turn restriction relations, but I don't think anyone has gone through the trouble of tagging that kind of restriction yet.

– Minh Nguyễn ^💬 02:40, 28 December 2020 (UTC)

Ok, so I added an only_u_turn restriction today and JOSM complained. I think it ought to be a valid restriction. (In this case, it was from a one-way link between the two one-way carriageways of a divided arterial, so technically it was redundant because there is no other way to go.) T99 (talk) 05:00, 3 October 2021 (UTC)

"only"

What does a router do if there are two restriction relations marked with the parameter restriction=only_... coming from the same road? Example:

1. restriction=only_...
only b1 and b2 are allowed

2. restriction=no_...
b1 and b2 are forbidden

1. Coming from a, turning to b1 and b2 is allowed. So turning to a, c and d is forbidden.
2. Coming from a, turning to b1 and b2 is forbidden. So turning to a, c and d is allowed.

The documentation doesn't explicitly explain that, but I suppose in that case it routes through both ways B1 and B2 (but not through the two ways on the left side). Am I right? --Gauß 18:41, 5 October 2012 (BST)

How applications handle incorrect/contradictory tagging is rarely defined and usually "random" (that is, depends on implementation details of that particular application). --Tordanik 10:04, 7 October 2012 (BST)

I see, but in this case it doesn't seem contradictory to me. On the contrary, it is consistent with the usage of restriction=no_.... --Gauß 18:34, 7 October 2012 (BST)

PS: I added the analogous example with restriction=no_... and two sentences describing the situation. As you can see the two cases are complementary to each other. Case 1 is correct and consistent. I hope this is a help. If you are still not sure, please tell me why, so that I can try to explain. --Gauß 09:01, 8 October 2012 (BST)

I think it is contradictory because "only_*" means "everything else is forbidden". Based on that interpretation, it can never be correct to have more than one "only_*" restriction with the same "from" and "via" members. And I believe that this is the interpretation supported by the page before you edited it, see e.g. the restriction=no_left_turn + restriction=no_u_turn example. --Tordanik 13:54, 13 October 2012 (BST)

Based on your assumption you could also say "'no_*' means 'everything else is allowed'", so that it could never be correct to have more than one "no_*" restriction with the same "from" and "via" members. But as it is common practice to combine multiple 'no_'-restrictions it must consequently also be correct to do so with multiple 'only_'-restrictions. As you see, I am using the restriction=no_left_turn + restriction=no_u_turn example as rationale for my changes. Now everything is symmetric and consistent. --Gauß 15:06, 13 October 2012 (BST)

This is ridiculous. "no" obviously means 'this is not allowed'. This has no assumptions on other possibilities. "only" does have those, it clearly states 'nothing else is allowed'. Don't view this from a too abstract point. This is not about how we define what "no" or "only" should mean in this context, but it is on the real world language implications of the two words. People should understand tags without having to read wiki pages on surreal redefinitions of words. Preferrably, we wouldn't even have "only" restrictions because of their assumptions that are quite problematic, while "no" restrictions have no side-effects on other possible ways. We do have "only" restrictions though, as they make a common special case a lot easier, and we have to deal with them, but we should not break out from what the English language provides us for their meaning. --Errt 11:40, 21 October 2012 (BST)

Road signs

In the table for the road signs I replaced the combination of the two restrictions "restriction=no_left_turn + restriction=no_u_turn" with "restriction=only_straight_on + restriction=only_right_turn". This is the solution to a long outstanding problem. --Gauß 06:45, 10 October 2012 (BST)

Fortunately, it seems this change was reverted, as in the current model there must not be multiple conflicting restriction relations on the same 'from' and 'via' members with the 'only_*' restriction values. Aceman444 (talk) 13:46, 13 September 2023 (UTC)

Conditional restrictions

We have an approved proposal for mapping things like "only applies to hgv" or "only applies from 8am to 8 pm": Conditional restrictions. For example, a maxspeed that only applies to hgv is mapped maxspeed:hgv=*. Likewise, a turn restriction only for hgv could be mapped as restriction:hgv=*}. The introduction of "applies_only_to" does therefore appear redundant. --Tordanik 14:14, 13 October 2012 (BST)

I agree with you that we should try to use the pattern described in Conditional restrictions, but there is an issue with the notation restriction:hgv=* as I pointed out in section restriction:<type of transport>=<restriction>. I am currently working on a solution for that, but it may be necessary to tweak Conditional restrictions a little bit, and as that might take longer I defined a temporary solution so that people can continue mapping things. The final solution should get rid of applies_only_to, except, day_on, day_off, etc. and use a standard notation instead. --Gauß 15:24, 13 October 2012 (BST)

I'm not sure if the conditional restrictions approach is the best choice here. Both the restriction type and the value are already defined by other tags leaving only the condition to be defined. Trying to apply the syntax of conditional restrictions would just make the tagging unnecessary complicated. I would suggest to use a simple tag like condition=<condition>. For a condition only applying to a specific transportation mode it could be condition:<transportation_mode>=<condition>. The condition would typically be a time condition following the opening_hours=* syntax. However other condition types listed on Conditional restrictions may also be used if applicable. --polderrunner 21:47, 15 October 2012 (BST)

"More turn restrictions" section

Since when were those approved via a vote? Honestly, the main page is getting more complicated for the new users out there. Especially since no editors support those "new" turn restrictions for "half" turns. Heck I don't know of any routers that would support them as well. Maybe that section should be pulled till a vote can be done? -- rickmastfan67 14:55, 14 October 2012 (BST)

+10. We see multiple rationales that can be acceptable but need to be discussed in harmony, without putting a mess. Here nothing has been clearly adopted by a vote; on the other hand many of these tags are already commonly used. Please, DO NOT MODIFY SCHEMES WITHOUT CONSENSUS. Changes are always possible, but put your arguments on the table and let's debate about them seriously, without passions. Teuxe 10:16, 24 October 2012 (BST)

What about pedestrians and horses?

There is no clear indication if the restriction concept applies to pedestrians or horses too. Is it right to assume that pedestrians are included in a restriction? Then we need to add except=foot and type=restriction:foot. Otherwise we need to add an appropriate note. I came across this issue because the JOSM GraphView plugin applies turn restrictions to pedestrian routing. --holgermappt 18:20, 26 January 2013 (UTC)

I agree that this is not clearly defined. There is one sentence ("Restriction refers to all vehicles") that could be interpreted to mean that pedestrians are not included. And probably that's also what mappers intend to show - in reality, there are probably very few signed turn restrictions that include pedestrians. An explicit note ("Turn restrictions do not apply to pedestrian unless explicitly stated") would clarify this. --Tordanik 19:26, 27 January 2013 (UTC)

I think the reference to "all vehicles" is just there because the writer did not think about pedestrians and horses, not because they are explicitly excluded. The note should be "Turn restrictions do not apply to pedestrian unless the type or key is restriction:foot". Same for horses. --holgermappt 18:55, 29 January 2013 (UTC)

I've added this note for pedestrians now. I don't feel comfortable enough with rules for horses to add a remark about horses, but it's fine with me if anyone wants to do so. --Tordanik 22:35, 2 February 2013 (UTC)

I'm yet to see a turn restriction that did, or even could apply to pedestrians. AFAIK some countries consider horses non-vehicles, whereas others state that a horse rider must obey "applicable" rules for vehicles - that would include turn restrictions. I'd say GraphView is then making a mistake if it applies them to pedestrian routing. We'd need to query locals in each country and make a table for the horse riders. Alv 06:58, 28 January 2013 (UTC)

As long as the (reasonable) implied exception for pedestrians is not documented, I do not consider application behavior a mistake either way. The question is simply unresolved until now. --Tordanik 13:40, 28 January 2013 (UTC)

Unification of type=restriction:vehicle and restriction:vehicle=*

Currently, the page presents two equivalent mapping styles for a restriction that only applies to e.g. hgv: type=restriction:hgv (20 uses) or restriction:hgv=no_right_turn (41 uses). I think we should choose one of the two variants. As for which one, I tend to prefer the restriction:hgv=* syntax which is compatible with the Conditional restrictions that we use elsewhere, whereas the alternative is only used on turn restrictions so far. --Tordanik 15:25, 28 January 2013 (UTC)

Software, which doesn't understand restriction:hgv, thinks, that there is a restriction for all vehicles. For example, type=restriction + restriction:hgv=only_straight_on from way A to way B is recognized as restriction to drive from way A to way B! There is no such problem with type=restriction:hgv + restriction=only_straight_on, because in such case software doesn't recognize tags as a restriction to drive from way A to way B. I think, that according to Conditional restrictions we should write something like type=restriction:conditional + restriction:conditional = only_straight_on @ hgv . Dinamik 22:54, 28 January 2013 (UTC)

"doesn't understand restriction:hgv, thinks ..." - it might, or it might (it should!) ignore the relation altogether as a broken restriction relation, if it doesn't find the basic restriction=*. If software doesn't look at both tags, the same argument would be true for type=restriction:hgv, that some software would look just at the restriction=only_straight_on tag. This is just a matter of what mappers will adopt and what is in itself better reasoned for in the docs. Alv 23:26, 28 January 2013 (UTC)

There was no direction in documentation, that software should ignore type=restriction without restriction=... - so people have already tuned software to think, that type=restriction with way A with role from and way B with role to is a restriction to drive from way A to way B. We can write these phrase now, but there will be addition hindsight and much time goes until people retune their software. Dinamik 07:17, 29 January 2013 (UTC)

I'm not aware of applications that will behave in this manner and it would be stupid to program it this way. Restriction relations have completely different meanings depending on whether the restriction value starts with "no_" or "only_", it's simply not possible to do anything meaningful with a relation that has no restriction value. --Tordanik 08:44, 29 January 2013 (UTC)

As it was mentioned by people, osm2mp thinks, that type=restriction with some unknown tag with way A with role from and way B with role to is considered as restriction to drive from A to B. This software is very popular and is used all over Russia and in many post-Soviet states as first step of making maps for many different applications (for example, car navigators). Of course, it is better to repair this mistake in software, but current logic, as I saw not much time ago, is what I described. If you add tag type=restricton + restriction:<type>, you should understand, that you add mistake to many maps. Dinamik 19:35, 30 January 2013 (UTC)

I'm fine with waiting for a while to give the people at osm2mp the chance to correct their bug before we recommend relation:hgv=* as the preferred alternative. So we can leave it undecided for now if you make sure that the developers are informed through their bug tracker. But that does not mean that I accept this solution to be set in stone forever, as you are attempting to do with your recent edit. The relation type is hardly the correct place for this sort of information - it exists to let software (including editors) select the correct code for handling the relation on a very broad level. A restriction for hgv is clearly still the same broad class of relation, it's just a single attribute which is different. --Tordanik 19:48, 31 January 2013 (UTC)

I payed osm2mp-developer's attention to this question. Dinamik (talk) 05:18, 1 February 2013 (UTC)

Thank you for communicating this. --Tordanik 22:31, 2 February 2013 (UTC)

osm2mp had last commit in december 2013, so this program should not be our concern anymore. Any more program known with this "bug"? I agree with Tordanik on this topic.--Jojo4u (talk) 14:43, 26 June 2015 (UTC)

Current top 3 stats for restriction:*=* 204 bicycle, 175 hgv, 19 bus. Type=* only has: 69 hgv, 10 motorcar, 5 bicycle.--Jojo4u (talk) 14:51, 26 June 2015 (UTC)

Turn restrictions based on vehicle length

How should one tag a turn restriction which is based on vehicle length or other physical characteristic (not by vehicle type). For example, "no right turn for vehicles over 30 feet in length"? --T99 (talk) 22:52, 17 February 2013 (UTC)

I would use a conditional restriction as follows: type=restriction + restriction:conditional=no_right_turn @ (length>30') --Biff (talk) 12:57, 7 July 2016 (UTC)

This question is valid if that length restriction is only marked on the turn restriction traffic sign, but nowhere else on the road, thus it is possible for longer vehicles to drive over the road from other sides (just not through the turn restriction sign). Such situation could exist e.g. when there is some particular sharp turn into a road from one side. But if the restriction is valid for the whole road in all directions (via a 'maximum allowed length' traffic sign), then a plain maxlength=30 on that road way solves this. Aceman444 (talk) 13:05, 13 September 2023 (UTC)

This page recommends tags deprecated at another page

day_on, day_off, hour_on, hour_off are deprecated in section: Conditional_restrictions#Deprecated_tags Xxzme (talk) 01:34, 7 September 2014 (UTC)

The section immediately below that is "Does not apply to", which says that conditional restrictions don't apply to turn restrictions. Since there's currently no other system in place for defining conditional restrictions on turn restrictions, we still need to use these supposedly "deprecated" tags, so I don't see how they can be deprecated.--Alester (talk) 15:50, 9 April 2015 (UTC)

Well, as you rightly said there's a conflict between the two statements, but imo it's not clear that the statement "does not apply to" is the correct one. There's also the issue that some situations cannot be mapped with the tags currently suggested for turn restrictions, but could be mapped if we used conditional restriction tagging. --Tordanik 16:46, 18 April 2015 (UTC)

I still don't see why this article should state that Conditional restrictions can be used, when that other article gives no hint of how they can be used on a turn restriction relation, nor can I fathom any way to make it work. Until a viable replacement tagging scheme has been devised, the so-called "deprecated" tags are all we have. At best, the note should say that Conditional restrictions should be considered and used where possible, and to use the following tags in other situations.--Alester (talk) 22:25, 30 April 2015 (UTC)

After looking at both pages, it was fairly obvious to me how to write a conditional turn restriction: replace the restriction=* tag with a conditional restriction with a <restriction-type> of "restriction" and a <restriction-value> of whatever you'd use for the value usually. In my case, this gave me restriction:hgv:conditional=no_entry @ (weight > 7.5 AND 22:00-07:00). Is this not what was intended? --Ben Harris (talk) 12:28, 20 December 2015 (UTC)

Bump. As per Ben Harris comment, there does not seem to be any confusion with how conditional restrictions can be added. Is it time to update this section with the latest :conditional format?--Planemad/Talk 07:29, 29 April 2016 (UTC)

I would not remove the old-style tags, but imo it is indeed time to document the conditional restrictions as an option. --Tordanik 13:53, 5 May 2016 (UTC)

If we must keep the deprecated tags on the page, should we at least make it more obvious that people shouldn't be using them? I find the box that says "the following keys are deprecated" very easy to miss. Perhaps that part of the table could have a red background, or those tags could be moved to a different section, such as "Former tags" or "Historical tags". Or (my preferred option), remove those tags entirely. TristanA (talk) 17:58, 9 February 2017 (UTC)

In my opinion, if conditional restrictions are used, then the except tag is also not needed. Instead of writing except=bus it would be better to write restriction:bus=none. --Biff (talk) 12:59, 7 July 2016 (UTC)

"Except bicycles" on conditional turn restriction?

Does restriction:conditional=* deprecate restriction=*+except=*? Not having except=* makes mapping 6455280 6455280 awkward (photo). bicycle=yes might not be interpreted as having a higher priority. --Kakurady (talk) 00:17, 12 August 2017 (UTC)

The conditional-compatible way of tagging this would be restriction:bicycle=none, which I don't find particularly awkward. The problem is that we don't actually have an explicit default value (such as "none" or "no") defined for the restriction key yet...

Nevertheless, I would see it as a goal to replace the except key with conditional restrictions in the long term, because the except key only works for relations, whereas the conditional restrictions could be the same for all tags – whether it's maxspeed, oneway, access, or restriction. --Tordanik 18:37, 14 August 2017 (UTC)

However, a year and a half later, https://taginfo.openstreetmap.org/keys/restriction:bicycle still has zero uses of "none", while https://taginfo.openstreetmap.org/tags/except=bicycle has 2987 uses in relations and combinations including bicycle in https://taginfo.openstreetmap.org/keys/except#values add a couple hundred more (though some like "bicycle;moped;motorcar;psv" are so wide-reaching that should arguably be tagged by specifying what is actually included). Unless I'm misunderstanding how restriction:bicycle=none should be used? --Jarek Piórkowski (talk) 00:13, 17 April 2019 (UTC)

The except=bicycle tag is well documented, has editor support in iD and the JOSM turn restriction plugin, and has built-up mind share from being around for a long time. Meanwhile, the "none" value isn't even documented yet. It's no surprise that people aren't using it. This doesn't change that it would be a logical consequence of the conditional restrictions rules and would therefore (in my opinion) be a good idea. But even good ideas need someone to put in significant effort to actually popularize them, maybe write a proposal and/or improve the tooling, and convince mappers and developers that making the data model a little more consistent is worth the effort it costs to change. --Tordanik 16:38, 17 April 2019 (UTC)

Adding implicit TRs

See this [post] from Daniel Hoffman about Sharp Turns onto Ramps. These need to be mapped as turn restictions for safe guidance by routing engines, and several communities (e.g. Denmark, https://www.openstreetmap.org/user/daniel-j-h/diary/41777#comment39368) have already started adding them in OSM. Some of these restrictions don't have an explicit sign board on the ground, and we should add implicit=yes to identify these kind of TRs. This is different from the mapping of numerous unsigned U-turn restrictions in Brazil, referenced in the introduction to the current wiki page, since that case can easily be handled algorithmically. Maning (talk) 05:30, 10 October 2017 (UTC)

I am not entirely sure that it would be useful to know what is causing a given turn restriction. In my mapping I never tagged this information, never felt that it would be useful and I am not going to start doing this Mateusz Konieczny (talk) 20:26, 11 October 2017 (UTC)
Unless iD adds another dropbox for this, it is not very helpful to tag them manually (hard to remember doing this IMO). I've added a lot of implicit restrictions without this tag. However, I do think this tag is useful, especially users demand aggresive driving. Mapbox has been doing this for years though. -- CBRS (talk) 23:03, 21 January 2021 (UTC)

remove role location_hint

The page defines a role "location_hint" by "A hint to a renderer as to where might be a good place to position a symbol indicating the restriction." This is pure "tagging for the renderer" and not verifiable "on the ground". Thus I suggest to remove that role from the page. (Also despite that role is on that page since its creation 12 years ago, it appears only 172 times in the osm database, while we have more than 1.1 million turn restrictions, which shows too that this role is not needed/useful.) --Klumbumbus (talk) 10:20, 6 April 2019 (UTC)

I agree, but would suggest rather than removing, having a "deprecated" note explaining what location_hint was intended to be in case someone finds that in a relation and doesn't know what it means/meant. --Jarek Piórkowski (talk) 14:57, 6 April 2019 (UTC)

Good point. I added an explanation instead of removing it. --Klumbumbus (talk) 11:35, 14 April 2019 (UTC)

'except' key used by turnrestrictions plugin in JOSM

I have seen that the only place in the wiki that talks about 'except' key is this article. However, this key does not have its own wiki page, and I do not know the status of the key (approved, in use, etc.)

The plugin turnrestrictions is using this tag, and if the key hasn't been accepted, this plugin could be forcing its usage without being approved. Key:except redirect to this page, which I think it is incorrect for a key.

Also, there is not any page about the except combinations, like except=bicycle. Tag:except=bicycle

What should we do? Using it because there is a small documentation? or can someone fully document it to have the necessary support? or the plugin should remove it until fully accepted?

--AngocA (talk) 02:43, 8 March 2022 (UTC)

This is a JOSM ticket response about this issue: https://josm.openstreetmap.de/ticket/21917#comment:2

However, I do not agree about not having a wiki entry for each accepted key.

--AngocA (talk) 15:51, 10 March 2022 (UTC)

Possible values for the except key

Currently the wiki lists these values for the `except` key: psv / bicycle / hgv / motorcar / emergency The most popular ones on tag info are the following (ignoring cases with multiple values): bicycle (4713), psv (2175), bus (1211), emergency (519) Especially bus seems popular but is not included in the list yet. And/or should it simply be covered by psv, but apparently many mappers do not know about this then. And what about moped/motorcycle? And what about except=destination? Is this list supposed to be complete? --Easbar (talk) 18:53, 28 October 2022 (UTC)

The value of 'bus' could be added to 'except' key, as maybe in some countries taxis (part of psv) should not be allowed, so one can't say 'psv' should be used everywhere instead of 'bus'.

Key except=* currently is documented to only take transportation modes as values. For other conditions the page offers the restriction:transportation_mode:conditional=* key so you would use e.g. restriction:vehicle:conditional=no_right_turn @ destination. I see you may want the negation of that (destination traffic has no turn restriction, it is exempted), which maybe harder. Maybe like restriction=no_right_turn + restriction:vehicle:conditional=none @ destination albeit 'none' is not a documented value yet. Aceman444 (talk) 13:33, 13 September 2023 (UTC)

Turn restrictions on intersections with _link highways

I've seen a lot of turn restrictions used in Australia to ensure routers don't skip highway links representing physically separate turn lanes. This seems reasonable, however the line about not mapping restrictions where they're signed seems to conflict with this. Should this be added as some kind of exception, or is this seen as mapping for the router but accepted in AU? --Fortera (talk) 09:08, 29 November 2023 (UTC)

I might add that a Mapbox link on the wiki page does talk about mapping these too. (https://labs.mapbox.com/mapping/mapping-for-navigation/implicit-restrictions/) --Fortera (talk) 09:09, 29 November 2023 (UTC)