Hi All,<br><br>I've been thinking a bit more about this and would like to improve on my initial thoughts from yesterday. So expanding on the existing opening_hours type tag, I would like to suggest the following format for extended access tags:<br>
<br> * <rule>:<vehicle>=<condition1> <value1>; <condition2> <value2>...<br><br>Explanation:<br>1. <rule> can be 'access', 'maxspeed', maxweight', etc.. Default value is 'access'. This means that if <rule>: is omitted the extended tag falls back to the current use (e.g. hgv=destination).<br>
2. <vehicle> is the transportation types given on the current wiki page. If omitted the rule applies to all transportation types (this is the current use).<br>3. The <condition> <value> takes inspiration from the opening_hours tag (e.g. opening_hours=Mo-Sa 08:00-18:00; Su off - here "Mo-Sa" is condition 1, 08:00-18:00 is the value, etc..). If condition 1 is omitted then value1 is assumed to be the default value for the tag key.<br>
4. There would be a limited number of (approved) rules and vehicles => therefore a limited number of tag keys.<br>5. Condition formats should be pre-approved (e.g. 'wet', 2 letter day types, 24hr clock types, etc.).<br>
<br><br>Examples:<br>* maxspeed=120<br>* maxspeed:hgv=80<br>* maxspeed=120; wet 80<br>* bicycle=yes; 10:00-18:00 no<br><br><br>Advantages:<br>This proposal has a limited number of tag keys (both rule and vehicle) have to come from an 'approved' list. The format is already in use in the open_hours tag, and is as easy to understand as any other extended schema. The format also falls back to match existing tag usage.<br>
<br><br>Possible issues:<br>1. How to include 'forward', backward' - possible solutions include (a) <rule>:<vehicle>:<direction>=... (b) <rule>:<direction>:<vehicle>=... (c) <rule>:<vehicle>=forward <vlaue1>; backward <value2>. The issue with (c) is that it may require pairing with other conditions - e.g. "bicycle=yes; backward+10:00-18:00 no" (bicycles allowed except in a backward direction between 10am and 6pm).<br>
<br>2. What if the condition is "Mo-Fr 10:00-16:00"? This would break the format of a space character separating <condition> <value>. Possible solutions include using brackets, or using a different character to separate the condition from the value. For example (a) bicycle=(Mo-Fr 10:00-16:00) no (b) bicyle=Mo-Fr 10:00-16:00?no<br>
<br>3. Maxweight except for access might be a bit tricky, but thinking about it you have the condition "destination" having no restricted maxweight. So we can therefore use "maxweight=5.5; destination unset" (which reads that there is a maxweight of 5.5t, with no maxweight restriction when using the road for 'destination' access.<br>
<br>4. Order of the condition value pairs. These should be seen as building blocks -> condition 1 holds true unless condition 2 overrides it, which in turn is true unless condition 3 overrides it...<br><br>Regards,<br>
Rob<br><br><br>p.s. To address some criticisms of my earlier proposal:<br><br><pre>>Here are some disadvantages of merging everything into a single value:
> - readability and ease of manual editing suffers<br><br>This suffers in any lenthy tag schema. Thr proposal is consistent so editors can be adapted to provide a fantastic GUI.<br><br>> - you lose backward compatibility<br>
<br>The proposal falls back to existing tag schemas therefore providing backwards compatability.<br><br>> - you don't integrate widely used conditions like forward, hgv, <br><br>now fixed<br><br>> - you run into the (real) risk of exceeding the 255 byte limit imposed on values</pre>
That would have to be one hell of a complicated access rule!!<br>