Talk:Relation:restriction/Archive 1

This page is an archive of topics previously discussed on the Talk:Relation:restriction wiki page.

not splitting ways

Resolved: The premise of this is incorrect as the way does need splitting --RobJN 23:56, 22 October 2012 (BST)

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.

• it is unnecessary complicated if there are 3 nodes have all the role via. A routing program have to search in both ways for each node. I do not think any routing algorithm will use it! What happens, when anybody splits the way between the via-nodes?
• the mapping of Route-Relations also needs splitting at crossings. It is mostly only a question of time, till the ways will be split for that reason.
• without splitting, we get more unnamed relations at each way. This is not better than short ways. --Langläufer 13:46, 21 January 2009 (UTC)

marking the intersection node

Resolved: Ways have to end at via node & start from via node (i.e. 'splitting ways' thus a second via role is not needed. --RobJN 23:56, 22 October 2012 (BST)

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)

Such a constraint doesn't exist any more. Alv 12:41, 3 October 2012 (BST)

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

Resolved: OP's comment to be reconsidered in the light of the newly approved Conditional_restrictions. --RobJN 23:56, 22 October 2012 (BST)

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)

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

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

Examples

Resolved: --RobJN 23:56, 22 October 2012 (BST)

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?

Resolved: I'm unsure if a vote was ever held but the proposal is in common use --RobJN 23:56, 22 October 2012 (BST)

• I already am using it. Just because it's merely proposed doesn't mean its unusable. But, yes, it probably should be put to voting. --Thomas Wood 20:22, 27 April 2008 (UTC)
• I'm also already using it and think that it should be scheduled for voting. I'll be voting Approve. --Gregoryw 07:08, 28 April 2008 (UTC)

Changing the lane and making a U-Turn

Resolved: We assume the routing engine to be clever enough to not suggest this as a common routing solution

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)

No Entry

Resolved: --RobJN 23:56, 22 October 2012 (BST)

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

Resolved: --RobJN 23:56, 22 October 2012 (BST)

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=* does not affect this meaning.

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)

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)

Brazil

Resolved

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?

• type=restriction
• restriction=no left turn
• member W-E

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)

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.

• Documentation (in the Traveling Salesman -wiki)
• State of the Feature-Request
• Osmosis-Task

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)

Why via nodes?

Resolved: Resolved when decision made to require splitting ways. --RobJN 00:25, 23 October 2012 (BST)

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)

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

Congestion control measures

Resolved: This does not fit in here (and is mutually exclusive so should have a non conflicting scheme of its own). --RobJN 00:25, 23 October 2012 (BST)

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

• Every private car will be restricted from driving in the restriction zone during rush hours (7am-9:30am and 4pm-7:30pm) ONE day a work-week.
• What cars affected are decided by the last digit of their license plate (1 & 2 = no-go mondays. 3 & 4 = no-go tuesdays. And so on.)
• Public transport is allowed to circulate whenever.
• There is not supposed to be a way to pay yourself out of this restriction. It's absolute.

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)

for

Resolved: --RobJN 00:25, 23 October 2012 (BST)

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