[Tagging] Extended Conditions - response to votes
ewoerner at kde.org
Wed Jul 4 19:36:25 BST 2012
the vote is fully underway, and some contra arguments are repeated over and
over again, and I feel the need to address some of them in more detail:
1. "constant keys is a fundamental rule in OSM"
If such a rule actually exists, it has never been written down, at least I
couldn't find any hints in the wiki, it has only been mentioned as an argument
to shoot down this proposal. The wiki states:
> Tags, consisting of a 'Key' and a 'Value' can be associated with either
> elements (nodes, ways and relations) or changesets. Both the key and value
> are free format textual fields, although in practice there are agreed
> conventions of how tags are used for most common purposes.
Now one may argue that this rule has been established just by not using
"variable keys" until now. This argument is flawed in two ways:
First of all, there is plenty of precedent: the (old) TMC scheme uses variable
keys extensively, the source base key uses variable keys (source:<key> has
<key> as variable), to my knowledge OpenSeaMap uses them for lights, etc.
Also, the argument is broken: not having done something in the past is not an
argument by itself for not doing something in the future.
However, let's have a look at some alternatives:
a. Use maxspeed:condition<X>=<condition>, maxspeed:valueX=<value> (or
something similar), where X is a number: first of all, the key is also a
variable, which violates the constant key "rule" the same way. Second, one
could easily argue that from a semantic POV this is even worse, since only the
combination of keys gives a key its meaning. With the extended conditions
proposal, I could easily setup a wiki page Key:maxspeed:(22:00-06:00) and
define the exact meaning of this single tag (whether such a page is actually
useful is a different topic).
b. Merge all conditions and all possible values into one value, i.e.
maxspeed=<complex expression> or access=<complex expression>
First of all, "complex" expressions are actually complex, people inevitably
will get them wrong. More importantly, one can quite easily exceed the 255
byte limit for tag values.
2. "[the new tagging scheme is] unusable for data consumers (or not without
huge impact on performances)"
The tagging scheme is pretty simple to implement; just match all tag keys
against /^access(:.*)/, sort all matching tags according to their specificness,
and skip less specific tags accordingly. Here  is a simple implementation
that evaluates maxspeed in less than 100 SLOC, the only thing that makes
access more difficult is because there is a lot of keys that are not prefixed
More information about the Tagging