|Feature : Conditional restrictions|
|To tag restrictions being dependent on a condition.|
This article describes how to tag restrictions being dependent on a condition.
Simple unconditional restriction tags such as access=private or maxspeed=60 are widely used to tag basic restrictions like a 60 kph speed limit. If the restriction only applies to a certain vehicle category (or transportation mode), the tag key can be extended by appending this information to the key. Examples include oneway:bicycle=no and maxspeed:hgv=80. The transportation mode should be used on its own in the key for an access restriction that applies only to that transportation mode. For example, use hgv=no instead of access:hgv=no.
In some cases, restrictions are only valid when certain conditions are fulfilled. An example may be a different speed limit of 60 kph applicable between 23:00 and 5:00. According to the present scheme, this example may be tagged as maxspeed:conditional=60 @ 23:00-05:00. This would override say maxspeed=50, in effect stating that maximum allowed speed is 50, but between 23:00 and 5:00 it is raised to 60.
The tagging scheme described here explains how to add conditional restrictions to OpenStreetMap.
The scheme uses the same syntax as that used for normal unconditional restriction tags with the following differences: The key ends with the suffix
:conditional. The value comprises the actual value followed by the character '@' and the condition.
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 limited to a specific transportation mode the restriction-type access: is usually omitted.
<transportation mode>[:<direction>]:conditional = <restriction-value> @ <condition>[;<restriction-value> @ <condition>]
Using this tagging it is possible to tag both the typical state and one that is triggered only in some situations. It allows to fully tag a given situation and keep basic tags easy to process.
The key is constructed in the same way as keys for established restriction tags with an additional :conditional suffix.
This can be any type of restriction that may have conditional validity. Common examples are access=*, maxspeed=* and oneway=* restrictions. The restriction type should reflect the "main" traffic sign. For the sign, having an additional sign specifying a condition the type should be vehicle. On the other hand, for the sign , the restriction type should be maxlength (similar for other max<dimension> signs).
This key-part specifies the vehicle category or transportation mode to which the restriction applies, e.g. bicycle, motor_vehicle, foot, agricultural. For access restrictions, it is common practice to use the abbreviated form by omitting access: in front of the category, e.g. motorcar instead of access:motorcar. Please note that the value agricultural designates the type of vehicle (typically tractors or special machines having a low maximum speed), not the purpose of the highway use.
See Key:access#Transport mode restrictions for the full transportation mode hierarchy.
Some restrictions are 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".
The value comprises the actual restriction followed by the @ character and 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 the US-originated access=permit (almost always granted to everyone as part of the procedure of travelling) in OSM.
This is the actual value of the restriction; e.g. yes, private, 80, 55 mph. 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).
This 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:
- 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.
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.
- 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.
- A directional restriction overrules a non-directional restriction of the same transportation mode
- A conditional restriction overrules a non-conditional restriction of the same transportation mode and direction
- A Lanes restriction, evaluated per-lane, overrules a restriction of the same transportation mode (whether conditional or directional)
- A conditional lanes restriction, evaluated per-lane, overrules a non-conditional lanes restriction
- 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).
- Parking lane restrictions formerly defined its own way of dealing with conditions but has now been harmonized with this tagging scheme.
See more details and examples at Key:maxspeed:conditional.
maxspeed:conditional=130 @ 19:00-06:00
The speed is limited to 120 km/h from 6 AM to 7 PM, but the default of 130 km/h applies otherwise (example from Dutch motorway).
maxspeed:conditional=120 @ 06:00-20:00; 100 @ 22:00-06:00
|Two conditional maxspeed values valid at different times of day (this is a real example from a motorway in Germany).|
maxspeed:conditional=none @ 20:00-22:00; 100 @ 22:00-06:00
|Two conditional maxspeed values valid at different times of day (this is a real example from a motorway in Germany).|
maxspeed:hgv:conditional=60 @ weight>7.5
|Example for a conditional speed limit applicable to a specific transportation mode.|
|Complex example from a Dutch pedestrian street. Delivery traffic ("bevoorradingsverkeer") allowed access at certain time intervals. Bicycles ("fietsen") are allowed except on Saturdays 8–16 h. Mofas and mopeds ("snor- en bromfietsen") not allowed.|
|motor_vehicle:conditional=no @ 2018 May 22-2018 Oct 7||Section of road is closed for motor vehicles for a few months (for construction). Navigation after the end date should work even for maps created in the meantime. (See also temporary:*=*)|
|motorcycle:conditional=no @ (Sa,Su,PH)||Motorcycles not allowed on weekends and public holidays|
|This is a camera-enforced "bus gate"; motor vehicles are prohibited from 07:30 to 18:30 except for PSVs. Times need to be switched around (against as they appear on the sign) if you want to use motor_vehicle=no as a fallback. (Note: "local buses" not handled yet)|
|Motorcycles are only allowed on this trail June 1st through October 1st.|
|access:conditional=destination @ weight>5.5||Only destination traffic is allowed for over 5.5t.|
|motor_vehicle:conditional=destination @ weight>5.5||Motorized Vehicles over 5.5t are only allowed for destination traffic.|
|Only destination traffic allowed for weight of over 5.5t.|
maxweightrating:conditional=none @ delivery
|There is a maxweightrating restriction which is overruled by maxweightrating:bus (as this includes a more specific transportation mode) and by maxweightrating:conditional (a conditional restriction of the same transportation type — i.e. none specified — as maxweightrating=). Therefore, the maximum weight rating of 7.5 t applies to all vehicles except buses and those loading ('delivery').|
maxweightrating:hgv:conditional=none @ delivery
|Note the sign only applies to heavy goods vehicles so this could be solved this way.|
|motor_vehicle:conditional=no @ 10:00-18:00 AND length>5||Motorized vehicles longer than 5 metre not allowed 10am - 6pm|
|maxlength:conditional=5 @ 10:00-18:00||Longer than 5 metre not allowed 10am - 6pm|
|Longer than 5 metre not allowed 10am - 6pm|
|hgv:conditional=no @ 06:00-22:00 AND weight>5||This is a vehicle specific time and weight restriction for HGVs|
|maxweight:hgv:conditional=5 @ 06:00-22:00||This is a vehicle specific time and weight restriction for HGVs|
|This is a vehicle specific time and weight restriction for HGVs|
|The sign translates as: (No motor vehicles). Does not apply to vehicles longer than 14 m.|
|Street is oneway on Sundays but bicycles may use it in both directions at all times. The second tag overrules the conditional tag because of the specific transportation mode 'bicycle'.|
|This road is a oneway by default. It temporarily allows traffic in the opposite direction on Monday through Friday.|
|For a road that is a oneway active on weekends (Sa-Su) and public holidays (PH)|
|For a road that is a oneway active during weekdays (Mo-Fr) except public holidays (PH)|
|oneway:conditional=-1 @ 17:00-20:00; yes @ 06:00-08:00||This road is bidirectional by default. It is a oneway from 6-8 AM in the direction drawn and a oneway in the reverse direction from 5-8 PM.|
|This road is a oneway by default. It is bidirectional from 2-9 PM on weekdays (Mo-Fr) and 7-10 AM on weekends (Sa-Su) and public holidays (PH).|
|overtaking:hgv:conditional=no @ Mo-Fr 06:00-19:00||Overtaking not permitted for heavy goods vehicles 6–19h on weekdays (example from Dutch motorway)|
|Parking where you are not paying for stay lasting no more than 2 hours|
|Parking where you are not paying for stay lasting no more than 2 hours. The same meaning as previous, but with different default (makes difference as conditional restrictions is not always processed - it is better to put safer/less surprising value in a default).|
|For an object with a free entrance/use on Mondays - in this case a museum but may apply for example to a parking.|
|Parking where you're allowed to stay only 90 minutes, except on Sunday and public holidays when you're not allowed to stay at all|
|Parking where you're allowed to stay only 90 minutes, except on Sunday and public holidays when there is no limit|
|Based on||female=no||For an object where woman are generally not allowed, except some specific days during a year.|
restriction:conditional=no_left_turn @ length > 6
|restriction:conditional=no_right_turn @ (Mo-Fr;PH off)||For a road that is a no right turn except weekends (Sa-Su) and public holidays (PH)|
|type=restriction||This is a conditional turn restriction that prevents vehicles except mopeds, motorcycles, mofas from making a U-turn from 06:00-22:00.|
This scheme deprecates the following tags when they are used in combination with restriction tags.
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.
Over the years, some conditional keys have emerged, that don't describe a restriction, for example:
Support by data users
OsmAnd does support conditional speed limits in the Netherlands since version 1.6 in 2013. Support for speed limits with time range condition, conditional lanes and access restrictions was added in 2019. It can be activated in the navigation settings menu.
- 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