[Tagging] Extended Conditions - response to votes

[Eckhart Wörner]

Hi everybody,

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 [1] 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 
with access.

Eckhart

[1] http://eckhart-woerner.de/~eckhart/extcond.html