Proposal:Conditional restrictions

The Feature Page for the approved proposal Conditional restrictions is located at Conditional_restrictions

Conditional restrictions
Proposal status:	Approved (active)
Proposed by:	polderrunner
Tagging:	`*:conditional=(value) @ (condition)`
Applies to:	Restriction tags
Definition:	Tagging of conditional restrictions (e.g. only valid at certain times)
Statistics:
Rendered as:	none
Draft started:	2012-07-28
RFC start:	2012-08-14
Vote start:	2012-09-16
Vote end:	2012-10-01

Sometimes restrictions are only valid when certain conditions are fulfilled. Examples may be cars not allowed on Sundays or a lower maxspeed applicable between 6:00 and 20:00. Currently there is no well-established scheme for tagging such conditional restrictions.

This proposal overcomes some objections to previous attempts at tagging conditional restrictions.

No variable parts in the key. This is essential as keys are used to search for data in the OSM database. If a key comprises a variable part it can no longer be retrieved during search unless you know the exact condition you are looking for (database searches do not allow wildcards in search keys). Variable parts in keys will also lead to an undesired proliferation of unique keys.
Avoids the requirement for problematic characters in the key such as "<" or ">", see Any_tags_you_like#Characters
Clear distinction between scope (transportation mode, vehicle class) and condition.
Possibility to combine conditions using operators.
The conditional restriction can be defined as a single tag. Some prior proposals required multiple tags such as hour_on and hour_off tags. For objects having multiple restrictions this could lead to problems (which tags belong to which restriction?)
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.

Tagging

The general syntax of the tag is:

<restriction-type>[:<transportation mode>][:<direction>]:conditional=<restriction-value> @ <condition>[;<restriction-value> @ <condition>]

(fields in square brackets [..] are optional).

Key

The key is constructed in the same way as keys for established restriction tags with an additional :conditional suffix.

Restriction type

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 this sign having an additional sign specifying a condition the type should be access. On the other hand for this sign the restriction type should be maxlength (similar for other max<dimension> signs).

Transportation mode

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 for the full transportation mode hierarchy. However, this proposal differs in one respect from the established transportation mode hierarchy of the access tag. The "By use" modes (hov, emergency, hazmat, disabled) are considered to be true conditions and as such should be used in the values, not in the key.

Direction

Some restrictions are direction dependent. Use forward and backward to indicate in which direction the restriction applies.

Value

The value comprises the actual restriction (e.g. "no") followed by the @ character and the condition. Add spaces before and after the @ character to improve readability.

Normally just one value with a corresponding condition is specified. In exceptional cases it may be necessary to use two or more values. Such value-condition pairs should be separated by a semi-colon. 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.

Restriction-value

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).

Condition

This field specifies the condition for which the restriction is valid. Various kinds of conditions can be distinguished.

Time: Use the standard syntax of the Opening hours tag. If the time condition includes the character ";" the condition must be enclosed by brackets. E.g. (Mo-Fr 7:00-19:00) or (sunrise-sunset).
Road condition: E.g. wet
Vehicle property: Some examples of properties are weight, axleload, length, width, height and draught. 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. E.g. (occupants>2) or hazmat.
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, customer, agriculture, forestry) or permission type condition (private, permit_holder). Example: maxweight=2.5 + maxweight:conditional=none @ destination.

Except for very simple conditions like "wet" or "Su" it is recommended to enclose the condition in 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)

