Proposed features/Extended conditions for access tags

Extended conditions for access tags
Status:	Proposed (under way)
Proposed by:	Tordanik
Tagging:	<basekey>:<condition_1>:...:<condition_n>=*
Applies to:	*
Definition:	an access tag only applies if all conditions are fulfilled
Rendered as:
Draft start:	2009-03-07
RFC start:	2009-07-09
Vote start:
Vote end:

This proposal presents the idea of adding conditions to existing keys (such as maxspeed, access ...). A tag with conditions will only have an effect if all conditions are valid. Something like this is necessary to describe many traffic restrictions encountered in reality.

The proposal is an extension of the older Conditions for access tags proposal and adds some missing features.

Contents 1 General idea 2 Possible conditions 2.1 vehicle category 2.2 road condition 2.3 lighting condition 2.4 direction 2.5 vehicle properties 2.6 time 3 Examples 4 Usage and evaluation details 4.1 Evaluating "conflicting" tags 4.2 Way direction dependency 5 Debate 5.1 Comments 5.2 Syntax Poll 5.3 Voting 6 See also

General idea

Conditions are appended after the base key. Conditions are separated from the base key and each other using colons (":"). In a few situations, the conditions themselves can contain colons, too - round brackets are then used to enclose that condition.

Possible conditions

vehicle category

Examples include:

• hgv - heavy goods vehicles
• motorcycle - motorbikes
• (many others...)

Any vehicle category (as listed on Key:access) is a possible condition. The access tag is then only valid for vehicles from that category.

road condition

• wet - access tag is only valid when the road is wet

lighting condition

• night - access tag is only valid at night (in darkness)

direction

• forward - access tag is only valid in way direction
• backward - access tag is only valid against way direction

(Note that this is different from lane-specific information: There are ways with direction-dependent restrictions that do not have multiple lanes. There also can be multiple lanes for each direction.)

vehicle properties

• weight
• axleload
• height
• width
• length
• draught

The following operators are used:

• > greater than
• < less than

The comparison values are given in the same way as values for maxweight, maxaxleload etc. Therefore, numeric values default to SI units (metres for lengths, tonnes for weights).

time

An access tag can be restricted to certain time intervals by using a time interval string as defined for opening_hours. The time syntax itself is not part of this proposal - it is considered desirable to use the same syntax as existing tags.

As times often contain colons (to separate hours from minutes), they will often require round brackets around the time condition.

Examples

Tagging (colons)	Interpretation
maxspeed = 100 maxspeed:hgv = 60	Maxspeed is 100 km/h for most vehicles, but 60 km/h for hgv traffic.
maxspeed = 120 maxspeed:wet = 80	Maxspeed is 120 km/h under normal conditions, but 80 km/h when the road is wet.
bicycle = yes bicycle:(10:00-18:00) = no	Bicycles are permitted to use this street outside 10AM-6PM.
access:weight>5.5 = destination	Vehicles over 5.5t are only allowed for destination traffic.
maxspeed:hgv = 120 maxspeed:hgv:Sa,Su = 80	Maxspeed for hgv is limited to 80 on weekends, but 120 otherwise.
maxspeed = 50 maxspeed:(Mo-Fr 07:00-17:00) = 30	Maxspeed limited to 30 on 7AM-5PM weekdays, but 50 otherwise.

Usage and evaluation details

Evaluating "conflicting" tags

1. More specific information overrides more general information. (For example, on a wet road, maxspeed:wet overrides maxspeed; maxspeed:wet:hgv overrides both maxspeed:wet and maxspeed:hgv for hgv.)
2. If there are conflicting tags without a "specificness" hierarchy, the most restrictive rule (e.g. lowest maxspeed) is to be chosen.

Way direction dependency

The following tags affected by this proposal depend on way direction:

• tags with ":forward" or ":backward" as part of the key
• tags starting with direction-dependent base keys (e.g. "oneway:...")

Editors should include those tags in their way reversal safety checks.

Debate

Comments

Please use the talk page.

Syntax Poll

See Talk:Proposed features/Extended conditions for access tags#Syntax Poll (Archived)

Comment by proposal author: In response to a suggestion on one of the mailing lists, a poll was held whether it would be preferable to switch syntax to angle brackets instead of the colons that had be used in the predecessor proposal. However, only few people participated (compared with the original proposal and considering that the colon variant is already being used), so I decided to stick with the low-risk option: colons.

Voting

Not yet started.

See also

• Conditions for access tags: original proposal
• Proposal for lane-tagging, which could also profit from conditional tags in case of reversibles