Conditional restrictions

Restrictions (such as access=private or maxspeed=60) sometimes exist only when certain conditions are met. Those conditions can be described using "conditional tags".

Overview

Conditional tags are usually used with a normal, unconditional restriction tag. The normal tag is taken to be valid normally, and the conditions specified are exceptions to the normal rule.

1. First tag the normal rule.
2. Then use a conditional tag to tag the exception.

Conditional tags are built as follows:

1. Create a conditional key by adding the suffix :conditional to what would be the normal key
2. Add the exceptional value after the conditional key
3. Describe the conditions in which the exceptional value is to be taken using @ followed by the condition.

Basic examples

Time periods

Exceptions are often determined by times or time periods.

• A chapel is private most of the year, but is open to the public on Christmas day:

access=private (normal tag)

access:conditional=yes @ Dec 25 (conditional tag)

• A section of motorway has a normal speed limit of 100 km/h, reduced to 60 km/h between 23:00 and 5:00:

maxspeed=100 (normal tag)

maxspeed:conditional=60 @ 23:00-05:00 (conditional tag)

Special cases

Where the exception is determined by transport mode, the transport mode is added to the key as a suffix.

• A street is one way to most traffic, but bikes can travel in both directions:

oneway=yes (normal tag)

oneway:bicycle=no (conditional tag)

Where the normal rule is implied, a normal tag is not needed.

• A default national speed limit applies to all vehicles, except HGVs are limited to 80km/h:

maxspeed:hgv=80 (conditional tag)

Additionally, access restrictions determined by transport mode should be tagged without the expected prefix access: , because this term is implied.

• A road is open to all traffic except HGVs:

access:hgv=no (conditional tag)

Tagging: full scheme

The general syntax of the tag is as follows (fields in square brackets [..] are optional):

 <restriction-type> [: <transportation mode> ][: <direction> ]:conditional
 =  <restriction-value>  @  <condition>  [;<restriction-value> @ <condition>] 

In access tags that are specific to a specific mode of transport, the expected restriction-type prefix access: is omitted (as it is in normal tags).

 <transportation mode> [: <direction> ]:conditional
 =  <restriction-value>  @  <condition>  [;<restriction-value> @ <condition>] 

Key

The key is constructed in the same way as keys for established restriction tags with an additional :conditional suffix.

Restriction type

The  <restriction-type>  can be any type of restriction that may have conditional validity. Common examples are access=*, maxspeed=*, oneway=* and maxstay=* restrictions. The restriction type should reflect the "main" traffic sign. For the File:Vorschriftszeichen 1.svg sign, having an additional sign specifying a condition the type should be vehicle. On the other hand, for the sign File:Nederlands verkeersbord C17.svg, the restriction type should be maxlength (similar for other max<dimension> signs).

Transportation mode

The  <transportation mode>  key-part specifies the transportation mode to which the restriction applies, e.g. bicycle, motor_vehicle, foot, agricultural, ....

Example: vehicle:conditional=*

Direction

The  <direction>  key-part can be used when a restriction is direction-dependent. Use forward and backward to indicate in which direction the restriction applies. The value depends on the direction in which the way is drawn in OpenStreetMap. For guidance on how to identify this in your editor, see the description of the terms "forward", "backward", "left", and "right".

Value

The value comprises the conditional restriction itself, followed by the @ character, followed by the condition. Add spaces before and after the @ character to improve readability.

Mostly just one value with a corresponding condition is specified. In exceptional cases, it may be necessary to use two or more value–condition pairs. Such value–condition pairs should be separated by a semicolon. One situation may be a certain speed limit at certain times of day but a different (lower) speed limit in case of wet conditions. See § conflicting restrictions below how to order multiple value-condition pairs.

permit_holder was originally proposed. permit is now more numerous, but be very careful in interpreting them. The meaning of UK's "except permit" (restricted to, e.g., residents and tenants, closer to access=private) supplementary plate doesn't have the same definition as access=permit (almost always granted to everyone as part of the procedure of travelling) in OSM.

