Proposal talk:Conditional restrictions

Feedback and suggestions on several aspects

Resolved

Thanks for setting up this proposal, the core idea seems like the logical next step after the failed Extended Conditions vote. In fact, I've had a similar half-finished draft on my hard drive for a while, and I've pasted it to User:Tordanik/Conditions in values for comparison. The following feedback will mostly be based on the differences to what I had in mind:

• What I like best about your proposal is the pragmatic decision to keep vehicle category and direction in the key. It is compatible with existing usage, makes the values shorter and more readable, lets editors handle way reversals ... I didn't think of that option, but now it really makes sense.
• What I don't like at all is the introduction of OR operators. As I mentioned in a previous discussion, these are not necessary, and make the syntax more complex. For example, it means that there might be nested brackets. Since I expect only few cases where they would be used at all, I'd really prefer to just have an (implicitly AND-connected) list of conditions.
• I've listed user groups (customer, delivery, forestry etc.) as another possible type of conditions. This has been suggested to me previously and it seems like an easy and useful addition.
• Other differences, e.g. preferred style of brackets and so on, seem pretty minor and are hardly worth talking about much.

So, again, this is clearly the right direction, I hope to see you finish this proposal - and maybe adopt some of my suggestions. ;) By the way, I only found this proposal because of your link on the Extended Conditions talk page. Have you intentionally decided to not publish it widely yet? --Tordanik 21:09, 5 August 2012 (BST)

Thanks for your constructive response. The proposal is still in draft status but I am more or less ready to announce it on the tagging list. On the OR operator: Well, I simply added it as the complementary to the AND operator (being an ancient programmer although no longer active as such). I will probably take the OR operator out of the proposal unless I find good examples justifying it. On the user groups: These groups are already widely used as values without being considered "conditions". But it may be useful to use them as conditions thus restricting the actual values to things like yes, no, destination etc. Will think about it. --polderrunner 22:59, 5 August 2012 (BST)

I have modified the proposal taking account of your comments. "OR" is gone and I added a user group as condition. However I don't consider customer or delivery as a "user group" but simply as the purpose of the access. The same for forestry or agriculture. This is in accordance with established and approved practice for the access tag. As user groups I consider persons having specific titles or rights like doctors, disabled persons or fire fighters. --polderrunner 09:29, 6 August 2012 (BST)

I don't have a problem with your interpretation of "user group" and appreciate your open response to feedback. Looking forward to the RFC announcement. --Tordanik 17:43, 8 August 2012 (BST)

Transport mode and vehicle classes

You are mixing vehicle classes and transport modes in the same field. These are orthogonal and should get both their own room. --Dieterdreist 17:19, 9 August 2012 (BST)

I disagree here. Vehicle classes are simply vehicle-based transportation modes. Transportation modes (corrected from transport mode) also include foot, horse and other non-vehicle classes. See "Land-based transportation" in Key:access. -- polderrunner 19:10, 9 August 2012 (BST)

Different values depending on different conditions

Resolved

How would you tag the following real-world example (given in Extended Conditions syntax):

maxspeed=none
maxspeed:(06:00-20:00)=120
maxspeed:(22:00-06:00)=100

-- Eckhart 18:50, 9 August 2012 (BST)

Interesting. So you have to test drive your Porsche between 20:00 and 22:00? :-) Anyway, my proposal allows for multiple value:condition pairs separated by semicolon. This one would be maxspeed=none + maxspeed:conditional=120:(06:00-20:00);100:(22:00-06:00) --polderrunner 19:03, 9 August 2012 (BST)

Apparently I missed the multiple value:conditions part, maybe add an example?

Test-driving your Porsche: the maxspeed combination exists because most parts of the motorway are limited to 120 between 06:00 and 20:00 because of capacity constraints. The restriction to 100 applies to a short section of the motorway only as noise protection for night hours.

That reminds me that this example shows a drawback of your proposal: assume the night-time restriction already exists on a short section of the motorway, and now the day-time restriction has to be added to the whole motorway:

• with the Extended Conditions proposal: don't think, just add maxspeed:(06:00-20:00)=120 to the motorway
• with the Conditional Restrictions proposal:
  • check whether maxspeed:conditional is already in use on any segment
  • on those segments which don't contain maxspeed:conditional, add maxspeed:conditional=120:(06:00-20:00)
  • on those segments which do contain maxspeed:conditional, pick segments for every value individually, and add ;120:(06:00-20:00) at the end of the maxspeed:conditional tag.

-- Eckhart 00:52, 10 August 2012 (BST)

Yes, please can you add an example for multiple conditions. If I understand you right, then it should be maxspeed=120 +maxspeed:conditional=100:(Mo-Fr 07:00-17:00);80:(17:00-20:00);60:wet --SunCobalt 16:23, 10 August 2012 (BST)

Done. Your syntax is correct. --polderrunner 22:40, 14 August 2012 (BST)

Marked as resolved as the main point of this topic has been sorted. This leaves a discussion about a potential drawback when comparing to another proposal (and is highly unlikely to be changed in this proposal). --RobJN 21:53, 7 September 2012 (BST)

Trivial syntax substitutions?

Resolved

For better clarity, I suggest using an @ symbol instead of : in the value, i.e.

...=<restriction-value>@<condition>[;<restriction-value>@<condition>]

as that could be more intuitive in some languages and would simplify parsing (no colon collision with times). --goldfndr 08:45, 10 August 2012 (BST)

This seems like a decent idea. Syntax is always a bit arbitrary and ultimately a matter of taste, but using an "at" fits quite well and could actually improve readability. --Tordanik 10:55, 10 August 2012 (BST)

Didn't think about the @ character when drafting the proposal. But I considered not using any separator but putting the condition within round or square brackets directly after the value. Will think about using @ or possible other characters. --polderrunner 22:47, 14 August 2012 (BST)

The 'value @ condition' syntax seems like a good idea to me --RobJN 23:03, 14 August 2012 (BST)

I have implemented the @ syntax as suggested. --polderrunner 21:59, 25 August 2012 (BST)

How about using spaces before and after the @ character? Doing so might improve readability, not unlike the spaces that are already used before and after the "AND". The current style might make some values look a bit unbalanced, such as values with units (30 mph@wet).

Btw, it would now be possible to drop the ":" from the sentence "If the time condition includes the characters ';' or ':' the condition must be enclosed by brackets" if you want to. --Tordanik 23:04, 25 August 2012 (BST)

I agree, it looks better. Implemented --polderrunner 08:19, 26 August 2012 (BST)

Marked as resolved. Please remove if you don't aggree. --RobJN 00:14, 29 August 2012 (BST)

Trivial syntax substitutions? Part 2