Default restrictions

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 Access restrictions for default access restrictions to different highway classes.

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 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
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 @ (9:00-17:00); destination @ (9: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-9: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 @ (7:00-11:00); customer @ (7: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).

Examples

Tagging	Interpretation
`maxspeed=120` `maxspeed:conditional=80 @ wet`	Maxspeed is 120 km/h under normal conditions, but 80 km/h when the road is wet.
`maxspeed=50` `maxspeed:conditional=30 @ (Mo-Fr 07:00-17:00)`	Maxspeed limited to 30 on 7am - 5pm weekdays, but 50 otherwise.
`maxspeed=none` `maxspeed:conditional=120 @ (6:00-20:00); 100 @ (22:00-6:00)`	Two conditional maxspeed values valid at different times of day (this example apparently exists in real somewhere in Germany).
`bicycle=yes` `bicycle:conditional=no @ (10:00-18:00)`	Bicycles are permitted to use this street outside 10am-6pm.
`access:conditional=destination @ (weight>5.5)`	Vehicles over 5.5t are only allowed for destination traffic.
`motor_vehicle:conditional=no @ (10:00-18:00 AND length>5)`	Vehicles longer than 5 meter not allowed 10am - 6pm
`overtaking:hgv:conditional=no @ (6:00-9:00, 15:00-18:00)`	Overtaking not permitted for heavy goods vehicles during rush hours
`oneway:conditional=yes @ Su` `oneway:bicycle=no`	Street is oneway on Sundays but bicycles may use it in both directions at all times.

Comments

Please use Talk:Proposed_features/Conditional_restrictions for this.

Voting

The voting has ended. The proposal has been approved with 27 votes in favour and 9 votes against.

I approve this proposal. --polderrunner 22:54, 16 September 2012 (BST)
I approve this proposal. --Imagic 05:11, 17 September 2012 (BST)
I oppose this proposal. Compared to the Extended Conditions proposal, this proposal

breaks a lot of tags which came "natural" to the mappers, e.g. maxspeed:wet=80 becomes maxspeed:conditional=80 @ wet, access:disabled=yes becomes access:conditional=yes @ disabled, …

No-one deprecates this old scheme. --Surly 10:15, 18 September 2012 (BST)

creates arbitrary distinctions: depending on whether something is defined to be a transportation mode or a condition, it belongs either in the key or in the value, e.g. "hgv" is a transportation mode, but "hazmat" is a condition
has bad editor support: adding a conditional restriction like "speed limited to 80 when wet" to a set of ways is quite complicated if there are already different restrictions on those ways; merging :conditional tags in JOSM by default produces a value that is completely wrong, yet cannot be identified as wrong. -- Eckhart 07:14, 17 September 2012 (BST)

I approve this proposal. ----MetiorErgoSum 09:04, 17 September 2012 (BST)
I approve this proposal. SunCobalt 10:31, 17 September 2012 (BST)
I approve this proposal. -- Errt 11:23, 17 September 2012 (BST)
I approve this proposal. -- Mondschein 11:55, 17 September 2012 (BST)
I have comments but abstain from voting on this proposal. Tag proposals and voting on the wiki are unrepresentative of the wider OSM community and work against the intent of OSM as an open database. However this is perhaps the cleanest way of representing these data, and it passes some real world test cases I've gathered which I consider moderately complex without being too syntactically horrid. Treat that as a tacit approval if you need to argue the toss against any competing schemes with numeric values stuffed into keys. --achadwick 13:01, 17 September 2012 (BST)

Thanks for the link to the childcare proposal. Worth reading and another proof that voting is usually not working here. --Imagic 16:21, 17 September 2012 (BST)

I don't agree with you that proposals are working against the intent of OSM as an open database. Voting might have little love in the community, but proposals are important to document stuff. It is very important to intend the same meaning when using the same tags (but it isn't important to use the same tags to describe the same stuff/aspects, although it is desirable to do so in order to facilitate use of the data).--Dieterdreist 11:40, 18 September 2012 (BST)

I approve this proposal. First proposal I see that's kind of intuitive, well readable for humans and scales well with complexity (== only creates a mess in the values if the situation really deserves it). -- Chaos99 14:51, 17 September 2012 (BST)
I approve this proposal. -- friep 16:04, 17 September 2012 (BST)
I oppose this proposal. It's to difficult for users, not intuitive. There are too many subkeys and subvalues. I think value with logic instruction (AND/OR) (and maybe special/new signs (@)) are not good tagging rules. --MasiMaster 16:10, 17 September 2012 (BST)
I approve this proposal. --Eimai 17:26, 17 September 2012 (BST)
I approve this proposal. --Surly 10:15, 18 September 2012 (BST)
I approve this proposal. --Dieterdreist 11:40, 18 September 2012 (BST)
I approve this proposal. --Lovwyr 16:57, 18 September 2012 (BST)
I approve this proposal. --Fabi2 19:05, 18 September 2012 (BST)
I approve this proposal. Foxxi59 20:57, 18 September 2012 (BST)
I approve this proposal. --RobJN 22:12, 18 September 2012 (BST)
I approve this proposal. --Jokoala 23:43, 18 September 2012 (BST)
I oppose this proposal. It is not intuitive, tags are log and unwieldy. --trig222 23:49, 18 September 2012 (BST)
I oppose this proposal. More than one way to tag same things (overtaking:hgv:conditional=no @ (6:00-9:00, 15:00-18:00) and overtaking:conditional=no @ ((6:00-9:00, 15:00-18:00) AND hgv)). This includes alternation to already exist tags like maxspeed:wet.