Restriction value

The  <restriction-value>  is the actual value of the restriction; e.g. yes, private, 80, 55 mph, 2 hours. The restriction can be absolute (yes, no, permissive and other values that apply to everybody), according to the purpose of the highway use (destination, delivery, customers, forestry, agricultural, etc.) or according to an explicit permission (private, permit).

Note that, although the condition may sometimes be in parentheses, the restriction value never is. For example, bus:lanes:conditional=yes|designated @ Mo-Fr 07:00-09:00 is syntactically correct, but bus:lanes:conditional=(yes|designated) @ Mo-Fr 07:00-09:00 is incorrect, since (yes|designated) is an invalid value for bus:lanes=*.

Condition

The  <condition>  field specifies the condition for which the restriction applies. Conditions may include a semicolon, ;, and where they do must be enclosed with parentheses, (). It is suggested, by some, to simply do this always.

Various kinds of conditions can be distinguished:

• Time and date: Use the standard opening hours syntax. Note the common occurrence of semicolons; e.g. (Mo 06:00-24:00; Tu-Fr 00:00-24:00; Sa 00:00-13:00), Mo-Fr 07:00-19:00, sunrise-sunset, or Jan-Mar.

  Comments, to be presented to the user directly, are allowed and should be written in local language. For example, "rowing events" and Mo-Fr 06:00-10:00,15:00-19:00 "bij grote verkeersdrukte". In the latter, the condition may apply within the specified time windows, but it certainly does not outside of them.

• Time of year: e.g. winter or summer which are not covered by the opening hours specification. Only use when the specific dates are not known or change each year. Notably used for speed limits on some roads in Finland where the dates of winter speed limits change each year. See Key:maxspeed:conditional for more details.
• Road condition: For example, wet, snow. It is noted that the condition wet corresponds to :wet in, e.g., maxspeed:wet=*. Using wet as a condition is recommended in order to streamline the syntax of restriction tags ("maxspeed:wet" was introduced at a time when no proper way of tagging conditional restrictions existed).
• Vehicle property: Some examples of properties are weight, axleload, length, width, height, wheels and draught (for ships). Use relative operators (<, >, =, <=, >=) to define the condition. E.g. weight<7.5.
• Vehicle usage: The restriction depends on how the vehicle is used, such as the number of occupants or the load. Examples: (occupants>1) (a typical condition for a vehicle to use an "hov" lane), hazmat (vehicle carrying hazardous materials).
• User group: The restriction relates to a specific user group, e.g. doctor, disabled, emergency, female.
• Purpose of access: For restriction types expecting a numerical restriction value such as maxweight the condition may be a purpose-of-access condition (destination, delivery etc) or a permission type condition (private, permit etc). Example:

  maxweight=2.5

  maxweight:conditional=none @ destination.

• Stay duration: The restriction depends on how long vehicle remains at the location, such as time parked. Use stay for stay duration. Examples: (stay < 2 hours) (where stay duration is less than 2 hours).
• Combined condition: Two or more partial conditions may be combined using the operator AND. It is recommended to use the uppercase form to improve readability. AND means that both partial conditions must be fulfilled for the condition to apply. Example: destination @ Sa-Su AND weight>7.

Default restrictions

It is not always clear which restriction applies when the condition is not fulfilled. In such cases the default restriction should also be specified; e.g., maxspeed=120 + maxspeed:conditional=100 @ 20:00-06:00. In some cases, a default restriction can be assumed and need not be explicitly tagged. For many highway classes like "unclassified", an implicit access=yes is assumed. See OSM tags for routing/Access-Restrictions for default access restrictions for different highway classes. However that may be, when using conditional tag, it is recommended to mark the default value in overt form in all cases.

Evaluation of conflicting restrictions

