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.

The content of this proposal has been archived to avoid confusion with the current version of the documentation.

View proposal content

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)

See also

• Conditional_restrictions the current documentation for the features proposed here.
• Extended conditions for access tags: Proposal using conditions within keys
• Conditions for access tags: Older proposal
• Conditional values: Somewhat similar to this proposal but including the vehicle category as part of the condition and using a "natural language" syntax.
• Access restrictions 1.5: Very elaborate (and complex) scheme for access restrictions, conditions encoded in keys.