Talk:Relation:restriction

From OpenStreetMap Wiki
Jump to: navigation, search

Contents

not splitting ways

I like this proposal better than the one which required splitting ways at each turn restriction. However, I would recommend that you limit the "via" role to nodes only. If a turn onto a connecting way is restricted, then that information alone is sufficient to define the restriction.

I do not understand how this proposal can avoid the need of splitting ways. Just imagine two simple roads intersecting at a crossing where is prohibited to turn right when you're coming from South. How does a routing software know (without split ways) that it is allowed to turn right when coming from North? -- Hatzfeld 15:05, Oct 13, 2008 (CEST)
Adding a second via node on the southbound or eastbound way (the first node before/after the intersection) makes for an unambiguous no_right_turn - those nodes would not be visited when coming from north and turning right towards west. Alv 13:20, 13 October 2008 (UTC)
I would like splitting more than 3 via-nodes.

marking the intersection node

Further, I think it needs to have an "at" role to know which node is the intersection node, since the members of relations are unordered. Consider a U-turn: this is essentially forbidding a turn from a way back onto itself. In this case, you would have the same way id in both the "from" and "to" roles, but with only two unordered "via" nodes, you wouldn't know which one was the restricted intersection or which direction it applied to. If one of the nodes was an "at" node, and the other was a "via" node, then the restriction is completely defined. --SiliconFiend 23:10, 8 October 2007 (BST)

A U-turn for the same way has the same "from" and "to" way ids and the "via" node id where the U-turn is forbidden. Why do you want two "via" nodes? If you think about a U-turn on a dual carriageway, one of the "via" elements has to be the small link part connecting the carriageways. --BerndR 26 Oct 2007
I read that the API no longer accepts a relation where any one way is included more than once. Presumably it was an anomaly that creating such a relation was possible in the past. Alv 18:18, 4 June 2008 (UTC)
But for a single way, that doesn't specify which direction in which the U-turn is forbidden. It's completely conceivable that a U-turn could be prevented at a given node while traveling in one direction, but allowed when traveling in the reverse direction. Without the extra "via" nodes, it's ambiguous. I will retract my objection to using ways in a "via" role, however, because of your example. When a single carriageway crosses a dual carriageway, it's not possible to model the turn restriction without it (you would end up restricting a potentially legal turn from the crossing way). My objection was because I don't know if I'll be able to translate it to auto-routing Garmin GPS maps. --SiliconFiend 20:24, 26 October 2007 (BST)

Is the unordered "via" list sufficient or do we need an ordered list of "via" node/way ids? --BerndR 26 Oct 2007

Unordered is okay (and currently the only option with relations, unless you do something with the "role" attribute), provided the "at" nodes are used in the case I mentioned above (prohibited U-turn on a single carriageway). --SiliconFiend 20:24, 26 October 2007 (BST)

Time scheduled restrictions

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)

I suppose you could have two different relations with two different hour_on and hour_off times. --SiliconFiend 01:03, 9 October 2007 (BST)

In reading some of the other earlier relation proposals, specifically the Relationships page, I noticed someone mentioned a one-way street in Hamburg, Germany, which changes direction in the morning and afternoon to accommodate commute traffic. It would be possible to model this using the turn restrictions proposal. You would have a pair of turn restrictions for each intersection--one for each applicable time of day. The turn restrictions would have to be created at each intersecting road, though, so it's somewhat tedious. This relation could also model the change in direction of the street itself when applied at the entrance and exit of the one-way section. In this case it would be more of a straight-on restriction with the appropriate hour_on, hour_off rules. The way itself should not have the oneway tag; otherwise it would just confuse auto-routers. --SiliconFiend 00:51, 10 October 2007 (BST)

Wouldn't it be easier to model this with a special "reversible way" tag? This would avoid the need to create turn restrictions at every intersection. Andrewpmk 04:00, 10 October 2007 (BST)
I guess it depends how common this situation is. If it's not very common, then we could just put the burden on those with "weird" streets to create those turn restrictions. Otherwise, it's an extra step for auto-routers to interpret the tag, iterate through each node in the way and apply the turn restrictions to each intersection. Your "reversible" tag (relation?) suggestion is definitely more user-friendly, though, so in keeping with the spirit of making the map easier to use and edit, I could go for it. --SiliconFiend 04:43, 10 October 2007 (BST)
These restrictions should not be represented by relationships but by attributes of the way! GDF defines traffic restriction attributes for a way. It is a list where each entry contains the allowed direction (both, positive, negative, none), time, and vehicle types. To introduce this in OSM we need Composite Attributes/Composite Tags. --BerndR 26 Oct 2007
The relation creates an attribute on the way in a more flexible manner than just tagging on the way allows. It *is* a composite attribute/composite tag. --SiliconFiend 20:24, 26 October 2007 (BST)
I agree a relation is a better representation, as it is not a physical object and can be edited without touching the way itself if changed. Ways for ways, relations for signs. Btw, there is a 4 lane highway in Hannover that changes to a oneway street in one direction in the morning and in the other in the evening during big fairs. See A37 "Messeschnellweg" --Lulu-Ann 12:18, 3 July 2008 (UTC)

