Talk:Conditional restrictions

From OpenStreetMap Wiki
Jump to: navigation, search

Refering to default value by *

Sometimes it is intended to have the same value in all or most lines of the conditional restriction. For such cases I suggest to allow to refer to the default value by the symbol *.


  • some_restriction = some_value
  • some_restriction:hgv:conditional = some_value
  • some_restriction:motorcar:conditional = some_value
  • some_restriction:bicycle:conditional = some_value @ (16:00-18:00)

With the * that would become:

  • some_restriction = some_value
  • some_restriction:hgv:conditional = *
  • some_restriction:motorcar:conditional = *
  • some_restriction:bicycle:conditional = * @ (16:00-18:00)

It would improve maintainability because changes to the value would have to be made only in one place. Moreover different values which may have been entered by mistake (instead of using the same value in all cases) could be avoided, so the * would help to avoid errors. --Bob K. 15:12, 15 October 2012 (BST)

Can you give an example where this is actually useful? Conditional restrictions are normally used to deviate from the default value. -- Eckhart 16:49, 15 October 2012 (BST)
I doubt this would be very useful. As Eckhart says the conditional values are typically different from the default ones (otherwise there wouldn't be a need for the condition!). And I fear that such an extension is going to confuse most mappers without having much if any added value. Furthermore, your examples violate the syntax by omitting the condition in *:conditional tags. --polderrunner 19:41, 15 October 2012 (BST)
I am mapping a lot of turn restrictions. They have a parameter restriction=turn_direction from which you don't deviate. It must always be the same for all types of vehicles. --Bob K. 19:35, 15 October 2012 (BST)
Ah, it was about turn restrictions! You cannot use conditional restrictions as currently defined for that! I deliberately left out turn restrictions from the scheme since the relations require a very different tagging structure. It might be a good idea to define a conditional scheme for turn relations, however. Probably something like you proposed above (but without any *-defaults!). BTW, why would you need to repeat the restriction for all transportation modes if the value is the same? --polderrunner 20:02, 15 October 2012 (BST)
Thinking about it I would propose to simply use condition=<condition> or condition:<transportation_mode>=<condition>. This should however be discussed on the turn relations wiki, not here. --polderrunner 21:28, 15 October 2012 (BST)

Wrong time format

The Key:opening_hours page specifies time as HH:MM, however, some examples on the page are using H:MM, this is probably not a good idea. -- Eckhart 16:52, 15 October 2012 (BST)
Fixed. Sloppiness from my side. Thanks for informing me. --polderrunner 19:27, 15 October 2012 (BST)

Some pitfalls

Right now, this section is just a place to collect some pitfalls:

Yes, that would be needed, unfortunately. The real problem for this example is probably rather limited. Hgv's in Europe may not exceed 80 km/h anywhere (built-in speed limiters) if I'm right (don't know how it is elsewhere). And the wet tag is a bit controversial anyway. How could an application use it unless it has access to some oracle predicting road wetness at some time into the future? --polderrunner 18:53, 19 October 2012 (BST)
For route planning purposes: weather forecast. For speed warnings: rain sensor of the car – built-in navigation systems normally have (read-only) access to the CAN bus. Also, depends on the vehicle, but some hgv vehicles are definitely allowed to go up to 100 km/h in Germany. -- Eckhart 00:11, 20 October 2012 (BST)

bus vs. tourist_bus

The fifth example is probably wrong: "bus" is defined as "a bus acting as a public service vehicle", "tourist_bus" seems to be correct here. -- Eckhart 12:06, 19 October 2012 (BST)

As I read this example (I didn't add it) it includes everything that can be catagorised as a bus including chartered vehicles like tourist buses. This is in contradiction to the definition at . Since this ambiguity is not specifically related to conditional restrictions I would propose to discuss it elsewhere (e.g. ). --polderrunner 18:39, 19 October 2012 (BST)
I believe the definition at Key:access and Key:bus is a mistake copy-paste error (back in 2009!) from Key:psv; I haven't heard of any country where "buses used as public transport vehicles" would have special restrictions or allowances. A bus, when the vehicle is registered as a bus, is a bus. I'm inclined to believe that virtually, if not totally, all bus=no ways have the "no buses" sign, etc. Maybe somebody is willing to start a (likely long) thread on the tagging list :) Alv 21:19, 19 October 2012 (BST)
Well, at least in Germany this sign allows only buses used for public transport. -- Eckhart 23:55, 19 October 2012 (BST)
That seems to be so. Strangely, though, Zeichen 253 - Verbot für Kraftfahrzeuge mit einem zulässigen Gesamtgewicht, StVO 1992.svg excludes all "Kraftomnibusse", and Zusatzzeichen 1024-14.svg is also plain "Kraftomnibus". I don't see any sign equivalent to Finland road sign 319.svg in the StVO. This means that DE:Road_signs_in_Germany is in part contradictory to what's said on Key:access. Is that De:245 Zeichen 245.svg the sign used above bus lanes, or just on separate bus-only roads? To sort this mess out, we'd optimally need to see in which countries these tags have been used to any reasonable extent, and to find out what the equivalent signs mean in those countries. Alv 16:41, 20 October 2012 (BST)
Many countries follow the Vienna convention for road signs, and Germany perfectly follows this convention too (in short: the blue sign refers to regular buses in the context of lanes, all other bus silhouettes refer to a bus category, Zeichen 253 - Verbot für Kraftfahrzeuge mit einem zulässigen Gesamtgewicht, StVO 1992.svg means "no entry for goods vehicles", which obviously does not apply to busses -- see Talk:Key:access#Bus_has_multiple_meanings).
This issue is that the access tag mixes "use" (bus used as tourist bus, bus used for regular transport...) with the "vehicle category" (IMO the legal registration of the vehicle). A bus vehicle can be a regular bus in the morning and a tourist bus in the evening. PSV is a "use" category and does not link 1:1 to the vehicle hierarchy. In some countries rickshaws may fall into the PSV category, in some taxis, etc. Thus IMO the "by-use" categories tourist_bus and PSV should be taken out of the main hierarchy (and may build up their own hierarchy, and may include "regular_bus"). In countries following the convention then the Zeichen 245.svg can be a "by-use" road sign (only regular bus) with a "by-use" tag, all other road signs with bus silhouettes are "category" road signs using the bus tag.--Martinq 20:42, 21 October 2012 (BST)
In the Netherlands buses acting as public service vehicles typically have exclusive access to bus lanes etc. It is indicated by the word "lijnbus" (bus in line service) on a sign or painted on the surface. A sign just referring to "bus" means all kinds of buses a far as I know. --polderrunner 07:54, 20 October 2012 (BST)
I now tried to start the discussion for a solution at Talk:Key:access#Bus_has_multiple_meanings, with a table of meanings for different countries. Please fill in. Alv 13:09, 21 October 2012 (BST)

One-Time Conditional Restriction or Restriction Change?

The opening_hours syntax doesn't seem to provide a way to specify a year. This means it doesn't appear possible to specify a one-time closure period, or a feature that will permanently gain or lose restriction(s) on a given date. I think on_date and related tags could do that, though I can't seem to find the documentation for those. Will this be addressed? Vid the Kid 23:19, 2 November 2012 (UTC)

Key:opening_hours indeed does not mention how to tag a year or a one-time closure, it is intended for repeated events. I have no clear answers to your question. Start_date and end_date are probably not suitable as they indicate the begin or end of a feature such as construction or demolition dates of a building (not just a changed property). For a restriction that changes permanently on a specific date I would wait until that date and then map the new situation. For a temporary closure of less than a couple of months I prefer not to map it at all as many users don't update their data that frequently. Thus they may never see that closure in their map or they may use the wrong data long time after the closure has ended. A longer lasting closure (several months) should be mapped but remember to 'reopen' it when finished. --polderrunner 09:04, 3 November 2012 (UTC)
The proper solution would be to add years to the "specification", or even better write a formal "time domain" specification. Deducing rules from opening_hours examples is quite hard. -- Eckhart 12:37, 4 November 2012 (UTC)
Btw, I'm currently trying to formalize time domains, feedback welcome. -- Eckhart 14:00, 4 November 2012 (UTC)

Addition: Gross vehicle weight rating

There is a difference between the actual weight of a vehicle and its gross vehicle weight rating. For hgv routing, it is necessary to differentiate between those two:

  1. Gross vehicle weight rating example
  2. actual weight example

I therefore propose to add the vehicle property "grossweight". Example usage (first link): hgv:conditional=no @ (grossweight>7.5) -- Eckhart 10:57, 22 November 2012 (UTC)

Agree, we need this, because the the Convention on road signs defines it (it is called "permissible maximum mass" in the convention): This convention, implemented by many countries in the world, requires a gross weight property in order to tag the road signs correctly:
Any weight value used in connection with a "no entry for goods vehicles", "prohibition of overtaking" and "speed limit" sign - no matter if inscribed or on an additional panel - means "gross weight" when the countries have correctly implemented this convention. Thus:
  • UK traffic sign 622.1A.svg or Vorschriftszeichen 7a Gewicht.svg or the German variant with additional panel means "No entry for goods vehicles with gross weight > X".
  • Speed limit of 60 for HGV with weight more than 7.5t.jpg also applies to HGVs with a GROSS weight > 7.5t only (see convention, annex I, section C, 5.). Thus I probably tagged the example on the conditional restriction main page and some local limits in my areas incorrectly, but the local law is sadly unspecific regarding the meaning of written weight limits on additional panels to speed limits.
    I'm not sure whether this is a German sign, but German law follows the Vienna Convention in this regard. -- Eckhart 18:30, 22 November 2012 (UTC)
    Nevermind, apparently it is an Austrian sign. (Austrian law apparently only defines this sign which specifies gross weight, and the usual weight sign.) -- Eckhart 18:44, 22 November 2012 (UTC)
    I fully agree, but I think your comment belongs to the previous bullet point (with the no goods/no HGV signs). My last senctence was very confusing, thus more structured: I don't know if the Austrian law (StVO) defines a weight value under a speed limit sign as gross weight or just as weight -- see mini-photo. According to the convention the photo should be tagged with maxspeed:hgv:conditional = 60 @ (gross_weight>7.5), but the Austrian StVO (where the picture was made) neither clearly says 'weight' nor 'gross weight'.--Martinq 21:51, 22 November 2012 (UTC)
  • But Vorschriftszeichen 9c.svg refers to the "laden mass" [Article I, (s)], which is the weight of the vehicle, its load, crew and passengers, also known as weight. It actual meaning is defined in the convention as (cite) "No entry for vehicles exceeding X tonnes laden mass". I think there is an agreement that roads with such signs should be tagged with maxweight=*. As correctly pointed out by Eckhart, gross weight is not needed for this type of sign.--Martinq 14:38, 22 November 2012 (UTC)

I started a proposal: Proposed features/gross weight --Martinq (talk) 20:32, 17 June 2013 (UTC)

I believe there is a problem in the current example, because the maxweight=* in this tagging applies to the road (you can not be heavier as this), while the sign is about the max registered weight (gross weight) of the vehicle and is only applying to hgv, it's a variation of hgv=no:
Photo Tagging Interpretation
Maxweight except buses and for loading.jpg maxweight=7.5
maxweight:conditional=none @ delivery
There is a maxweight restriction which is overruled by maxweight:bus (as this includes a more specific transportation mode) and by maxweight:conditional (a conditional restriction of the same transportation type — i.e. none specified — as maxweight=). Therefore, the maximum weight of 7.5 t applies to all vehicles except buses and those loading ('delivery').

this could be tagged as
+ hgv:conditional=yes @ (maxweight<7.5)
+ bus=yes --Dieterdreist (talk) 16:56, 21 February 2017 (UTC)

I think that it's still better to start with the general rule - as shown on the large sign - first and then add the exceptions that are shown on smaller add-on signs. If you want to go into detail about gross and actual weight, then you just need to use the more specific weight tag as described in Martinq's proposal: maxweightrating=7.5; maxweightrating:bus=none; maxweightrating:conditional=none@delivery. --Biff (talk) 21:29, 21 February 2017 (UTC)
Don't know how established this tag is, but our proposal is clearly an advantage over the current tagging in this example. I think you should put it to the front page. The wrong example should be removed. --Dieterdreist (talk) 23:58, 21 February 2017 (UTC)

type of access, depending from time. logic of choosing from different variants

What tags should we use, if access is permissive from 6:00 until 21:00 and private from 21:00 until 6:00? access=permissive + access:conditional=private @ 21:00-06:00 or access=private + access:conditional=permissive @ (06:00-21:00) access=permissive + access:conditional=private @ (21:00-06:00) or access=private + access:conditional=permissive @ (06:00-21:00)? Could, please, someone explain a logic of choosing from these variants? Dinamik 18:39, 25 November 2012 (UTC)

Technically, there is no difference between the two options. Realistically, support for routers will take some time, and you should pick the option with the most appropriate access tag. (In your case, I would probably pick permissive since it applies 15 hours out of 24.)
Also, I would suggest to wrap your time condition in brackets, i.e. access:conditional=private @ (21:00-06:00). -- Eckhart 21:07, 25 November 2012 (UTC)
'Logic': There are no written rules yet, but simply assume that some data users may not read the conditional value --> consequently you should pick the value you would tell a person if you have only one choice. In your case, whould you tell somebody the access is permissive or private? There is no generic answer to this: If there is an alternative route nearby, I may tend to 'permissive', because more people use ways during the day and in the case that the person comes at night, the negative consequences at night are acceptable (just a minor detour). But if there is no alternative route and a big additional walk/drive is required, then I may set 'private'.
If you don't like to decide, there is a third alternative without 'default' value: access:conditional=permissive @ (06:00-21:00);private @ (21:00-06:00). However, due the fact that applications typically assume access=yes if they do not find an access tag (and cannot interpret the conditionals yet), the outcome may be worse than setting access=permissive or access=private...--Martinq 22:13, 25 November 2012 (UTC)

Date format

How do you propose to write date period? Winter closed roads for example. Restrictions for given periods of the year. access:conditional=no @ (****.11.01-****.06.01)

According to opening_hours=* a date interval, for example from December 1 to March 21, is written as (Dec 01-Mar 21). The opening_hours syntax is intended for repeated events and therefore does not define how to indicate a specific year. See also Talk:Conditional_restrictions#One-Time_Conditional_Restriction_or_Restriction_Change.3F above dealing with the same problem. As winter closures usually happen at (almost) the same dates every year I suggest to tag the period without any year. If you include a year you will need to update the period every year anyway. --polderrunner 11:55, 15 December 2012 (UTC)

EV-only access

Charger at this location; note parking restriction sign in background
I ran into a need to tag some parking spaces as permitted for electric vehicles only. By my understanding of the general format of access restrictions, I came up with motor_vehicle:conditional=yes @ (electric=yes), my rationale being that "electric" is a vehicle property (like weight, axles, etc.). The area in question is in the database. —Larry Gilbert 20:15, 28 January 2013 (UTC)

I just realized that the restriction is for "electric vehicle charging" specifically. But maybe that's splitting hairs...? —Larry Gilbert 20:24, 28 January 2013 (UTC)

I think you are touching a subject that is going to be quite important in the future. Parking spaces reserved for ev charging are already getting quite common. But in the future it is not unthinkable that we may see ev-only streets or zones in inner cities. When drafting the conditional restrictions proposal I deliberately left out this kind of vehicle properties as it really deserves a discussion on its own, see Talk:Proposed_features/Conditional_restrictions#Fuel_type_and_emission_conditions.3F.
My immediate suggestion is to use motor_vehicle:conditional=yes @ (fuel=electric) or motor_vehicle:conditional=yes @ (fuel:electric). This may be more flexible than "electric=yes". --polderrunner 21:01, 28 January 2013 (UTC)
Indeed, fuel=electric is probably better, because it could also cover plug-in hybrid vehicles. --Biff (talk) 23:56, 13 December 2013 (UTC)


Why is there only an AND operator defined? Some conditions need an OR operator, too. See for example this help question requiring an OR operator. --Scai (talk) 06:17, 18 June 2013 (UTC)

There's an implicit OR when using the (here, acceptable because it was drafted that way) semicolon notation. It's not clear from the question above whether the asker needs "ice" to be a distinct condition from "snow". If the asker needs this, the logical OR can be written as "access:conditional=no @ ice; no @ snow". --achadwick (talk) 11:44, 18 June 2013 (UTC)
The semicolon is the current way of doing it. Whether applications support it I don't know. My first draft of the conditional proposal actually included the OR operator but it was suggested to drop it for simplification. As I had no good examples justifying the use of OR I left it out of the final proposal. In many cases it can be replaced by an AND by negating a condition (e.g. relative weight or height conditions). In this actual case I find it better to define a common condition for wintry conditions. For example in Germany your vehicle must legally be equiped with winter tyres if you are driving in "wintry" conditions whatever that involves ice, snow or both. --polderrunner (talk) 19:15, 18 June 2013 (UTC)
Personally I find the semicolon solution somewhat confusing. Take for example other tag combinations like amenity=restaurant;cafe. Almost always a semicolon is interpreted as an AND and not as an OR. But you suggest to use it as an OR in this special case. I suggest to not use the semicolon at all for conditional restrictions and instead define two separate AND and OR operators to reduce confusion. --Scai (talk) 06:30, 20 June 2013 (UTC)
';' is not an "operator", it is an enumeration (in the conditional as well as in your example). For enumerations spoken language uses "and" and "or" interchangable: "You cannot access on snowy conditions AND you cannot cannot access on icy conditions" means the same as "You cannot access on snowy conditions OR you cannot cannot access on icy conditions" - or expressed as conditional: no @ ice; no @ snow.--Martinq (talk) 07:40, 20 June 2013 (UTC)
Re-reading Conditional restrictions#Evaluation of conflicting restrictions, you're quite correct. There is no short-cut evaluation possible here, and nor is ";" a logical OR. Each term must be evaluated in turn, and one should use the access value given by the final match. It's quite clear when I actually read the page ☺ --achadwick (talk) 10:49, 20 June 2013 (UTC)

It's still unclear to me whether "ice" (which I'd define as "likelihood of encountering frozen surface water") really needs to be a distinct category from "snow" (which I'd define as "deep or drifting snow" primarily, but might it be confused with "trodden snow"?); but that's bias coming from my living in a temperate country. Can anyone with better knowledge provide a concrete use case where either "ice" or "snow" is considered as something more specific than "generic adverse wintry conditions" as noted above? Not merely from legislature, but from signage, skiing piste information, ... ? --achadwick (talk) 10:49, 20 June 2013 (UTC)

Weather conditions: distinct or not?

Resolved: "wet" and "snow" do not refer to weather, just the road surface.

We currently document road conditions on the main page (Conditional restrictions#Condition), but not weather-based conditions. Do we need them, or are keywords like "wet" to read as "wet roads, significantly affecting traction" as well as "when monsoon downpours significantly affect visibility"?

Tabulating precisely what is meant by each current condition keyword would be a good idea.

--achadwick (talk) 12:30, 18 June 2013 (UTC)

The "wet" condition clearly refers to wet road surface affecting traction, at least in western European countries. I think weather conditions like poor visibility are not relevant to OSM tagging as they don't normally concern individual roads but are globally defined in the traffic code of the particular country. --polderrunner (talk) 19:25, 18 June 2013 (UTC)
They might be signposted in some places; we cannot rule that out. For now, let's agree that "wet" and "snow" do not refer to weather, just the road surface.
If anyone needs to add weather conditions as distinct tests, I'd suggest keywords of raining, snowing, fog etc., and to discuss it here.
--achadwick (talk) 09:57, 20 June 2013 (UTC)

School zones

How are we going to specify whether a road's speed limit is affected by its proximity to a school? There are too many variables to lay down a restriction of that kind within the framework that is set up now. -- DENelson83 (talk) 03:05, 30 September 2013 (UTC)

There are different types of school zones, thus you have to be more specific:
  • Just warnings, e.g. Ontario Wc-1.svg
  • Combination with speed limit including time limitation (or implying a time by law, e.g. 8am - 5pm) and typically also just valid on school days (example: New South Wales R4-230.svg or Ontario Rb-6.svg) -- or
  • School zones with a controlled signal like Ontario Rb-106A.svg or Delaware S5-3-DE.svg or even LED/electronic road/maxspeed signs?
The variants with the controlled signal (flashing light - Ontario Rb-106A.svg) cannot be tagged with the conditionals yet, but there is a proposal maxspeed:variable=school_zone. It is however not capable to tag the reduced speed limit during school hours.
For the time and school day limited variants Ontario Rb-6.svg you can already use conditionals together with the opening_hours definition, typically it will look like maxspeed:conditional=40 @ (Mo-Fr 08:00-17:00;PH off;SH off) (assuming that a school day is Monday to Friday except if is a school holiday or a public holiday). Yes, could be simpler.
So, what is your request?--Martinq (talk) 20:58, 30 September 2013 (UTC)
You've made my point exactly. All of those need to be taken into account. -- DENelson83 (talk) 07:32, 3 October 2013 (UTC)

Tide dependant access

Access to some places and roads might depend on the tide. Here's an example of such info available for boat ramps: [1]

Instead of using tags like tidal=* or highway=tidal_road it's probably better to indicate conditional access, especially in combination with tags like highway=* and leisure=slipway.


  • access=tidal, not useful for automatic routing, but as long as more detailed info is not available, this is still better than just assuming access=no or access=yes.
  • access=no + access:conditional=yes @ ((hightide-05:00)-(hightide+05:00)), e.g. for boat ramp that is accessible from 5 hours before until 5 hours after high tide. This could even be used for automatic routing, if the router knows the tide table (e.g. [2]).
  • access=no + access:conditional=yes @ ((lowtide-02:00)-(lowtide+02:00)), e.g. for road that is accessible from 2 hours before until 2 hours after low tide.

Additionally, it's probably a good idea to add a description=* which explains the situation.

What do you think?

--Biff (talk) 23:52, 13 December 2013 (UTC)

I'm not sure that a conditional tag is better. At least I would propose to reverse the restriction to access:conditional=no @ ((hightide-02:00)-(hightide+02:00)). A routing engine is very unlikely to be able to evaluate this condition such that the restriction will never turn out to be valid. In other words the default access=yes will apply which I find better when the feature is accessible (you may have to wait for the water to retreat if you arrive at the wrong time but eventually you can get through). In your examples the resultant access will always be no which is not very useful for a routing engine. A free text 'description=*' is probably better in this case. On the other hand I don't like the use of highway=tidal_road as this conflicts with the normal highway classification tagging, such as unclassified or tertiary. Here is one example using highway=tidal_road illustrating the problem, see [3] (enable the 'Humanitarian' layer to see the roads). I prefer the simple tidal=yes. This is sufficient for a render to indicate the tidal property with an appropriate style. --polderrunner (talk) 17:28, 14 December 2013 (UTC)
Hi Polderrunner, thanks for your answer. Let me try to sort this out:
  • tidal=yes is useful for rendering, but will not help for routing.
  • The default access=no needs to be avoided because existing routing engines that are not aware of hightide and lowtide could be confused. However, I suppose that access:conditional=yes @ ((hightide-02:00)-(hightide+02:00)), while not leading to any useful output, should at least not confuse them, as long as no default access information is provided. Routing engines that are aware of hightide and lowtide could be smart and calculate access times even without default info.
  • As long as we don't have smart routers, human readable info needs to be provided by a description tag.
  • (Discussion about highway=tidal_road should take place on the corresponding talk page.)
--Biff (talk) 01:35, 15 December 2013 (UTC)
The main problem is that routers will have to be REALLY smart to use such conditions. Somehow they need to know the tide table for the location or being able to calculate it from some provided tide constant and astronomical data. Considering that such tidal restrictions are rather uncommon I just don't see any router designer making the effort to implement something quite complex to solve a rare problem. Furthermore, there may not be any precise rules for accessibility since tides vary a lot depending on lunar phase and the weather. For the example I gave above there are no strict rules. Drivers need in advance to consult a forecast for the local tide such as provided by a national weather office (a website=* tag might be useful). --polderrunner (talk) 15:52, 15 December 2013 (UTC)

Conditionals with Month restrictions

I don't see any information about conditional restrictions based on months. I am noticed this due to JOSM throwing an validation error on the River Cam, which has a motorboat restriction between March and November.

I'm guessing the tagging on the river is correct, but I think the main conditional restrictions page could do with a note about month formats and have an example...

--Ozhiker2 (talk) 12:45, 7 August 2014 (UTC)

There is actually one example "(Jan-Mar)" given for Time and Date conditions but it may not be very obvious in the text. The reference for time conditions is opening_hours=*. Your example actually seems to be correct. Maybe "motorboat" is not recognised as a valid transportation mode (which it of course is). --opani (talk) 15:26, 7 August 2014 (UTC)

Adding Lanes iteration to Conditional_restrictions#Evaluation_of_conflicting_restrictions?

How does Lanes access restriction fit in with conditional restrictions and their evaluation? There aren't any examples documented on that page, but that doesn't mean it doesn't/shouldn't support them.

[4] is a real world example. How would it be tagged, if it should be supported at all? My best guess...

 motor_vehicle:lanes:conditional=no @ (Mo-Fr 05:00-09:00,15:00-19:00)|yes|yes|yes
 hov:lanes:conditional=designated @ (Mo-Fr 05:00-09:00,15:00-19:00)|yes|yes|yes
 bus:lanes:conditional=designated @ (Mo-Fr 05:00-09:00,15:00-19:00)|yes|yes|yes

Thoughts? (If this should be supported, an example like the above probably should be on the Lanes page (linking to Conditional Restrictions), and a note about evaluation order of lanes be put into the Conditional_restrictions#Evaluation_of_conflicting_restrictions section... Skybunny (talk) 07:09, 4 October 2014 (UTC)

I deliberately left out lanes support in the "conditional restrictions" proposal in order not to complicate matters. Your extension proposal looks like the right way to go. However, I have one big objection concerning the syntax. The condition should be common for all lanes, not per lane as you propose. Otherwise, the latter values are not covered by a condition and unconditional values should not be present in the conditional tag. I seriously doubt that we need per lane conditions. Thus this is my recommended syntax: bus:lanes:conditional=designated|yes|yes|yes @ (Mo-Fr 05:00-09:00,15:00-19:00).
Furthermore, you really don't need the three unconditional tags as these are the obvious defaults for a motorway. --opani (talk) 18:14, 6 October 2014 (UTC)
As for the topic whether the condition should be common for all lanes: Logically, the key *:lanes:conditional would indicate a single condition for all lanes, whereas the key *:conditional:lanes would indicate one conditional value per lane. --Tordanik 10:48, 7 October 2014 (UTC)

"Does not apply to: Turn restrictions"

I don't see why such restrictions exists. It is limitation of minor routers rather intended feature. Please clarify how this is wrong or if there any pitfalls. Xxzme (talk) 22:38, 30 April 2015 (UTC)

The problem I see is that there's no documented method of using Conditional restrictions on relations, which are required for turn restrictions. If someone knows how to model something like "No left turn, Monday to Friday, 12:00 to 18:00" using Conditional restrictions on a turn restriction relation, I'd be very interested and would love to see that added to this article. As it's written now, however, it doesn't seem like this is possible. If it isn't possible, then that needs to be stated over on the Turn restriction article. That article currently points here and says you can do it, but there's no indication over here of how or if it's even possible; rather, this article says it isn't.--Alester (talk) 23:38, 30 April 2015 (UTC)
I don't see need in this, it is well explained in Conditional_restrictions#Examples. There nothing new here, just tag Relation:restriction with access=no or more appropriate transport mode (access=*) with Conditional restriction after @: access=no @ Mo-Fr in real opening hours=* format. Xxzme (talk) 01:49, 1 May 2015 (UTC)
Actually, I think it would be better to use the turn=* tag as the basis of the conditional restrictions. So the above example would be
 turn:conditional = no_left_turn @ (Mo-Fr 12:00-18:00)
As far as I can see, this would work for all applications of Conditional restrictions, and would be a logical application of the normal rules. --Tordanik 13:32, 1 May 2015 (UTC)

Mode of transport

I recently found some that some ways are tagged with conditional restrictions based on the mode of transport - somewhat like xxx:conditional=yyy@(bus). However, using modes of transport as a condition is not documented and is also unnecessarily complicated. In my opinion, it would be better to use the format xxx:bus=yyy. Any comments? --Biff (talk) 18:58, 28 June 2016 (UTC)

Using xxx:bus=yyy is indeed the documented way to do it, see Conditional_restrictions#Transportation_mode. Keep in mind that it's a special case for mode of transport, though, everything else needs to go into the value. --Tordanik 07:12, 29 June 2016 (UTC)

Use of parenthesis

I see a lot of parenthesis used in the examples, yet the documentation does not mention them even once. When are they required? When not? What should they contain? --Pbb (talk) 22:37, 6 November 2016 (UTC)

Hi Pbb, the documentation does mention them:
  • Time and date: Use the standard syntax of the value * of the opening_hours=* tag. If that value includes semicolons (";"), that condition must be enclosed by brackets, e.g. (Mo-Fr 07:00-19:00), (sunrise-sunset) or (Jan-Mar). (The examples don't contain a semicolon???)
  • Except for very simple conditions like "wet" or "Su" it is recommended to enclose the condition in brackets. (Does "recommended" mean that they are optional?)
So the paranthesis are only needed around a condition which contains one or more semicolons because otherwise each semicolon would indicate the start of a new condition. The text should be improved to provide a clear requirement for this, the fuzzy recommendation is not helpful. It would also be better to use the precise terms for brackets "[ ]" and paranthesis "( )". --Biff (talk) 23:06, 6 November 2016 (UTC)
Thanks, I didn't realize brackets could also mean parenteses! --Pbb (talk) 22:09, 8 November 2016 (UTC)