When an object has two or more different restrictions both matching the given traffic and conditions, the following algorithm determines which one is valid.

1. A restriction having a more specific transportation mode overrules a less specific transportation mode. E.g., a tag for "psv" overrules a tag for "motor_vehicle" in case of a public service vehicle. See Key:access#Transport mode restrictions for the transport mode hierarchy.
2. A directional restriction overrules a non-directional restriction of the same transportation mode
3. A conditional restriction overrules a non-conditional restriction of the same transportation mode and direction
4. A Lanes restriction, evaluated per-lane, overrules a restriction of the same transportation mode (whether conditional or directional)
5. A conditional lanes restriction, evaluated per-lane, overrules a non-conditional lanes restriction
6. In case of multiple matching value-condition pairs in the same tag the last matching value becomes the effective restriction value. Therefore it is important to put the more general restriction first and the more specific restriction last. Some examples:
   • (access=yes) + access:conditional=no @ 09:00-17:00; destination @ 09:00-17:00 AND disabled will allow destination traffic for disabled persons (the last match) while all other traffic isn't allowed 9am-5pm. The time condition needs to be repeated in the second value, otherwise disabled persons would only have destination access 17:00-09:00 while all other traffic would have general access.
   • (maxspeed=none) + maxspeed:conditional=120 @ 06:00-20:00; 80 @ wet: Here the 80 at wet will overrule the time based restriction in case of wet conditions.
   • (access=no) + access:conditional=delivery @ 07:00-11:00; customers @ 07:00-17:00: Here is actually no conflict as only one value can match (the purpose of access must match in case of destination, customers, delivery, agricultural and forestry).

Exceptions

• Parking lane restrictions formerly defined its own way of dealing with conditions but has now been harmonized with this tagging scheme.

Examples

Speed limit

Main article: Key:maxspeed:conditional

Traffic modes

Vehicle dimension

Travel direction

Pricing

Durations

User groups

Turn restrictions

Destination restriction signage

Main article: Destination restriction indications

Conditional syntax may be used, if necessary, for destination symbols prewarning about remote access restrictions or recommendations.

Deprecated tags

This scheme deprecates the following tags when they are used in combination with restriction tags.

By-use modes

The present scheme treats the by-use modes hov=*, emergency=*, hazmat=* and disabled=* as conditions, not as transportation modes. This will allow more complex restrictions like access:conditional=destination @ (hazmat:A AND weight>7.5). It is recommended to tag such by-use modes as real conditions instead of using pseudo-transportation modes although such tagging is not explicitly deprecated with this scheme.

Other conditionals

Over the years, some conditional keys have emerged, that don't describe a restriction, for example:

• interval:conditional=*
• duration:conditional=*
• cycleway:left:conditional=*
• traffic_sign:conditional=*
• route:conditional=*

Software support

Routers

OsmAnd's support for conditional restrictions can be activated in the navigation settings menu.

OSRM's support for time-conditional restrictions requires running a script to specialize the data set for a given evaluation time and load it into the server. In principle, a public server could be configured to automatically run this script at frequent intervals so that a query submitted at a given time has restrictions evaluated at approximately the same time. This is extra work, so some public servers may not implement it and thus may ignore time-conditional restrictions. As of 2025-09-05, the OSRM server used by openstreetmap.org appeared to ignore time-conditional restrictions in one test. Of course, if you're running your own OSRM server for testing, you can run the script as many times as you want to test evaluation times of your choosing.

Renderers

CyclOSM does render conditional access restrictions next to affected roads or paths at zoom level 20 (example). Access restrictions on nodes are not rendered.

CityParkingWeb renders conditional access and fee tags on parking lots/lanes.

See also

• Proposed features/Conditional restrictions: The approved proposal.
• Proposed features/temporary (conditional): For roads closed due to temporary construction etc.
• Sophox query returning inputs to conditional turn restrictions

References