These turn restrictions represent 'prohibited manoeuvres', i.e., turns which are not allowed. GDF maps also represent 'restricted manoeuvres' (or 'obligatory turns'), i.e., turns which are allowed and have to be taken (cf. traffic sign Turn Right). I propose to add appropriate values without the prefix 'no_' to the value list of the 'restriction' tag. --BerndR 26 Oct 2007

This is not necessary. A required right turn can be modeled by restricting a straight-on or left turn. --SiliconFiend 20:24, 26 October 2007 (BST)
I don't agree, I think mapping the allowed manoeuvers is needed, as the speech output of your navigation device does not tell you at the crossing "don't turn left and don't go straigt on and don't go half rigth" but it needs to tell you "turn right"! --Lulu-Ann 12:18, 3 July 2008 (UTC)
Hmm, but your software will have calculated a route which will turn right (because it can't turn left or go straight on) - so it will tell you to turn right anyway. Given that most movements are allowed, just listing prohibited turns will save significant space in the database - and will achieve the same result. Richard B 12:12, 8 July 2008 (UTC)
No, that will not give the same result, as the speech output will not know if the allowed direction is "right", "halfright" or "sharp right" (correct this if I am not using good terms)--Lulu-Ann 16:06, 8 July 2008 (UTC)
Yes, it can give good results. I've witnessed a GPS indicate a "sharp right" turn. The angle can be easily calculated from the nodes and then compared to some table which maps ranges of angles to terms such as "slight right" (or "bear right"), "right" or "sharp right".
I agree, that can give good results. Just because you have seen that once, does not mean it always works fine. I have seen professional navigation software failing often. I prefer a solution that garuantees functionality. --Lulu-Ann 07:55, 9 July 2008 (UTC)
What I meant was that the actual calculation of the route will be identical, regardless of whether you map allowed turnings, or prohibited turnings. The voice output just needs to say "turn right" if there is only one allowed manoeuver - or "turn first/second right" if there are two options etc. Most sat-nav equipment will also give a diagram of a complex junction - removing any ambiguity. Inputting hard-coded allowed turnings into the database doesn't "guarantee" functionality - since the actual angles may subsequently be altered by an editor to the map data - who might not update the necessary relation. Let's just map restrictions (the least common type) and let any voice output work out what to say from the angle of the data. This is much more likely to get it right than stating "slight right", "sharp right" etc. in a relation. Richard B 11:15, 9 July 2008 (UTC)
  • Without a firmly defined structure, a "Validity Period" tag will be useless to auto-routers. I would suggest using the proposed day_on, etc. tags where possible, and come up with something else for the oddball situations such as you've described. (Besides, I doubt my handheld GPS will know if it's a school holiday or not.) --SiliconFiend 17:23, 5 November 2007 (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)

Example

Can someone please provide me with an example, a picture where all the nodes and ways are marked, and how the relation tags should look like... That would be helpful, as I know a lot turn-restrictions in my area, and I just need a hint *how* to do map them...

User:Coldtobi - 09:01, 15 November 2007

I assume that's been addressed adequately now with Relation:restriction#Examples (presumably added since this old comment) -- Harry Wood 10:16, 1 September 2010 (BST)

Should this be scheduled for voting?

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)

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)

Changing the lange and making a U-Turn

If at a junction there are turn restrictions, it is also very often forbidden to change the lane.

Assume a T-Crossing where we come from south and it is forbidden to turn left (west). We could instead turn right (east), make a U-turn and go west.

So if there is a turn restriction and the lanes are not separated, the routing software will always try this trick. -- Jms 08:06, 9 June 2008 (UTC)

What does this have to to with lanes?--MarcusWolschon 13:42, 23 March 2009 (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:

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

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 rectengular intersection of two ways the values no_left and only_stright_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)
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)

No Entry

Could we also have restriction = no_entry, this would be used where you are not allowed to enter a (two-way) side road.

question for clarity

Unfortunately, there are neither examples for the only_x cases nor a clear, short definition of the meaning this relation (the introduction is mainly about the purpose of the relation). Thus let me ask: 

The relation states that you must not travel from “from” via “via” to “to”. The tag restriction=

Is this correct? --Tordanik 19:12, 10 September 2008 (UTC)