I suggest changing the subkey from "conditional" to "exception" or "except" or "but" (or "yet"?) or perhaps "if" or "iff". (Beware ISO 639 additions.) --goldfndr 08:45, 10 August 2012 (BST)

The suggested alternatives to "conditional" generally don't describe the meaning of the key well. To me, "if" or "iff" would suggest that only the condition is stored in the value. "except" has a similar effect because of the manner this word is currently used for turn restrictions, where the tag contains a list of vehicle types excepted from the restriction. I think "conditional restrictions/values" is a good term for the concept as a whole, and "conditional" makes a better wiki search term than the alternatives for those who stumble upon such a tag. --Tordanik 10:55, 10 August 2012 (BST)

"iff" (meaning If and only If) would be incorrect: a no motor vehicle sign with "except for access" implies destination traffic is allowed, but destination traffic being allowed does not imply a no motor vehicle restriction. --RobJN 21:53, 7 September 2012 (BST)

Moving conditions to their own page?

Resolved

Every proposal so far basically agrees on what a "condition" is. Wouldn't it be a good idea to move the definition of a condition to its own page? That way the wiki pages can focus on the actual differences between the proposals (i.e. basically "where is the condition supposed to be")? This would allow discussing a new binary condition like "grossweight>7.5" without restricting that discussion to a single proposal. -- Eckhart 13:32, 10 August 2012 (BST)

I have now moved conditions to their own page and referenced them in the Extended Conditions proposal, it's probably a good idea if you do the same. -- Eckhart 17:18, 10 August 2012 (BST)

Well, I'm not sure if everybody agrees on the definition of "condition". My proposal does not consider transportation mode and direction as "conditions" but as "scopes" which form parts of the key. Thus your conditions page is not consistent with this proposal. --polderrunner 23:05, 14 August 2012 (BST)

In that case there is an additional limitation in your scheme, since transportation modes ("scopes" in your terminology) are not mutually exclusive. -- Eckhart 16:48, 15 August 2012 (BST)

Can you name an example where a condition requires two transport modes that are not in an ancestor relationship? If such a thing exists, it would indeed be a problem for the suggestion to keep them as a part of the key. --Tordanik 17:21, 15 August 2012 (BST)

Marked as resolved: A list of agreed "conditions" would be nice to have eventually but differences between proposals prevent a common list at this stage. --RobJN 21:53, 7 September 2012 (BST)

Avoiding lengthy tag values

Resolved

Instead of:

• <restriction-type>[<:transportation mode>][<:direction>]:conditional=<restriction-value1>:<condition1>; <restriction-value2>:<condition2>]

which could result in long tag values (difficult to read, especially in Potlatch 2), have you considered something like:

• <restriction-type>[<:transportation mode>][<:direction>]:1=<restriction-value1>:<condition1>

• <restriction-type>[<:transportation mode>][<:direction>]:2=<restriction-value2>:<condition2>

Regards, --RobJN 23:09, 14 August 2012 (BST)

One of the goals listed for this proposal is "No variable parts in the key". Numbers may be shorter and not quite as diverse as e.g. weight restrictions, but they would still be a variable element of the key, and many of the disadvantages described by users opposing the Extended Conditions proposal for that reason would still apply. --Tordanik 23:42, 14 August 2012 (BST)

I'm not suggesting numbers in the tag key as a variable as such. My suggestion is essentially to use multiple tags (e.g. key:1=value1, key:2=value2), instead of combining multiple values into one tag (as in the case of key=value1;value2;...). --RobJN 23:00, 15 August 2012 (BST)