Also subtagging is not good (but not critical).--Scondo 06:31, 19 September 2012 (BST)

The second version is NOT supported by this proposal. Transportation modes cannot be used as conditions. Further, don't use nested brackets, they are not necessary. Concerning wet. The proposal doesn't deprecate any established tagging but in this case offers an alternative. --polderrunner 07:27, 19 September 2012 (BST)

And alternative (for wet, for hgv or for anything else) is bad. And I can't understand do I need nested brackets or not.--Scondo 12:58, 19 September 2012 (BST)

I approve this proposal. --PeterRounce 09:07, 19 September 2012 (BST)
I approve this proposal. While it is not the most beautiful or mapper-friendly tagging scheme I've seen, it appear flexible enough to capture most types of restrictions, and seems to be the best of the proposals that I've seen for doing so. It will be a step forward to have this standardised scheme. --Rjw62 14:06, 19 September 2012 (BST)
I approve this proposal. --Wambacher 15:12, 19 September 2012 (BST)
I approve this proposal. --It looks great with the condition for the value in the "value"-part of the tag and not in the "key"-part. @ looks quite right, even if unconvential here.Johan Jönsson 19:53, 19 September 2012 (BST)
I have comments but abstain from voting on this proposal. ...or rather I recoil in horror at this proposal. You really are turning OSM tagging into a programming language. Tags are supposed to be simple! But at the same time, I've never been bothered to map such a nutty level of detail so maybe I should stay out of it. -- Harry Wood 23:20, 19 September 2012 (BST)
I approve this proposal. Streele 11:30, 20 September 2012 (BST)
I oppose this proposal. Because old tagging-scheme would be invalid p.e. maxspeed:wet=* --Efred 11:56, 20 September 2012 (BST)
I oppose this proposal. Seem to be a joke?! You can use the @-sign in your personal SMS or something like that but not in combination with official datas (except e-mail-addresses of course).--R-michael 08:07, 21 September 2012 (BST)

This comment seems to be a joke! There's nothing wrong with the @ character, it's a widely used, standard (even ASCII) character that predates email by centuries and it fits here perfectly, being a clear visual seperator and meaningful in its written out form 'at'. --Errt 14:46, 25 September 2012 (BST)

I approve this proposal. David. S 10:27, 21 September 2012 (BST)
I like this proposal. Tagging such complicated restrictions will never be easy anyway. This is the most human readable proposal I've seen so far. It is important that tags can be interpreted quickly and unambiguously by humans. Computers can do their job anyway and are less important than contributors. I'm still not sure if is 100% backward compatible with old, traditional keys which is also very important. --Pieren 22:17, 21 September 2012 (BST)
I oppose this proposal. This would cause too much typing effort. "conditional" should at least be abbreviated to "cond". But it would be more to the point to omit it completely. Instead of <maxspeed=120 + maxspeed:conditional=80 @ wet>, <maxspeed=120; 80@wet> would suffice. --Fkv 20:22, 23 September 2012 (BST)

As a long term plan that would be nice, but for now we still need the ":conditional" part in order to maintain backwards compatibility.--RobJN 20:31, 23 September 2012 (BST)

So you think that changing the tagging scheme once breaks backwards compatibility, but changing it twice won't? --Fkv 21:15, 23 September 2012 (BST)

No. I gave my opinion of what would be "nice". If this was a business rather than a community project you would assess the pros and cons of dropping the ":conditional" part. The biggest con would be that it breaks backwards compatibility as there are many data users that do not expect to find two or more values within the maxspeed= tag. If you deem the benefits to outweigh the costs then you alert your stakeholders of the forthcoming change via a "Request for Change (RFC)". You give them plenty of advance warning so that when the RFC goes "live" their systems are able to cope. In reality this is very very unlikely to happen given the structure under which OSM and it's users operate (and the fact that the benefits aren't that big). --RobJN 23:21, 23 September 2012 (BST)

