[Tagging] Extended tagging schema - my thoughts
rob.j.nickerson at gmail.com
Fri Aug 10 15:47:23 BST 2012
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
* <rule>:<vehicle>=<condition1> <value1>; <condition2> <value2>...
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
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.).
* maxspeed=120; wet 80
* bicycle=yes; 10:00-18:00 no
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.
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...
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
> - you don't integrate widely used conditions like forward, hgv, …
> - 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!!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging