Talk:Conditional restrictions

From OpenStreetMap Wiki
Jump to navigation Jump to 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)

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.svg excludes all "Kraftomnibusse", and Zusatzzeichen 1024-14.svg is also plain "Kraftomnibus". I don't see any sign equivalent to Linja-autolla ajo kielletty 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.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)

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)
The current example has IMO a completely different syntax than the general accepted. And also needs two tags. Why not
accessːconditional=destination @ (maxweight>7.5) --Karussell (talk) 11:13, 25 April 2018 (UTC)
Note that we have Key:maxweightrating that seems clearly superior. Mateusz Konieczny (talk) 05:28, 23 September 2020 (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)
opening hours syntax allows to specify year but maybe specific example would be nice... Mateusz Konieczny (talk) 05:29, 23 September 2020 (UTC)

The page currently contains the example example motor_vehicle:conditional=no @ (2018 May 22-2018 Oct 7) but it is not explained or supported by any links. As this is not a seasonally recurring period, but one fixed period in specific years, why do we not use the same syntax (2018-05-22) here as elsewhere? Martianfreeloader (talk) 18:09, 21 March 2023 (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)

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)
My request would be some kind of shorthand for times that the nearby school is open like: school_open or school_time. Besides speed limits we also have school playground access restrictions when school is in session.--Rassilon (talk) 21:21, 16 February 2020 (UTC)

School days should have their own form. Because that's what the sign says. The sign doesn't say public holidays. Jidanni (talk) 20:45, 20 November 2022 (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)
I am creating a project to map ciclovías in Bogotá, Colombia, where normal car highways are blocked to only allow cyclists and pedestrians just in Sundays mornings - I need conditions per lane, but these suffixes are generating warnings in JOSM validator. This is what I am using:
 highway=secondary, oneway=yes, lanes=3
 vehicle:lanes:conditional=no|no|designated @ (Su 07:00-13:00)
 bicycle:lanes:conditional=yes|yes|designated @ (Su 07:00-13:00)
 foot:lanes:conditional=yes|yes|designated @ (Su 07:00-13:00)
 oneway:lanes:conditional=no|no|yes @ (Su 07:00-13:00)
Can I ignore them? How else can I map this? Thank you.
--AngocA (talk) 18:18, 7 February 2022 (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)
Added this example --Planemad/Talk 11:51, 11 August 2017 (UTC)
Mateusz Konieczny (talk) 06:09, 20 October 2020 (UTC)

"Except bicycles" on conditional turn restriction?

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

Why it would deprecate this? Mateusz Konieczny (talk) 06:09, 20 October 2020 (UTC)

Construction without known end date

I have a construction site which causes the ways to have only 2 instead 3 lanes. Also there is no parking ATM. I think :conditional is the right tool for the job. I am thinking about: - changing the default tags to represent the current state - adding :conditional versions of the tag to show the post-construction state So lane=3 becomes lane=2+lane:conditional=3 @ (condition). And so on. This way all data consumers will have the currently correct data. Does that make sense so far?

My next issue is, that I don't know the end date of the construction site. So I could only write something like ":conditional=3 @ (construction finished)". What is the best way to handle this? --Tordans (talk) 12:26, 20 April 2019 (UTC)

Odd-Even Road Restriction in Indonesia

Hello, I'd like to ask how to apply the following "Odd-Even Vehicle License Plate" restrictions in OpenStreetMap

The latest (8/15/2019) iteration of this restriction is described as follows:

  • Only odd-numbered vehicles may be allowed to pass certain roads on odd-numbered dates (e.g. January 25, May 15)
  • Only even-numbered vehicles may be allowed to pass certain roads on even-numbered dates (e.g. April 2, July 18)
  • This (odd/even number) is detected by finding the last numerical digit of the vehicle license plate. For instance, "B 1234 XX" will be determined as even-numbered ("4")
  • Restrictions are applied from 06:00 - 10:00 as well as 16:00 - 20:00, with exemptions/exclusions on weekends and public holidays
  • Emergency (firefighter trucks, ambulances), government (national and regional) officials, public transport, regular taxi vehicles (non ride-hailing app drivers) as well as motorbikes/motorcycles are also exempted/excluded from this restriction.