My goal is to get all the variable stuff out of the key and into the value and your suggestion goes the other way by introducing a variable in the key, even if only a few different numbers are needed. That long values are difficult to read in Potlatch is no reason to significantly modify the proposal (it's Potlatch2 that needs fixing if there is a problem). In the example given in the proposal I count 32 characters in the value. This is no more than what can occur in many other tags (e.g. name, description, note). Also by removing "conditional" from the key it becomes more difficult to recognise the tag as a conditional restriction and it is more likely to be wrongly used by mappers. Furthermore, multiple conditional values for the same transportation mode seem to be quite rare. Eckhart presented one example above and I listed another on the page (time dependent maxspeed and another maxspeed in wet conditions) but such cases are not easy to find. I find the semi-colon solution perfectly acceptable for those few cases. --polderrunner 20:29, 16 August 2012 (BST)

I have marked this as resolved. --RobJN 00:14, 29 August 2012 (BST)

Fuel type and emission conditions?

How should we deal with restrictions based on the type of fuel used or the emission class of a vehicle? I'm hesitant to mention this in the proposal as it seems to be a bit of a quagmire to touch. There are many examples around. Vehicles using lpg (liquified propane gas) are often banned from underground carparks for safety reasons. Many German cities only allow vehicles fulfilling certain emission standards (identified by coloured sticker in the windscreen). Electric vehicles may have exclusive access, e.g. to charging stations. This topic probably deserves a wiki-page and maybe a proposal on its own. --polderrunner 08:32, 26 August 2012 (BST)

Hi Ole. Nice to see you considering all restrictions. Couple of suggestions that may help. The first two are proposed restriction types that could then be used with your extended conditions proposal (or elsewhere). The third attempts to make use of the fuel type as a value, and the fourth ... well I don't like it but fuel:lpg is used in the amenity=fuel tag schema:

• maxemissions = 120g/km
• allowed_fuels= , restricted_fuels=
• access:conditional=no @ lpg fuel
• access:fuel:lpg=no

--RobJN 00:02, 29 August 2012 (BST)

The first two suggestions have the problem of interrelated tags, i.e. which tag belongs to which? Furthermore, I don't expect the first example to be used on a road sign anytime soon. CO2 emissions are more related to vehicle taxation and registration. The third suggestion is in line with my proposal although I would probably write it as access:conditional=no @ fuel:lpg. The fourth suggestion has a condition in the key which is precisely what I try to avoid. --polderrunner 09:27, 29 August 2012 (BST)

The emissions one is going to be difficult as I would expect each country to use different methods of determining "emissions". How does the Low Emmission Zone in London work? Can you also explain what you mean by "the problem of interrelated tags"? --RobJN 02:14, 31 August 2012 (BST)

left/right

Resolved: --Martinq 17:31, 4 September 2012 (BST)

The current proposal text supports only :forward and :backward. Shouldn't :left and :right be included/possible too? I think about parking conditions, where this conditional value approach could also be used.--Martinq 21:05, 28 August 2012 (BST)

Although this is probably beyond the scope of the conditional restrictions page, it seems to me that this proposal could work well for parking rules currently mapped using Key:parking:lane. For example the parking lane wiki page includes the example:

• parking:lane:right=parallel
• parking:condition:right=free
• parking:condition:right:time_interval=18:00-10:00

In my opinion this would be better expressed using 'similar' logic to the conditional access proposal. The above could be expressed as:

• parking:right=parallel
• parking:right:conditional=free @ 18:00-10:00

Note: I have dropped the use of "lane" as I feel this could be confused with the Lanes schema. I also use the word 'similar' with scepticism - maybe use of conditional is not great here. Perhaps parking:right:fee=free @ 18:00-10:00 is better...

--RobJN 23:43, 28 August 2012 (BST)

That seems to be a useful extension to the proposal. I may introduce it redefining the third key field to be "direction/side" if there are no serious objections to that.

Concerning your actual example: Would it not be more logical to specify the value of the parking restriction between 10:00 and 18:00 when it is NOT free? That is probably when most people would like to park there. --polderrunner 09:37, 29 August 2012 (BST)

This could be a bit messy. If we add conditions to the existing parking lane scheme without breaking the existing syntax the syntax could become very long and awkward. E.g parking:condition:right:conditional=free @ 18:00-10:00 (I really think the creators of the parking lane scheme should have used restriction in place of condition). On the other hand if we omit "condition" as suggested then basically we are modifying the existing parking lane scheme which may not be well appreciated. Thus I still hesitate to add right/left. --polderrunner 09:25, 30 August 2012 (BST)

The parking lane tags have the same issue like the access or other traffic restriction related tags: They try to describe conditions with a lot of individual tags for every aspect of the restriction: time, duration, etc. As soon as someone has to describe a non-trivial combined restriction/condition - and authorities seem to love complicated parking restrictions - it gets hard or impossible to express it. The same idea could help there too (and make tagging less bulky and IMO easier to read). But it was not my intention to discuss solutions for parking lanes here. It is not in the scope of this proposal now. I only mentioned it as an illustration that there are tags with :left and :right, and not just :forward and :backward, which may have conditional values.

To go a step further, isn't there a basic underlying question about how to order all our key extensions? Do we need an explicit order for various extensions like left/right, lanes, forward/backward and - because chosen by design - the transport mode/vehicle category (and maybe other extensions)"? Who defines that? Every key extension must come up with rules? Is it hgv:conditional:lanes or hgv:lanes:conditional or is it an option to allow both (creating lot of permutations for applications for key lookup)? Is it really mandatory to write lanes:bus:forward:conditional or is lanes:forward:bus:conditional also OK? The more 'generic' key extensions we define in OSM, the more this question will get relevant. But I am not sure we need solve it here, because the problem already persists and is not caused by this proposal. I also point out that in the current tagging practice (taginfo) combintions of extensions are very exceptional, only forward/backward + transport mode has relevant usage, thus we may not have to worry about other combinations when they represent just e.g. 0.1% of the cases. --Martinq 12:32, 30 August 2012 (BST)

I totally agree that the parking lanes is beyond the scope of this piece of work. But it does go to show, if we can get this one sorted we provide a syntax platform that could be used to help tagging similar situations. --RobJN 02:07, 31 August 2012 (BST)

The other place that 'left' and 'right' is used is for Key:cycleway. Don't think it is of too much concern here either, but can't say for definite that others won't adapt this proposal to include left/right. (Full disclosure: I'm not a huge fan of the cycleway key as I feel it is trying to do too much - lanes and tracks are different and should be treated as such). --RobJN 02:07, 31 August 2012 (BST)

I have added 'left/right/both' as possible values to the direction field. I included 'both' for completeness since this value is already used by existing parking schemes. --polderrunner 19:37, 31 August 2012 (BST)

Imo this is dangerous because many existing uses of "left/right" are not actually conditions, but instead simplified forms of Lanes tagging that refer to a physical part of the road. This is the case with e.g. bicycle lanes or sidewalks where attributes are sometimes given as cycleway:left:oneway or something like that. If you list left/right as a possible condition, then people might be confused and treat these cases as if they were conditional tagging - this would not only affect the order of the suffixes, but also prevent lanes mapped like that from having forward/backward restrictions. --Tordanik 20:00, 31 August 2012 (BST)