Yes, that is correct but universally only if the ways start or end at the via node. Otherwise a present tag restriction=* might not forbid some turns from the from to to. But if the via node is not the first or last node for either way and that way is does not have oneway=yes then the relation without a restriction=* forbids up to four turns - which might be correct or might be not. Splitting ways or adding sufficient extra via nodes or a restriction=* is then needed. Alv 05:55, 11 September 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=

Turns.png
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)
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)

Rendering of routing restrictions (proposal)

Routing Visualization
The following image shows how routing restrictions could be rendered in maps. The blue signs indicate the allowed turn maneuvers. The sign is always on located of the right side of the street relative to the concerned driving direction. A dotted line between the sign and the street helps to display the assoications in crowded areas.

In this case only the routing restrictions given by oneway streets are displayed, however the same approach should work with other routing restrictions too.

Restrictions detail the prohibited manoeuvres rather than the allowed ones, so why should we render differently? Chriscf 08:30, 20 October 2008 (UTC)
When visualizing turn restrictions / turn prohibitions we need a visualization method that is intuitively understandable to (almost) everybody and does not distract on a map. This applies very well for describing directed turn allowances with arrows and could be presented as shown in the picture. However it is very hard to do so with directed turn restrictions. E.g. most of the worldwide available oneway street symbols are not directed, they just tell "do not enter" and the direction is given by the line of sight from the persons location. This can not be used on a map.ccording to my understanding, it should be possible to automatically transform any set of turn restrictions at a certain crossing into an equivalent set of number of turn permissions (as show in the picture). If this would not be unambiguously possible, the whole turn restrictions concept requires rework anyway. Josy 19:44, 23 April 2009 (UTC)
it is not correct to transform from the prohibited ("red") rendering to the permitted ("blue") rendering without examining the underlying ways attached to the node for oneway restrictions. otherwise, nonsensical results may arise, and users may do questionable things trying to get a "correct" rendering. nfgusedautoparts 18:42, 08 January 2010 (UTC)

The "Restriction Analyser" shows signposts on a map e.g. here. If I understand Josy's idea correctly, he's talking about a special rendering showing allowed routes through all junctions as blue signposts, which is different of course -- Harry Wood 00:28, 4 May 2010 (UTC)

Proposed changes

  1. 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!
  2. Use restriction=* only with the two values "permissive" and "restrictive" to tell if this relation is a "only_*" or "no_*"-rule.
  3. 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.
  4. Replace "except" with the optional and unmistakable access=*-values "affected", "unaffected" and others. See Different restrictions for different vehicles!
  5. 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

Logic

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)

Brazil

Turn restrictions are common in Brazil, specially no left turn. Can an entire road be marked as no left turn without using any to nodes? 

      1          2         3                    
W-----+----------+---------+-----E
      4          5         6

A car coming from W driving towards E can enter 4 5 6 but not 1 2 3, when coming from 4 you can cross to 1, if you can go from 1 to E and W or only to W is to be decided by another relation or defined by 1-4 road. Is the following correct?

I am omitting from and to by purpose. --Skippern 10:52, 8 December 2008 (UTC)

My proposal above would cover this with 6 relations (one for each direction and for each junction). Perhaps it would be wise to tag the way with restriction=no:left. For parsing the 6 relations would be better, because they are more obvious! --Phobie 11:48, 8 December 2008 (UTC)
So in a junction where nobody is allowed to turn left, there will either be two roads or the node itself with restriction=no:left or four relations, one for direction? --Skippern 12:07, 8 December 2008 (UTC)
I would add 4 restrictive relations for that! All those "left"/"right"-rules are not good because parsing software needs to guess a lot. With Relations and Members the software simply knows which ways are usable and which not. It's more data but also more information and hard-disks are cheep! A good map-editor would offer the user a simple junction builder interface, where the user can chose roadsigns with a click... --Phobie 13:45, 8 December 2008 (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) 

             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)

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

preprocessing turn-restrictions for routing

I am preparing to write an osmosis-task to pre-process a local map to make turn-restrictions usable by routers that cannot work with restrictions on graph-nodes.

Limitations:

  • only one via-node that must be shared by From and To.
  • no support for "no-u-turn" as this cannot be expressed this way.
  • For multiple From and/or multiple To -ways the algorithm is executed for each pair in sequence.

--MarcusWolschon 14:10, 18 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: Relation.png 79516 (XML, check, manage, JOSM, history, view, gpx ), described in http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/000894.html. Robx 08:07, 27 February 2009 (UTC)
And here: Relation.png 71051 (XML, check, manage, JOSM, history, view, gpx ) --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 Relation.png 139064 (XML, check, manage, JOSM, history, view, gpx ) (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 with access ?
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)

