|Característica : Restricciones condicionales|
|Para etiquetar restricciones que dependen de una condición.|
|Conditional restrictions: puede tener carencias, errores no corregidos o partes que todavía no han sido traducidas.
Si comprendes el artículo original en inglés, por favor, ayuda a completar esta traducción al español. Lee las instrucciones sobre cómo traducir este wiki.
Parece que nadie está trabajando en la traducción en este momento. Anímate y colabora en la tarea de traducción.
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 may 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 lower speed limit of 60 kph applicable between 06:00 and 20:00. According to the present scheme, this example may be tagged as maxspeed:conditional=60 @ (06:00-20:00).
The tagging scheme described here explains how to add conditional restrictions to OpenStreetMap.
- 1 Tagging
- 2 Default restrictions
- 3 Evaluation of conflicting restrictions
- 4 Deprecated tags
- 5 Does not apply to:
- 6 Examples
- 7 See also
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>]
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 access. 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 allowed 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.
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, customer, forestry, agricultural etc.) or according to an explicit permission (private, permit_holder).
This field specifies the condition for which the restriction is valid. Various kinds of conditions can be distinguished.
- Time and date: Use the standard syntax of the value * of the opening_hours=* tag. If that value includes semicolons (";"), that condition must be enclosed by round brackets (parentheses), e.g. (Mo-Fr 07:00-19:00), (sunrise-sunset) or (Jan-Mar).
- 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 etc). Example:
Except for very simple conditions like "wet" or "Su" it is recommended to enclose the condition in round brackets.
Combined conditions: AND
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 access:conditional=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); customer @ (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, customer, delivery, agricultural and forestry).
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.
Does not apply to:
- Parking lane restrictions as the parking lane scheme has defined its own way of dealing with conditions.
maxspeed:conditional=120 @ (06:00-19:00)
|Maxspeed limited to 120 km/h 6–19 h but 130 km/h 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).|
||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.|
|access:conditional=destination @ (weight>5.5)||Vehicles over 5.5t are only allowed for destination traffic.|
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').|
|motor_vehicle:conditional=no @ (10:00-18:00 AND length>5)||Motor vehicles longer than 5 meter not allowed 10am - 6pm|
||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|
|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)|
| oneway:conditional=yes @ Su
||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'.|
Example for a conditional speed limit applicable to a specific transportation mode.
- Proposed_features/Conditional_restrictions: The approved proposal.