Overview of conditional access proposals
Access restrictions are used to limit use of highway, amenity or other map feature. Usage could be limited to a sub-group of users (for example, vehicles under 12 meters in length), or a set of specified rules (for example a maximum speed of 80 km/h). Simple restrictions can be easily tagged in OpenStreetMap using existing tagging schemes. Examples include access=*, maxweight=*, maxlength=*, maxspeed=*, and many more...
For more complex restrictions, such as a maximum weight restriction that only applies between 6am and 10pm, there was no widely accepted and documented tagging scheme until Conditional restrictions was approved. Many proposals have been suggested. This wiki page helps to highlight and summarise the existing proposals in a simple way. Any tag examples shown are taken from each proposal respective page and are intended to illustrate the tags schema at its most complex. The examples may be theoretical only. The proposals are listed in alphabetical order.
As a reminder of terminology, a tag consists of 'Key' and a 'Value' pair (key=value). For example "maxspeed=80".
Access restrictions 1.5
Schema: access:<mode>+<property>&&<role>?<condition>.<modifier>=*
Example: access:car+trailer&&customer?wet.maxspeed=30
Status: RFC start: 2011-04-26
Quotes:
- "The goal should be to bring some structure and naming conventions to the current access tags and values and handle special cases a bit better than right now. That's why it has the version number 1.5 and not 2.0".
- "Clean separation between the kind of transportation (vehicle), user roles and access values"
- "There will be situations where the predefined conditions won't be enough. That is why you can also define your own. To define a condition use "!" instead of "?" and append the modifier, which should act as a condition, plus a value."
Read more and/or discuss...
Conditional restrictions
Schema: <restriction-type>[:<transportation mode>][:<direction>]:conditional=<restriction-value> @ <condition>[;<restriction-value> @ <condition>] - where fields in square brackets [..] are optional.
Example: motor_vehicle:conditional=no @ (10:00-18:00 AND length>5)
Status: Approved: 2012-10-01
Quotes:
- "This proposal overcomes some objections to previous attempts at tagging conditional restrictions"
- "No variable parts in the key."
- "Clear distinction between scope (transportation mode, vehicle class) and condition. "
- "The conditional restriction can be defined as a single tag. Some prior proposals required multiple tags such as hour_on and hour_off tags."
- "The syntax of the key is essentially identical to the established access key syntax with an additional qualifier ":conditional"."
- "Backward compatible. Doesn't break any established tagging schemes."
Read more and/or discuss...
Conditional values
Schema: <a_key>:cond = <a_value> <a_condition>
Example: maxspeed:cond = 80 if vehicle is a hgv and weight>7.5t
Status: obsoleted
Quotes:
- "No weird programming language type syntax: If a mapper reads a sign "80 km/h for HGV>7.5t, 22:00-07:00", mapping should be as close as possible to that."
- "The syntax/grammar allows several variants, from 'close to natural language' (avoiding a technical touch, but rather 'bulky') to more technical, but shorter expressions"
- "The new approach clearly separates the attributes of the mapped objects from the circumstances of use and generalizes them for use in any arbitrary condition and not just for a special tagging group (like access or parking conditions)"
Read more and/or discuss...
Conditions for access tags
Status: abandoned
Quotes:
- "This proposal has been superseded by the Extended conditions for access tags proposal."
Read more and/or discuss...
Extended conditions for access tags
Schema: <basekey>:<condition_1>:...:<condition_n>=*
Example: maxspeed:hgv:(Sa,Su)=80
Status: rejected - RFC start: 2012-08-10 (following voting on an earlier iteration closed - 18 oppose, 9 approve)
Quotes:
- "Conditions are appended after the base key. Conditions are separated from the base key and each other using colons (":")."
- "Brackets around conditions should be used to improve readability or to avoid ambiguities."
- "For compatibility reasons, the "access" base key can be omitted if it is followed by a transportation category: access:hgv=* and hgv=* are considered equal."
Read more and/or discuss...
Modifiers for access tags
Schema: <basekey>:<modifiers>=*
Example: access:hgv=destination
Status: obsoleted - draft start: 2009-01-16
Quotes:
- "This proposal has been obsoleted by Proposed features/Conditions for access tags and Proposed features/Extended conditions for access tags.
Read more and/or discuss...
Simplified conditional restrictions language
Schema: not explicitly documented, but see examples
Example: condition1=wet and maxspeed:lgv=120 or 80 if condition1 - note is short "condition1" value can be placed directly in access rule tag"
Status: Unknown (last edited June 2012)
Quotes:
- "The variable part (like speed limit or date or time) has to be on the value part of the tag"
- "We create the following new keywords which would enable a new "simplified conditinal restrictions language" (SCRL) parser: and, or, not, if,condition#"
Read more and/or discuss...