Why via nodes?

It is apparent that we need one or even multiple via ways to express some situations. There is, however, no obvious reason for the required (!) single via node -- it doesn't add information, because it is simply the junction node between from and to. Similarly, multiple via nodes are unnecessary and, imo, underspecified.
I'd therefore suggest to remove via nodes from the specification. It would become more simple, but could still express everything. --Tordanik 11:02, 8 March 2009 (UTC)

The via node is necessary, if the two ways have more than one crossing in common. But alternative you can split the ways. It is also a part of the #Proposed changes. --Langläufer 18:51, 8 March 2009 (UTC)

Well, since this proposal has already decided that requiring splitting is usually acceptable (which is why we don't use that alternative xrestriction proposal), I don't consider that a problem -- few ways have both start and end node in common anyway. The "Proposed changes" do, however, not include removing the possibility of nodes entirely, they only mention the single-node-case, whereas I don't see a value in multiple via nodes, either. --Tordanik 21:28, 8 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 n
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)

Only u-turn

Problem: http://osm.virtuelle-loipe.de/restrictions/?zoom=16&lat=52.42899&lon=10.76296&layers=B00TT wants from and to way ?!?!??

Yes, only U-Turn is not fully supported yet bey Restriction Analyser, because it is more complicated. Here we can have same or different from- and to-ways, and also node or way with role via. Only one way (from or to) in a restriction relation was not documented before. But yes, it makes sence. Otherwise you can add the way e.g. with JOSM 2 times with different roles to the relation. --Langläufer 15:37, 15 February 2010 (UTC)
Can we have another icon for U-Turns than for errors, please? Lulu-Ann

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)

Congestion control measures

I realize this is a long shot. In Quito, Ecuador, authorities have created a "restriction zone" [2], see the red outline on the map. The following restriction apply:

The restriction zone could be seen as per-street, but really applies only inside the polygon of the image linked above.

Suggestions?

Perhaps low emission zone can help? --NE2 16:11, 12 August 2010 (BST)

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

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)

for

Please, pay your attention to Proposed features/mark vehicles, for which restriction is operating. Dinamik 13:32, 8 July 2011 (BST)

no straight on

"moving straight on is prohibited"
Example of a road with sign "moving straight on is prohibited" without one way
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)

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)
"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 3.1.svg 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 3.1.svg 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)

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..

--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)

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:
  1. 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.
  2. 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:
3.19.png
8.4.1 (Road sign).gif 

type=restriction
restriction:hgv=no_u_turn

Example 2:
4.1.1 (Road sign).gif
8.4.2 (Road sign).gif 

type=restriction
restriction:caravan=only_straight_on

Example 3:
4.1.2 (Road sign).gif
8.4.3 (Road sign).gif 

type=restriction
restriction:motorcar=only_right_turn

Example 4:
4.1.5 (Road sign).gif
8.4.4 (Road sign).gif 

type=restriction
restriction:bus=no_right_turn

Example 5:
4.1.6 (Road sign).gif
8.4.5 (Road sign).gif 

type=restriction
restriction:agricultural=no_straght_on

Example 6:
4.1.3 (Road sign).gif
8.4.6 (Road sign).gif 

type=restriction
restriction:motorcycle=only_left_turn

Example 7:
3.18.2.png
8.4.7 (Road sign).gif 

type=restriction
restriction:bicycle=no_left_turn

Example 8:
3.18.1.png
8.4.8 (Road sign).gif 

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)

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:
3.19.png
8.4.1 (Road sign).gif 

type=restriction:hgv
restriction=no_u_turn

Example 2:
4.1.1 (Road sign).gif
8.4.2 (Road sign).gif 

type=restriction:caravan
restriction=only_straight_on

Example 3:
4.1.2 (Road sign).gif
8.4.3 (Road sign).gif 

type=restriction:motorcar
restriction=only_right_turn

Example 4:
4.1.5 (Road sign).gif
8.4.4 (Road sign).gif 

type=restriction:bus
restriction=no_right_turn

Example 5:
4.1.6 (Road sign).gif
8.4.5 (Road sign).gif 

type=restriction:agricultural
restriction=no_straight_on

Example 6:
4.1.3 (Road sign).gif
8.4.6 (Road sign).gif 

type=restriction:motorcycle=
restriction=only_left_turn

Example 7:
3.18.2.png
8.4.7 (Road sign).gif 

type=restriction:bicycle
restriction=no_left_turn

Example 8:
3.18.1.png
8.4.8 (Road sign).gif 

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)

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)
Retrieved from "http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction"
Personal tools
Namespaces
Variants
Actions
site
Toolbox