This restriction is currently effective on major (primary and secondary) roads in Jakarta, with plans to extend this regulation to other cities as well as toll roads / expressways. Some of these roads connects with Jakarta's renown POIs, including but not limited to:

  • National Monument (Monas): Jalan Medan Merdeka Barat, Jalan M.H. Thamrin, Jalan Majapahit, Jalan Hayam Wuruk, Jalan Gajah Mada
  • Kota Tua (Jakarta's heritage city) and Jakarta Kota Train Station: Jalan Pintu Besar Selatan, Jalan Hayam Wuruk, Jalan Gajah Mada
  • National Museum (Museum Nasional): Jalan M.H. Thamrin
  • Welcome Monument (Tugu Selamat Datang), also known as "HI" Roundabout/Ramp (Bundaran HI / Hotel Indonesia): Jalan Jend. Sudirman, Jalan M.H. Thamrin
  • Gelora Bung Karno (GBK) stadium and sports complex; Jakarta Convention Center (JCC): Jalan Jend. Sudirman, Jalan Gatot Subroto
  • Jakarta International Expo (JIEXPO) and Jakarta Fair: Jalan Benyamin Sueb
  • Pondok Indah Golf Course (2018 Asian Games venue): Jalan Metro Pondok Indah

At the time of this writing, only Google Maps and Waze who have implemented this feature. The UX of both apps requires users to enter the last two numerical digits (though the second last is not significant to the restriction regulations) and the app will notify if the path the users would like to navigate passes through restricted roads.

There are no signs from HERE maps (HERE WeGo) on implementing this feature. It's nice to see this implemented in OSM clients.

Reinhart Previano (talk) 01:24, 15 August 2019 (UTC)

self-contradictory example

oneway=yes + oneway:backward:conditional=yes @ (Mo-Fr 07:00-10:00) is in my opinion a poor example.

It claims to describe "For a road that is primarily a oneway, which temporarily allows traffic in the opposite direction on Monday through Friday." but it actually describes case where at the same time road is oneway in both directions!

If oneway direction is reversed it should be

oneway=yes + oneway:conditional=-1 @ (Mo-Fr 07:00-10:00)

If traffic in both directions is allowed at once

oneway=yes + oneway:conditional=no @ (Mo-Fr 07:00-10:00)

Mateusz Konieczny (talk) 20:42, 17 October 2019 (UTC)

I agree. Moreover, the first occurence on the page incorrectly suggested that oneway is a "condition" when it is in fact a "restriction type". I've simply removed that bit.
However, the two oneway examples in the "Example" table have the same error and were added during the same edit, so these should also be corrected. We could either ask one of the mappers on the ground which of the two interpretations is actually the correct one (the OSM database entry should be corrected, too), or just remove the examples. --Tordanik 22:44, 4 November 2019 (UTC)

negated conditions

I am trying to fix the access conditions on trails on my family's property. The conditions are nordic skiing and hiking only, but the hiking is restricted to when there is no snow. How can I put in a no-snow restriction for hiking?

The alternative would be to disallow hiking during any month that there could be snow but that would be too restrictive.

Peter F. Patel-Schneider (talk) 01:39, 1 January 2020 (UTC)

I think
should do the trick? --Tordanik 22:45, 19 January 2020 (UTC)

Parking restrictions

Parking restrictions in Gothenburg, Sweden

What would be the appropriate tagging for this sign? Parking is not allowed on Tuesdays between 09 and 12, if it is an even week between March 15th and April 30th. --Ojan (talk) 21:08, 3 August 2020 (UTC)

@Ojan: "if it is an even week between March 15th and April 30th" - what you mean by "even week"? Mateusz Konieczny (talk) 05:22, 23 September 2020 (UTC)

Based on the calendar for 2021 this means that parking restriction apply in calendar weeks 12/14/16. A few hours on even/odd days rather than weeks are very popular restrictions in Sweden in order to clear the side of a road for cleaning. Such a case has been discussed on Talk:Key:opening_hours#odd.2Feven_dates and would lead to something like parking:condition=no @ Mar 15-Apr 30 week 2-52/2 Tu 09:00-12:00 for the displayed image (no guarantees here for the exact syntax) Michael63 (talk) 12:15, 3 September 2021 (UTC)

@Ojan and Michael63: parking:condition=* predates the conditional restriction syntax and is incompatible with it. There is an ongoing effort to rework the tagging scheme to use conditional restriction syntax, but it would use the conditional subkey, not condition. – Minh Nguyễn 💬 18:36, 3 September 2021 (UTC)

Tagging free/paid parking depending on stay time

How one may tag fee paid "only if more than 2h".


fee=yes fee:conditional=no @ (time < 2h)

or (defaulting to no)

fee=no fee:conditional=yes @ (time > 2h)

? Mateusz Konieczny (talk) 06:16, 20 October 2020 (UTC)

As we discussed on Telegram group - looking at taginfo, it seems that maxstay is better suited here. So, it can look like: fee=yes fee:conditional=no @ (maxstay < 2h). I might propose this to mailing list
--Stalker (talk) 09:24, 20 October 2020 (UTC)
Just to update that this page now shows to use fee:conditional=no @ (stay < 2 hours) and stay now seems more popular than maxstay as a condition on taginfo.TrekClimbing (talk) 13:36, 11 March 2023 (UTC)

hazmat and emergency - transportation mode / by use

I think we will need to distinguish between hazmat=* and access:conditional=* @ (hazmat) such that the former applies to a vehicle designed to carry hazmat, and the latter is a by-use condition only applies to those vehicles actually carrying hazmat in it. The same distinction should be applied with disabled and emergency as well (i.e. a vehicle designed for the purpose and actually used for that purpose, e.g. an ambulance and an ambulance transferring emergency cases with flash and siren on). Miklcct (talk) 05:48, 12 February 2021 (UTC)

Documenting Example Values


I was documenting a type of conditional speed limit I hadn't mapped before ( for the record) and I wasn't sure how to tag the value consistently with other mappers. Would there be an interest or value in documenting the non-obvious values (ie, not date and times) in the wiki? Diacritic (talk) 18:33, 7 February 2022 (UTC)

Prefer to use :conditional for the least restrictive condition?

One can always map a conditional restriction exactly as the sign says, or prefer to set the main tag to the less or more restrictive side of the condition. For example, the following conditions are equivalent:

  1. vehicle=destination + vehicle:conditional=yes @ (Mo-Fr 09:00-17:00; PH off)
  2. vehicle=yes + vehicle:conditional=destination @ (Mo-Fr 00:00-09:00,17:00-24:00; Sa,Su,PH 00:00-24:00)

Both are rendered the same and treated the same in routing software that support conditional restrictions. But some software don't, especially offline (relatively simple and lightweight) navigation software, and in this case deciding between the above two makes a practical difference for some. Of course, this doesn't have to apply only to vehicles, but these are usually the most affected users. Thinking about helping the user avoid being fined, I tend to think that preferring to set the most restrictive case in the main tag is better. Maybe so if the restriction applies most of the time or most of, say, business hours, when transit is more likely. What do you think? --Fernando Trebien (talk) 13:07, 5 August 2022 (UTC)

I've encountered a similar issues, specifically with a pedestrian way which allow bicycles at night. It is tagged with bicycle=yes and bicycle:conditional=no @ (09:00-21:00) (It is in a pedestrian zone where bicycles are allowed, and this tagging matches the signage). However this is not very helpful, as bicycling is forbidden during the times when most would want to use it! To make matters worse, routers will happily route a user down this way. We shouldn't tag for the router, but I think tagging the most useful (or most restrictive information as you suggest) makes a lot of sense.
A counterexample is a park pathway which is closed at night. I don't think in this case we should tag the most restrictive information (access=no), but again tag the most useful information. --Popball (talk) 17:49, 26 September 2022 (UTC)
As the approval of this proposal was 10 years ago, I'm asking myself if we should still think about how to best support data consumers not supporting this or if we should do what feels more natural (tag what is on the sign) and don't worry about other people's problems. -- Discostu36 (talk) 15:55, 2 December 2022 (UTC)
Is there support beyond OsmAnd? The two routers at the main website do not support, and implementation does not seem to have started (GraphHopper #374, OSRM #4231). --Fernando Trebien (talk) 12:29, 10 December 2022 (UTC)

permit or permit_holder?

We have the documented value access=permit, but the otherwise undocumented value permit_holder appears in two examples here. If there is no meaningful difference between the two, should this be aligned with access, or both values accepted? --Rskedgell (talk) 12:52, 27 December 2022 (UTC)

*:conditional=* @ (permit_holder) is the original condition suggested in Proposed_features/Conditional_restrictions. You can check *:conditional=* @ (permit is now the most numerous by several pages over , after Proposed features/access=permit is proposed, or maybe because it is shorter.
A fundamental problem is there is no standardization on conditions, or it is intentionally left out. This situation seems to have some overlap with quoted freeform text comment syntax in opening_hours=* from time conditions.
--- Kovposch (talk) 09:24, 28 December 2022 (UTC)

Simpler syntax for delivery restrictions

Please see


Just documented them Rtfm (talk) 18:14, 28 January 2023 (UTC)

No, they are not the same. How do you know what delivery:conditional=* is used for? delivery=* is used for a business offering deliveries. access=delivery and *:conditional=* @ (delivery) are legal restrictions and conditions. --- Kovposch (talk) 08:31, 29 January 2023 (UTC)
I checked taginfo and found they use the "conditional" syntax (yes @...). I also checked taginfo for "delivery allowed for less than 7.5 tonnes" and it seems there's a lot of confusion about the correct ("traditional") syntax. The combination above seems much easier to me (unless you need two tags to express it, generally I prefer the "all in one" tags). Is there any tool to check the correct syntax similar to the one for opening hours ? Rtfm (talk) 18:02, 29 January 2023 (UTC)
There are already 7 maxweight:conditional=7.5@(05:00-10:00 AND delivery) though? 28 maxweight:conditional=8 @ delivery. Equivalent syntax do exist. I listed some cases in Conditional_restrictions#Vehicle_dimension.
Other examples implying motor_vehicle:conditional=delivery @ (weight < 7.5):
maxweight:conditional=* is simpler.
JOSM's validator has some defects that causes false warnings.
Truncated edit:
But are you suggesting delivery=* as a mode besides goods=*?
What is "delivery vehicle" then??? This doesn't explain help US "commercial vehicle" either. private=*, customers=*, permit:*=* are used to explain access=private, access=customers, access=permit, not replace them.
--- Kovposch (talk) 09:15, 30 January 2023 (UTC)

Mixing alternative condition types for one restriction value

I wasn't sure whether it is acceptable to mix condition types that fit a value within parentheses. For example, parking that is free for the first hour or for customers. Are either/both of the following acceptable (combined with fee=yes)?

both of these forms (and a version with OR) are present on taginfo. TrekClimbing (talk) 15:48, 11 March 2023 (UTC)