This would be true if all values in the database would change at once. But it actually starts with 0 values with the new syntax, so the impact will initially also be zero. And don't forget that few OSM applications today use those maxspeed etc. values at all. We are primarily talking about future uses here. --Fkv 08:11, 24 September 2012 (BST)

There has been so much debating about this issue, it's clear we can't push something now that breaks compatibility.

This is just wrong, see my previous statement. You are completely ignoring facts. --Fkv 08:08, 29 September 2012 (BST)

Once the schema is widely used and applications are used to it, changing the key is less of a problem as it does need small adaptions in code only, not rather major changes.

--Errt 14:46, 25 September 2012 (BST)

Changing the code is easy. The problem is that it needs to be done. This will be a bigger issue in the future, when it will affect many more applications. Therefore, lousy interim solutions often turn out to become permanent. --Fkv 08:08, 29 September 2012 (BST)

I approve this proposal. --unixasket 15:42, 25 September 2012 (CEST)
I approve this proposal. Eriks Zelenka 11:14, 28 September 2012 (UTC)
I oppose this proposal. Way too complicated: I'm going to avoid further tagging of such features if this scheme will be approved and adopted --Al3xius 12:18, 28 September 2012 (BST)
I oppose this proposal. Sorry, I like the concept but the application is too complicated both for the mapper adding the tags and also for anyone querying the database. You'll need a degree in Regular Expressions to access any data. Instead of complex entries in one tag a sensible structure of multiple tags is required. bigfatfrog67
I approve this proposal. --higa4 04:11, 30 September 2012 (BST)
I approve this proposal. This proposal is a good compromise. The only thing I dislike is that we 'rushed' into the voting stage without significant practical use -- and without proper descriptions [or referencing the applicable definition] of the conditions (wet means what? disabled means what? trailer only a vehicle class - or also a condition, etc. - this will leave some room for interpretation and will result in tagging differences). Nevertheless I approve it because it was no problem to use it (see below) for the practical cases I had - and in the whole voting process no big argument against it was raised:

"Too complicated": It doesn't affect the way simple cases are tagged (fully backward compatible!). But it provides a solution for things that weren't possible before. It is not more complicated then the road signs itself. So I don't understand votes like "I'm going to avoid further tagging of such features" because it was impossible to tag them until today, and other cases are not affected by this proposal.
:wet and :disabled: First they are just in proposal state - and we have around 500 uses for each according to taginfo. They also don't get invalid by this proposal. Once this is approved, just an alternative way of tagging wet/disabled exists. We accept since years that we have footway=both and sidewalk=both, thus the ambiguity can't be a huge argument, especially in a community project where things are "in move".
Having the vehicle category in the key is arbitrary: Yes it is somehow arbitrary, but a result of a compromise: It respects the current practice that maxspeed for HGVs and maxspeed for motorbikes are understood as two different attributes - and therefore have different keys. A side effect is to keep the values short.
:conditional is unnecessary. Yes. But breaking existing implementations using maxspeed, etc. by suddently allowing values that cannot be parsed seems to be more crucial than the better solution from a engineering/technical point of view. Here we shouldn't forget that :conditional is only required for special cases (for example more than 90% of my maxspeed tags are unconditional anyway).
Modifying conditional values in the editor (one of Eckhart's arguments): While the argument is true from a technical perspective (without changing editor behaviour), we have also to consider how often we will run into this issue: Conditional restrictions are already infrequent. Then we also need different conditions in two adjacent ways (makes it even more seldom). Finally there must be a reason for changing both of them (road sign changes are new regulations are rare). Altogether it is practically not relevant enough. With this proposal we accept that such an exceptional case is more work/inconvenient in the editor.
Syntax (@ character, etc.): Without editor support I don't believe that Joe Average will be able to tag complex road signs, no matter if we (try to) split it into several individual keys or keys with complexer values. We always need rules for it (syntax, grammar or feature definitions). And for 'hard core' mappers that are interested in keys & values, the syntax is intuitive enough for getting understood without massive lookups in the wiki.

--Martinq 13:38, 30 September 2012 (BST)

I approve this proposal. Viking81 00:25, 1 October 2012 (BST)

Proposal:Conditional restrictions

Contents

Tagging