Hi All, 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:
* <rule>:<vehicle>=<condition1> <value1>; <condition2> <value2>... Explanation: 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). 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). 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. 4. There would be a limited number of (approved) rules and vehicles => therefore a limited number of tag keys. 5. Condition formats should be pre-approved (e.g. 'wet', 2 letter day types, 24hr clock types, etc.). Examples: * maxspeed=120 * maxspeed:hgv=80 * maxspeed=120; wet 80 * bicycle=yes; 10:00-18:00 no Advantages: 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. Possible issues: 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). 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 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. 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... Regards, Rob p.s. To address some criticisms of my earlier proposal: >Here are some disadvantages of merging everything into a single value: > - readability and ease of manual editing suffers This suffers in any lenthy tag schema. Thr proposal is consistent so editors can be adapted to provide a fantastic GUI. > - you lose backward compatibility The proposal falls back to existing tag schemas therefore providing backwards compatability. > - you don't integrate widely used conditions like forward, hgv, … now fixed > - you run into the (real) risk of exceeding the 255 byte limit imposed on > values That would have to be one hell of a complicated access rule!!
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