Ok, your objections seem fair. There are really only parking lane restrictions that require "left/right" (I can't think of others at the moment). And since such restrictions are already covered by an (approved?) tagging scheme there is no real reason to include left/right in this proposal. Thus in order to prevent potential confusion I have decided to remove left/right again. --polderrunner 20:44, 3 September 2012 (BST)

So, if I understand the conclusion right, 'left' and 'right' belong to the key with a restricted/conditional value. Consequently a conditional value on a left/right side feature would be structed key:left/right + :transport mode (optional) + :direction (optional) + :conditional. We also interpret 'forward' and 'backward' as (part of the) condition, which is (for backward-compatibility reasons) included in the key. After the discussion I can agree with this point of view.--Martinq 17:29, 4 September 2012 (BST)

Maxweight and similar maximum rules

Many conditions restrict access to some maximum value, and are signed in this way (e.g. Maxweight, max length signs are part of the Highways Agency approved signs in the UK). As such we already have some tags that align with these signs. Can you please consider making more use of them. For example:

• maxlength:conditional=5 @ (10:00-18:00) instead of access:conditional=no @ (10:00-18:00 AND length>5).
• maxweight:conditional=none @ destination instead of access:conditional=destination @ (weight>5.5).

This reduces the need for '>' which may cause issues for xml (as noted in Any tags you like). Perhaps a web developer can provide more advice as to how important this is, if at all. --RobJN 23:27, 28 August 2012 (BST)

After reading the proposal carefully, I cannot confirm that the proposal 'enforces' or 'prefers' the second option. Both ways are fully inline with the proposal.

But while having the same result, I see a subtle difference between both versions: I would use maxlength:conditional=10 @ (10:00-18:00) for a road with this sign and the addition like 10:00-18:00 only, but access:conditional=no @ (10:00-18:00 AND length>10) when there is this sign and the addition from 10:00-18:00 for vehicles longer than 10m [Note: That's not fully correct, it should be tagged as vehicle:conditional=no @...]. In other words: No unnecessary transformation should be made by mappers. The main sign determines the key (maxspeed, maxweight, access...), the restictions or conditions written on additional signs below are expressed with conditional values.--Martinq 08:22, 29 August 2012 (BST)

That's also how I would do it in practice. Use the base key that corresponds to the main sign, and use conditions to model the effect of add-on signs. --Tordanik 19:02, 29 August 2012 (BST)

Agree. Thus use access tag when the sign indicates a restricted access with a condition and max* tag when the main sign indicates some maximum measurement of the vehicle. I doubt that there are many conditional maxweight/length/height /.. signs around since such signs usually corresponds to physical limitations of the road ahead and therefore are unlikely to be conditional. BTW, the example above was inspired by this sign and should therefore really be motor_vehicle:conditional=.. --polderrunner 20:07, 29 August 2012 (BST)

Comment: even if not conditional based on time or other such, we have many places with "maxlength 12m, except buses"; most of the roads into the city center have such signs to keep anything bigger than a small truck on the main roads to the harbour. There's only a slight correlation between the restriction and "roads difficult to maneuver with a long truck". Outside the very center they're just to prevent heavy vehicles driving through some residential areas, when there's a big road that goes around said area.

Otoh, most entry points into the city have time limited conditional access rules for transports of hazardous materials, even two classes of such transports, any transport is categorized based on the materials involved and the amount onboard. --Alv 10:02, 30 August 2012 (BST)

Same in my area, especially maxweigth is often used for 'political' reasons (to reduce the amount of damage on roads due to heavy load trucks - and save maintenance costs for the communities - or to enfore specific routes outside the residential areas) rather than due to statical calculations. Thus you find things like maxweight=2.5t except agricultural traffic or 2.5t except residents mainly to keep truck traffic and road damage at a minimum.--Martinq 12:42, 30 August 2012 (BST)

The character restriction in Any tags you like relates to keys. In values any character is allowed, see last sentence in that section. --Martinq 08:01, 29 August 2012 (BST)

"After reading the proposal carefully, I cannot confirm that the proposal 'enforces' or 'prefers' the second option. Both ways are fully inline with the proposal".

Perhaps an example of both can be inlcuded in the proposal as although it does not 'enforce' use of the access tag the lack of an example would suggest that this is the preferred option. Also a note on using the 'main sign' as base key would be worthwhile. --RobJN 22:10, 7 September 2012 (BST)

The two examples maxlength:conditional=5 @ (10:00-18:00) and maxweight:conditional=none @ destination are actually problematic as there is the need for defining the unconditional values of maxlength and maxweight (the access versions don't have this problem as access=yes is the default for normal road types). And what does the value "none" mean? 0, indefinite or something else? I haven't seen "none" documented anywhere. However, it may be a good idea to mention that the restriction type should reflect the actual "main sign".

BTW, did you just mess up this topic? I think some text used to be in a different order such as the discussion on allowable characters! --polderrunner 23:27, 7 September 2012 (BST)

(I simply moved the responses to after the signature of the original question - apologies if I shouldn’t have done this --RobJN 23:24, 9 September 2012 (BST))

"none", in the context of max* attributes, is supposed to mean "no limit" - see e.g. Proposed_features/maxspeed_none. It is basically the implicit default value for most max* attributes. --Tordanik 02:19, 8 September 2012 (BST) --Tordanik 02:19, 8 September 2012 (BST)

Ok, I only looked at Key:maxweight and it was silent on "none". Maybe the Key:max<dimension> pages need some attention concerning allowable values? --polderrunner 20:47, 8 September 2012 (BST)

Some more examples

Resolved: Appears resolved. Please start a new topic if adding more examples.--RobJN 21:53, 7 September 2012 (BST)

I'd like to see what these restrictions become in this proposal:

1. Normal residential road, no access on friday between 5:00 and 15:00 except public service vehicles.
2. Oneway road, but cyclists and mopeds are allowed in both directions.

--Eimai 21:12, 3 September 2012 (BST)

1. access:conditional=no @ (Fr 5:00-15:00) + psv=yes

2. This isn't really a conditional restriction. It could be tagged oneway=yes + cycleway=opposite (or oneway:bicycle=no) + oneway:moped=no. --polderrunner 21:43, 3 September 2012 (BST)

Thanks, I wasn't too sure about the conflict resolution on the first one, so wanted to check what the solution was. Does mean that it requires some interpretation to translate traffic signs into tags.

But what about: road with twoway traffic, except on sunday, when it's oneway, but bicycles can still go both directions? --Eimai 01:26, 4 September 2012 (BST)

The important rule here is that a restriction for a more specific transportation mode overrules any restrictions for less specific transportation modes, like in example 1. The same will apply to your new example where the oneway:bicycle and oneway:moped tags will overrule a oneway:conditional restriction. --polderrunner 08:34, 4 September 2012 (BST)

So I guess it'll be oneway:conditional=yes @ (Su) + oneway:bicycle=no. Great for humans, but I don't think this makes the automatic traffic sign translator I'm planning to make very easy :-) Anyway, I like the syntax, everything is possible as far as I can see. And we so desperately need this... --Eimai 12:47, 4 September 2012 (BST)

Yes! I have added your example to the examples section. That automatic traffic sign translator sounds interesting. How does it work? Image recognition, smartphone? --polderrunner 19:25, 4 September 2012 (BST)

Nah, it would be just a webpage where you click on traffic signs. I had a working version for most Belgian traffic signs, but it translated into tags with a syntax I created myself since there was no official version available (similar but not the same as the previous proposal). That page isn't online anymore so I can't show it. When I have some time I'd like to adapt it to the new syntax, but it probably has to be rewritten mostly, because by adding more and more traffic signs I was already hitting the limits of what the initial design could handle. But one problem I can foresee now is that in the first example above, interpreting the "psv:conditional=yes @ (Fr 5:00-15:00)" as "psv=yes" will prove to be difficult, as it also means understanding all restriction tags that may be present and making sure that the shortcut won't conflict. Now, the two are equivalent in the end, so it's not too much of a problem, but it would be nice anyway. Same problem with the "oneway:bicycle=no" in the third example by the way, which is the simplified version of "oneway:bicycle:conditional=no @ (Su)". --Eimai 01:40, 5 September 2012 (BST)

Btw, once that's written, if someone wants to make a image recognition program to be used as input instead of clicking in a list of traffic signs, that would be fun, but I don't know anything about creating such a thing :-) --Eimai 01:45, 5 September 2012 (BST)

Restriction relation

This probably doesn't have to be in this proposal at the same time, but one thing I keep missing in these proposals is the ability to put the restriction in one relation and add the roads with that restriction to that relation. Plenty of zonal restrictions here where this would make sense (and they often have some extra info like reference numbers and/or names so repeating all of that information on all roads would be more error-prone and cumbersome than putting it in one relation). Syntax can be just the same, unfortunately type=restriction is already taken for turn restrictions so we need another type=* value to classify the relation. --Eimai 21:27, 3 September 2012 (BST)

That certainly doesn't belong in this proposal but otherwise seems like a good idea. Maybe make a new proposal for relation type=zonal_restriction (or type=zone_restriction)? --polderrunner 21:57, 3 September 2012 (BST)

type=zonal_restriction, I like that (although it may be an issue for some since it doesn't necessarily have to be a zonal traffic sign). But yeah, let's keep this for a separate proposal after this one gets approved. --Eimai 12:50, 4 September 2012 (BST)

I think one of these 'zones' would be when all access roads into area within a city centre are marked no motor vehicle except for access. The central area would include roads that don't have this sign but are not possible to get to without passing the sign. How do we ensure routing software knows it can route down these restricted roads to destinations within the zone? To me this is where a zonal relation would come in... --RobJN 21:53, 7 September 2012 (BST)

And some more syntax questions

A few more syntax questions for some situations I've seen in my city:

• no access to vehicles except for delivery between 7:00 and 11:00 or between 17:00 and 19:00, but only if the vehicle is less than 7.5 tons. The question here is of course what the syntax in the condition is exactly. Reading the page I'd say it's "vehicle=no" + "vehicle:conditional=delivery @ (weight<7.5 AND 5:00-11:00, 19:00-22:00)". But since I think that the comma has the meaning of the "OR" operator if I understand it correctly, this may introduce some conflicts in the syntax (you could read that line as: delivery allowed between 5 and 11 if weight is less than 7.5 tons, or between 19 and 22 and weight doesn't matter then). Should there be an OR operator as well? (and perhaps even a NOT operator?)
• Multiple restriction-values: no access for vehicles except deliveries and residents (there's not really a tag for that one, but it's not the same as destination traffic, I use "residential"). The access key page doesn't say how it's done either. --Eimai 20:19, 7 September 2012 (BST)

One option to solve the fist point would be to drop the usage of multiple time blocks separated by a comma. If this was dropped from the proposal then the correct tagging would be "vehicle=no" + "vehicle:conditional=delivery @ (weight<7.5 AND 5:00-11:00); delivery @ (weight<7.5 AND 17:00-19:00)". Other solutions would include keeping the current use but adding a note to the proposal to try and make it clear what is meant in this example. --RobJN 22:00, 7 September 2012 (BST)

To be clear there is no OR operator in this proposal (there was but I removed it, see first topic on this page). The comma is part of the time syntax and is used for separating multiple time intervals according to the opening hours syntax. I didn't want to invent a new time condition syntax when there already is the well-established opening hours syntax. The comma should certainly not be confused with an OR operator, it belongs strictly to the time condition. Using vehicle:conditional=delivery @ (weight<7.5 AND 5:00-11:00, 19:00-22:00) therefore should be unambiguous.

Concerning multiple restriction-values. They will need to be separated by semicolons, each value with its own condition even if the conditions are identical for both values. At least this proposal has a solution for this problem unlike the access key page. I have never seen "residents" as a documented value for access restrictions. In my opinion "destination" more or less means "residents" and "delivery" (and any other necessary access to addresses on that street such as the plumber). I would use "destination" in this case as the main purpose here is to prevent routing of non-destination traffic there. --polderrunner 23:03, 7 September 2012 (BST)

access=destination has it's own definition in our traffic code, and it's really not the same as residents and delivery traffic. So while tagging it as such would probably deny access to many users by a router, that router would allow also others to use it while it's not allowed in reality. An access tag for residents is something we really need in Belgium, since it appears on a lot of signs, and another tag for what google translates as "adjoining landowners" (Dutch: aangelanden, French: riverains).

'Destination' may not catch all fine differences between national laws but it is the only one defined on Key:access. At least in the Netherlands it is called "Bestemmingsverkeer" which translates pretty accurately to "destination traffic". Since this proposal just adopts the values defined in the existing access page I suggest to continue the discussion on Key:access as it is not the goal of this proposal to introduce new access values. --polderrunner 19:47, 10 September 2012 (BST)

Also, wouldn't mulptiple access restriction-values tagged like you say involve some problems with the logic of the tag? If you have something like "access:conditional=delivery (A=B); agricultural (A=B)", then how would one logically process that? Suppose the condition A=B is fulfilled, and I'm delivery traffic: rule 1 says I'm allowed, rule 2 says I'm not allowed, so which one takes precedence? The page says in the conflict resolving section that the most restrictive rule wins, so it's not allowed. The same happens when I'm agricultural traffic but not delivery traffic. So I think we still need to have the two restriction values together somehow.

On a similar note: how are conflicts inside one access:conditional rule handled if one part says something is allowed and another one says it isn't? --Eimai 16:00, 10 September 2012 (BST)

I may need to have a closer look at that rule. Intuitively there shouldn't be a problem if the traffic is allowed according to either delivery or agriculture. The issue here is that both 'delivery' and 'agriculture' have built in implicit conditions ("purpose=delivery?"). If you consider it this way then there is no conflict as one condition is fulfilled, the other not. However, rule 4 doesn't handle this correctly. I will try to rework it. I'm not sure I have understood your second question. There can't be any conflicts within one conditional statement. Either there is just one condition or there are more sub-conditions combined using the AND operator. All sub-conditions must be true for the condition as a whole to be true. --polderrunner 19:47, 10 September 2012 (BST)

For the single access key, I've once heard the proposal to tag it as "access=delivery;agricultural". Now obviously we can't use that here with a semicolon, so we may need something like "access:conditional=delivery,agricultural @ (condition)". Or we do away with the established method of tagging these and use something like your "purpose=*" condition instead, but then we'd have to use "access:conditional = yes @ (purpose=delivery)" instead of "access=delivery". It becomes even more fun when you have a condition for traffic that is at the same time delivery and agricultural traffic... If we stay in the existing tags, I could see something like "access:conditional=delivery+agricultural @ (condition)" (a plus sign instead of a comma above). --Eimai 19:45, 11 September 2012 (BST)

You can use the semicolon here! Just repeat the condition for each value. So it would be access:conditional=delivery @ (condition1);agricultural @ (condition1). I will rework the conflict evaluation as discussed in the section below. The last matching restriction will be the effective one. --polderrunner 21:36, 11 September 2012 (BST)

I just explained above why it can't be used, and even if you replace the rules to resolve conflict with "last one that applies wins", it won't work well. There are just no other possible ways here than to keep them together in front of one conditions. --Eimai 23:43, 12 September 2012 (BST)

I think we are discussing rather hypothetical situations which have next to no importance in the real world. I'm not going to introduce a more complex syntax to cover such unusual combinations of restrictions that may never be used in reality. The current proposal will cover 99.9% of all situations that are likely to be encountered by mappers. Should there be a situation that cannot be accurately be tagged using this scheme that won't mean the end of the world, only that a special transportation mode may encounter a slightly unexpected situation which most likely will have no or only a minor impact. --polderrunner 00:25, 13 September 2012 (BST)

Well, it's maybe because of my mathematical background, but I do care about the 0.1%, because having a syntax that's not covering everything will sooner or later become a problem. It's always the exotic examples that make you really think about the entire picture. Also, I wouldn't find a restriction like no vehicles allowed on sunday, except agricultural vehicles and destination traffic, not that extraordinary for example... And one can only wonder what governments have come up with in various parts of the world we're not familiar with. So yeah, maybe there are zero examples of this in the roads the people who are discussing this syntax are familiar with, it still doesn't mean we have to ignore it. It may not become part of the new syntax for now, but it doesn't mind thinking about it so we're at least not making it impossible to extend the syntax when a place is found where we do need this (the syntax doesn't make it impossible, but if you as inventor of the syntax say that it should be tagged in a logically wrong way, imagine what users will do if they ever encounter it). My idea is just to make it as complete as possible from the start, because rules like access tags syntax is something that's best changed at as few occasions as possible. Anyway, I'm going to find me some more exotic examples to test this syntax to its limits :-) --Eimai 02:30, 14 September 2012 (BST)

In ths community project we often only approximate reality (a new house -> map it as approximation or a point until we have arial images). People find and tag approximations for the missing 0.1%. I actually do this from time to time, e.g. there is a track in my area with maxweight 2.5t, but except argricultural *traffic*. I tagged it as maxweight=2.5 + maxweight:agricultural=none (and a note), which is not perfect (agricultural vehicle != traffic), but IMO close enough ("better than nothing") and valid for most poeple.

I'm realizing that the proposal is missing something here. In case of restrictions requiring a numerical value such as all max* restrictions it should be possible to use the purpose-of-access as a condition. Your example would be maxweight=2.5 + maxweight:conditional=none @ agricultural. However, would it be confusing that e.g. agricultural now can appear in three different places with three different meanings? --polderrunner 11:48, 14 September 2012 (BST)

About the problem: I would intuitively put brackets around the value if it contains special characters or spaces (like we do with the condition!): access:conditional=(delivery;agricultural) @ (condition) or (not seriously) name:conditional=(Mars-Testosterone Street) @ male;(Venus-Oestrogen Street) @ female. I personally think this would happen anyway, even it is not explicitely described in the proposal.--Martinq 10:48, 14 September 2012 (BST)

I propose to close this discussion. The current proposal will stay as it is. Should a real need appear to add further refinements to the scheme they could be added later (I believe that various improvements have already happened to Key:access and many other approved tagging schemes). However at the moment it is not currently evident that further refinements are really necessary (no real life examples) and further not clear how such improvements could be defined. --polderrunner 22:01, 16 September 2012 (BST)

Evaluation of conflicting restrictions

Resolved: --Martinq 11:14, 13 September 2012 (BST)

I am not sure if the new rule for multiple value/condition pairs is really understandable. Using your example, slightly modified: access:conditional=destination @ hazmat; no @ 9:00-17:00

There are two possible interpretations:

• There is no access from 9-17 for everybody and hazardous material can be delivered to a destination in this street from 17-9
• Hazardous material can be delivered the whole day (including 9-17!), but everybody else cannot access the street from 9-17

In this case the first one seems to be more logical (the human brain is amazing), but if I use your example: access:conditional=destination @ disabled; no @ 9:00-17:00 the second interpretations suddently seems to me more likely/obvious than the first one [at least according to the interpretion in the proposal*]. Thus "more special" is very vague, because the difference was only disabled/hazmat. [* the example would disallow disabled persons that they can drive through like any other person from 17-9, but let's ignore that].

I propose another rule: If multiple value/conditions are in a key, the last match is used as value. This implies that order of value/condition pairs should be from generic to the special cases.

• access:conditional=destination @ hazmat; no @ 9:00-17:00 has then the first meaning from above,
• access:conditional=no @ 9:00-17:00; destination @ hazmat the second meaning.

No "more specific" interpretations are required - and it is hopefully not counter-intuitive to start with the generic case first (at least it is not for me).

We should keep in mind that these are already very special cases, and the proposal typically does not require multiple key/value pairs - and and average mapper has typically not to worry about them. But it is good to define it upfront. --Martinq 07:29, 11 September 2012 (BST)

First of all, these conflicting examples are probably rare in the real world and we shouldn't put too much effort into some elaborate scheme to solve them. I admit that the current solution (rule 4) is less than perfect and could be counter intuitive (and yes, hazmat traffic will indeed have destination access all day according to the rule!). Your idea using the last match may be a simpler solution and certainly easier to explain. But it will make the order important. It will be necessary to stress that the restrictions should be listed with the more generic restriction first and the more specific restriction last. --polderrunner 09:59, 11 September 2012 (BST)

I guess Martinq gave the example you asked me above :-) I agree that the "last match counts" idea is a better one than the "most restrictive one wins", but let's make sure that doesn't bring its own conflicts. In any case, however rare these examples may be, it's best to define it up front and make sure it works correctly, so we won't end up with ten routers each interpreting the rules slightly differently to match what makes sense to them. --Eimai 19:38, 11 September 2012 (BST)

I have modified rule 4 to be "the last match is the effective restriction". Is simpler to evaluate but the mapper must be aware of the order when tagging. There is no longer a need for a rule 5. Hope this addresses your comments. --polderrunner 09:17, 12 September 2012 (BST)

Pictorial examples

Can we have some pictorial examples please, for integration into the final thing? Here's my stab at some UK examples in my home town. I've attempted to represent them in this schema as an exercise and to test it out with some real-world examples; please feel free to re-express them. Perhaps we could add some of the other totem pole images [1], [2] (Finnish), [3], [4] (German) too? --achadwick 12:32, 17 September 2012 (BST)

#	Photo	Tagging ("Conditional restrictions" schema)	Remarks	Tagging ("Extended conditions" schema)
1		for the bus gate highway=tertiary motor_vehicle=no motor_vehicle:conditional=yes @ (18:30-07:30) psv=yes	A nice simple access condition to get things started. This is a camera-enforced "bus gate"; motor vehicles are prohibited from 07:30 to 18:30 except for PSVs. It's almost representable with the existing schema, however using hour_on=* and hour_off=* would also break the speed limit since they're deemed to affect that too. times need to be switched around (against as they appear on the sign) if you want to use motor_vehicle=no as a fallback	for the bus gate highway=tertiary motor_vehicle=no motor_vehicle:(18:30-07:30)=yes psv=yes
2		for the section around the corner highway=tertiary psv=yes tourist_bus=no tourist_bus:conditional=yes @ (18:00-10:00) taxi=yes taxi:conditional=no @ (occupants>8 AND 18:00-10:00) The no-through-road restriction refers to the bus gate in the example above, and is represented separately.	This totem pole warns of a restriction prohibiting big taxi-vans or buses between 10:00 and 18:00 further around the corner to the left. This is then lifted for local buses". The intent is to prevent tour buses of any size from driving through the centre of Oxford during peak hours. The "no through road" restriction refers to a camera-controlled "bus gate" found around the corner to the left which the named vehicles can just go straight through without being fined.
3		for the road highway=unclassified motor_vehicle=yes motor_vehicle:conditional=no @ (10:00-18:00 AND length>5)	As mentioned above. In this case, most motor vehicles which might use it are short enough to be excluded, so it makes a better map to say "yes" for the general motor vehicle case. motor_vehicle=yes may be omitted in this case because it is implied by the value of the highway tag. It is retained above for didactic reasons.
4		for the pedestrian zone highway=pedestrian motor_vehicle=no motor_vehicle:conditional=yes @ disabled; delivery @ (18:00-10:00) bicycle=yes bicycle:conditional=no @ (10:00-18:00) for the bollard barrier=bollard bollard=rising motor_vehicle=no motor_vehicle:conditional=yes @ (18:00-10:00)	A complex example to chew on. Pedestrianized area (no restrictions come from that though, beyond what's spelled out on the signs). No motor vehicles except those belonging to disabled persons displaying UK "blue badge scheme" badges in their windscreens, except vehicles used for loading or unloading between 18:00 and 10:00 No riding of bicycles between 10:00 and 18:00. No parking at any time, even if you remain in the vehicle. Doesn't apply to loading and unloading goods, and presumably disabled persons are OK too. Some of the above is partially enforced by a rising bollard from 10:00 to 18:00.
5		for the road highway=residential (motor_vehicle=yes) not needed for "residential" motor_vehicle:conditional=destination @ (22:00-06:00); yes @ (22:00-06:00 AND fi:service_traffic); yes @ (22:00-06:00 AND parking_permit:F)	The word "tontilleajoa" mean literally "into a lot", so if you drive there to park on the street, you're not driving into a lot; not all of these streets in the small area have any buildings lining them. "Huoltoajo" (literally "service driving" is a legal concept here, which includes six different use cases, from "with enough small kids per adult passenger" to "a taxi when picking up or dropping of a customer". The repeated hours on the sign mean they're valid for saturday and sunday, too, which allows shorter tag values.
6		for the road highway=residential maxlength=12 maxlength:bus=none vehicle:conditional=permit_holder @ (length > 12) hazmat:A:conditional=no @ (Mo-Fr 07:00-09:00, Mo-Fr 15:00-18:00) hazmat:B:conditional=destination @ (Mo-Fr 00:00-07:00, 09:00-15:00, 18:00-24:00; Sa-Su 24h)	"With special permit" seems overkill, those with the permit (no idea who they are) already know they can enter. The "B (VAK)" is a category of hazmat transports with larger amounts and/or more dangerous materials; at peak hours, no hazmats allowed, at other times, small transports are free to go, and bigger loads only to their destination. These A and B groups are sometimes used without time limits, so the tags hazmat:A and hazmat:B are "in use" and moving that to the condition seems unnecessary.
7		for the road highway=* maxlength = 10 maxlength:psv = none maxlength:conditional = none @ destination; none @ agriculture; none @ forestry maxspeed=50	both agriculture and forestry are used as 'Use Type', not vehicle type and therefore end up in the value, not in the key (A farmer can also use this exception in his normal car, not only with his tractor). I found no good value for 'Linienverkehr', which means vehicles on fixed and reoccurring routes. Yes, this is mostly public transportation buses on a schedule, but the definition says it can also be transportation of goods and the 'psv' tag doesn't specify the fixed and reoccurring nature of the route.
8	translation: except agricultural traffic and "Wasserverband" (=an association) vehicles	for the road highway=* maxweight = 3 maxweight:conditional = none @ agricultural maxspeed=30	Exception is valid for agricultural traffic, not agricultural vehicles, thus maxweight:agricultural = none would be incorrect Value none is not an 'officially' described value yet, but according to taginfo already in use for such cases (especially maxspeed) Exception for "Wasserverband" vehicles cannot be tagged yet (similar to other exceptions for special groups, associations or companies - or permits like "A38")
9		for the road highway=* maxspeed=80 maxspeed:hgv:conditional = 60 @ (weight>7.5)	Simple example for a conditional speed limit on a motorway, which cannot be tagged with current access and restriction tags.

• At first: thanks for this topic! I really like the idea of bringing this down to a seeing-a-sign -> how-to-map problem. That's a lot more helpful that pure academic discussions of how to restrict only green cars entering during a blue moon.
  • But seeing your examples, I may have a question: Do we need some rules or advises on how to decide which general tag to choose and which exception then to use the conditional for? I like to tag in favor of the general category of main sign (prohibition/allowance) and then do the conditional for the extra-signs, if possible copying times/restrictions literaly. For example a 'No bicycles, except 6pm-10am' would be a bicycle=no + bicycle:conditional=yes@(22:00-10:00). But for backward compatibility, you may also argue that even if the main sign forbids bicycles, it's more often allowed than forbidden to use the road so a bicycle=yes + bicycle:conditional=no@(10:00-22:00) would create less error on non-conditional-aware data users (and could even be reduced to the second part if bicycle=yes is a default for that road).--Chaos99 14:47, 17 September 2012 (BST)

• Base cases: That's a very good question. IMO it's an aesthetic choice, particularly for access=* which generates dashed overlays for the general case in Mapnik. And it's very context-specific - local knowledge matters enormously for making a Good Map. I think my first stab at a guideline would be best expressed as

"For any given mode, or the general "access" case, decide what kind of traffic mode within the mode's set predominates, and what the most common instance of that traffic mode is. Tag the base case (<mode>=* or access=*) with the access level which would be applied for this most common instance during peak daylight hours, in good weather, and with the current road conditions; then tag exceptions to this base case using <mode>:conditional=* or access:conditional=*.

"For most public roads in industrialized/developed nations, the most common traffic mode within access, vehicle or motor_vehicle is the private automobile. Common exceptions include pedestrian areas, industrial hgv roads, off-road cycle tracks and similar: tag these according to their predominant mode."

"For developing nations and rural areas, other traffic modes may dominate (bicycle, foot, motorcycle rickshaw...). Decide what type of traffic predominates here, and tag for the most common instance of that in access=* during peak daylight hours, in good weather, and with the current road conditions."

Hope that makes sense! I think it's also a good system for even the current access schema, which permits a base access=* case and overrides following the lines of the mode hierarchy. --achadwick 16:10, 17 September 2012 (BST)

I see a problem here and it's kindly illustrated by the first Finnish sample above: If the sign says 'no' and all the exceptions specify when it's still 'yes', you can't make the base case a 'yes', because your conditions have no 'no' case to fall back to when no condition matches. Look at the example: all the conditions specify yes @(...). So how does a router know when it's not allowed to enter? I think the user who added this example had the impression that every access:condition tag has a built in fallback to 'no'. But that's not the case. It has a fallback to the more general tag given before, which in this case is 'motor_vehicle=yes'. We could fix this by adding a motor_vehicle.conditional = no; yes@(..) to the value, but a restriction with empty condition is not specified in the proposal. --Chaos99 08:12, 18 September 2012 (BST)

But it falls back to "destination" for anybody not-more-specific, even if the sign is a "no". The conditional destination matches everybody at that time. Alv 08:44, 18 September 2012 (BST)

I re-thought the example and you are of course completely right. Sorry about the fuzz. I mixed up the conditions and the restrictions and though "When I'm not going to a destination, who says that I'm not allowed to enter?" But this is wrong. You have to ask for the condition ("Is it after 22:00?") and then the restriction 'destination' is in effect, which in itself says that I can not enter. Got that now. Feel free to delete this discussion branch if you like. --Chaos99 09:07, 18 September 2012 (BST)

• (moved here to keep the table above free of discussion)
  Changed bicycle = no + bicycle:conditional=yes @ (10:00-18:00) to bicycle=yes + bicycle:conditional=no @ (10:00-18:00). The former was clearly incorrect. You may argue about if it's better to start with no or yes. I preferred to follow the general meaning of the sign (prohibition) and keep the hours as shown on the sign. --Chaos99 14:27, 17 September 2012 (BST)

• Thanks for the fix. I think it's better to start with bicycle=no because those are peak daylight hours and you can't ride down that street at that time. But access=yes because it's a pedestrian zone and therefore foot use predominates :) --achadwick 16:10, 17 September 2012 (BST)
• OMG, incredible what those local authorities can get away with! At least I think this tagging scheme can handle these complex restrictions. I'm more concerned about the poor drivers having to decipher those signs on the fly. For the first example I would tag it exactly as the sign indicates, thus motor_vehicle:conditional=no @ (07:30-18:30). Then there is no need to tag the default as highway=tertiary allows all traffic by default. You can of course discuss if the opposite tagging would be better from the view of causing the "least surprise". That is a personal taste. I recommend to tag the sign literally, easier to map and less chance of messing up. The second example only applies to the upper half of the "totem pole" if I'm right? The lower half should be tagged access:conditional=no @ (7:30-18:30) + bicycle=yes + psv=yes. The third example is identical to the example on the proposal page (that very sign inspired me). The motor_vehicle=yes tag can be omitted for 'unclassified'. The last example you already corrected. One problem. The 'loading' condition is normally covered by the access value 'delivery'. I would tag it motor_vehicle:conditional=yes @ disabled; delivery @ (18:00-10:00). I'm not sure about the bollard tagging (except from the fact that your time interval is not right). First of all it is only a warning sign, not a restriction sign. Secondly the bollard is probably operated either by an operator via an intercom or by some kind of keycard so we don't know the exact restrictions for it, only that is is always passable 18:00-10:00. I would actually tag it as access=yes for simplicity. The access tags on the highway already define the relevant restrictions. --polderrunner 20:27, 17 September 2012 (BST)

• (Regarding #2) Tourist bus vs. local bus: nitpicking here, but "local buses" and "tourist buses" are not the only bus "categories", at least globally. Some private persons or organisations have private buses, and long distance operators' buses sometimes - at least daily - need to transit between different route endpoints/their depot. Yet they wouldn't be allowed in the second photo. Alv 07:53, 18 September 2012 (BST)

To Alv: I have permitted myself to modify the tagging of your examples a bit. Example 5: motor_vehicle=yes is not needed as that is the default access to residential. The latter two conditions are very obscure and probably never going to be supported by any data consumers (routeplanners etc). I left them as they are, though. Example 6: I changed bus:conditional=yes @ (length > 12) to maxlength:bus=none. Otherwise it might be difficult to evaluate which restriction is valid (humans can figure it out but software might have a hard time). I also changed vehicle:conditional=yes @ (lenght > 12 AND special_permit) to vehicle:conditional=permit_holder @ (length>12). permit_holder is not documented on Key:access but is used a few times according to TagInfo. It should be used similar to private but where a special permission is needed to use a public road (where 'private' is not appropriate). In my opinion the hazmat restrictions could better be defined as conditions. The hazmat:A restriction would then become access:conditional=no @ (Mo-Fr 07:00-09:00,15:00-18:00 AND hazmat:A). But hazmat as key has become quite established so I won't deprecate it with this proposal just offer an alternative as in my opinion hazmat is really a condition. Example 7: Corrected no to none meaning 'no limit'. Feel free to disagree. --polderrunner 20:06, 18 September 2012 (BST)

In fact these are already tagged maxlength:bus=none :), just playing along with the proposal syntax. The obscure ones are in this case almost superfluous, as 'destination' almost sufficiently covers them anyway. I think that access key value space should not be extended any more (permit_holder), and even some of the establised ones (even designated) - or actually their implications - would be best tagged with other keys. Alv 22:46, 18 September 2012 (BST)

Example #7: maxlength:conditional = none @ destination; none @ psv; none @ agriculture; none @ forestry Shouldn't that be maxlength:psv = none and maxlength:conditional = none @ destination; none @ agricultural; none @ forestry? This example indicates that the decision to move the vehicle category into the key - even with the best intention to appreciate current tagging practice and for backward compatibility - is somehow arbitrary and not fully intuitive. We may see a lot of 'slips' like this. --Martinq 21:05, 19 September 2012 (BST)

Of course, I overlooked that one. I didn't create that example, just corrected 'no' to 'none' and failed to spot the odd one out. Should be correct now. --polderrunner 21:28, 19 September 2012 (BST)

AND vs. &

• Changed & to AND in several examples above. Is this an open point for discussion? Or just a common error? --Chaos99 09:11, 18 September 2012 (BST)

I thought I copied it from the previous example :). If it happened already, I believe it will be used "in the wild" sometimes, so parsers ought to be advised to understand that, too, even if only AND is given as the proposed form. Alv 09:44, 18 September 2012 (BST)

Just to be clear. It should be AND according to the proposal. Don't use '&'. Already one opposing vote complaining about 'special signs' so better not add another one :-) --polderrunner 20:31, 18 September 2012 (BST)