[Tagging] Reviving the conditions debate

[Peter Wendorff]

Am 15.06.2012 16:29, schrieb Eckhart Wörner:
> Hi Peter,
>
> Am Donnerstag, 14. Juni 2012, 13:10:44 schrieb Peter Wendorff:
>> A key access:weight is okay IMHO and can contain weight-related access
>> restrictions.
>> access:length, access:time and so on - okay.
>>
>> but the specific weight a restriction belongs to should be part of the
>> value, not the key.
> The problem is that different restrictions combine different conditions that may exist more than once. E.g. there are roads where access restrictions depend on several different weights, different times, and any combinations of them. access:length, access:time, … is by no means sufficient.
Why is it a problem?
If - as some of you here discuss currently - introduce a really complex 
grammar for access values nevertheless, why not doing it a little bit 
more complex to put everything in one tag?
If it's already hard to understand as 
complicated:tag:with:conditions:and:whatever=complicated:value, then why 
not doing a simplekey=set:of:complicated:conditions:values?

The opening hours key IMHO is manageable by humans for the "usual" case. 
It get's difficult already when dealing with seasons (summer different 
from winter, holidays, days before holidays and so on), I fear, too 
difficult for some people - but well, let's accept that.
At least it's one tag, and a mapper may decide not to touch that one tag.

To introduce variable tags is worse:
* For mappers the attribute list get's long, and I have to ignore more 
tags than before.
* For common data usage applications like osm2pgsql, osmosis and so on 
filtering has to be done on substring operations on keys - much more 
complex than on whole keys only, to deal with exceptions; while a value 
is a simple string that can (for the first run) simply be copied.
* Tags relying on each other (as proposed somewhere in this thread as a 
matter of "use other tags as variables") is error prone
* Software that put's different attributes into different columns of a 
table (like, but not restricted to mapnik) for easier search and index 
functionality has to introduce more - and even worse: variable table 
columns to support this tagging scheme. On the other hand one tag with a 
incredible complex value grammer could be used simply by copy and paste, 
and, if necessary, interpreted and processed to fill different columns 
or even tables by that interpretation step (e.g. a timetable for opening 
hours or sth. like that).

To conclude: I really don't see any benefit in creating variable keys 
over creating fixed keys with a variable, slightly more complex 
(compared to the already complex one) value scheme.

regards
Peter