Proposed features/Advanced access tags
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 is no documented tagging scheme that is widely accepted. Many proposals have been suggested, but none yet approved. 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 it's most complex. The examples may be theoretical only.
As a reminder of terminology, a Tag consists of 'Key' and a 'Value' pair (key=value). For example "maxspeed=80".
List of proposals
'Conditional Restrictions' proposal approved|
The 'Conditional Restrictions' proposal was approved by vote on 1st October 2012. For more information please see the Conditional Restrictions wiki page.
The following proposals, listed in alphabetic order, have been found on this wiki:
- Access restrictions 1.5
- Conditional restrictions
- Conditional values
- Conditions for access tags
- Extended conditions for access tags
- Simplified conditional restrictions language
Overview of each proposal
Access restrictions 1.5
Status: RFC start: 2011-04-26
- "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."
<restriction-type>[:<transportation mode>][:<direction>]:conditional=<restriction-value> @ <condition>[;<restriction-value> @ <condition>] - where fields in square brackets [..] are optional.
motor_vehicle:conditional=no @ (10:00-18:00 AND length>5)
Status: Approved: 2012-10-01
- "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."
<a_key>:cond = <a_value> <a_condition>
maxspeed:cond = 80 if vehicle is a hgv and weight>7.5t
Status: Draft start: 2012-04-08
- "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)"
Status: RFC start: 2009-01-28, but now Abandoned (inactive).
- "This proposal has been superseded by the Extended conditions for access tags proposal."
Status: RFC start: 2012-08-10 (following voting on an earlier iteration closed - 18 oppose, 9 approve)
- "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."
Status: Draft start: 2009-01-16
- "This proposal has been obsoleted by Proposed features/Conditions for access tags and Proposed features/Extended conditions for access tags.
Simplified conditional restrictions language
Schema: not explicitly documented, but see examples
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)
- "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#"