[Tagging] Reviving the conditions debate

[Peter Wendorff]

Am 15.06.2012 00:51, schrieb Eckhart Wörner:
> Hi martinq,
>
> Am Donnerstag, 14. Juni 2012, 22:19:06 schrieb martinq:
>> and many other variants. It is almost impossible to tag it wrong.
> I'm sorry, but every time I've heard a statement similar to "you cannot get it wrong" it just boiled down to "the computer cannot tell you that it's wrong". This is the price you pay for mimicking human language, and I'm not sure I'm willing to pay that price.
>
>> However, the author struggled with the same basic problem, e.g. there is
>> a (non-intuitive) difference between using ',' and ';' now.
>>
>> Also, except for a basic time restrictions it is impossible to tag and
>> also difficult to read these expressions. Clearly powerful, but too
>> compressed for casual mappers. Can you read this?
>>
>> Dec 25-Su-28 days - Mar Su[-1]: 22:00-23:00
> I cannot read it for a simple reason: the specification does not tell the meaning of ":" inside that expression. The ":" is defined by an implementation, which just shows the problem of not standardizing properly.
> However, I believe we should not make time domains part of this discussion at all.
>
>> open:cond = yes if time is 10:00-18:00
> Your example suggests that you have a problem with defining what the "if" actually means:
> Does "open:cond=yes if time is 10:00-18:00" tell
> a) open from 10:00-18:00, not open from 18:00-10:00 or
> b) open from 10:00-18:00?
>
>> 2) Value vs. key
>> I think value side conditions would be more intuitive, because the value
>> depends on the condition.
> I think key side conditions would be more intuitive, because the validity of the key depends on the condition. ;-)
>
>> Also, it easier to filter the things in the database, especially if
>> left/right&  forward/backward is also mixed into the conditions (or
>> should we simple go the next step and see them as condition too?).
> The Extended Conditions proposal already treats forward/backward as conditions.
>
>> Normal form is nice to parse - but do you think everybody can map it?
>> Non-normal form is not so nice for machines - thus I cannot promise that
>> I achieve to parse it - and the discussion is theoretical until I can
>> prove it (with reference implementation).
> Except that this kind of normal form is the way signs are written normally (that's why it's called normal form ;-) ), see http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg for an example:
> access:motor_vehicle:(10:00-18:00)=no (first sign)
> access:motor_vehicle:(10:00-18:00):(length<5)=yes (second sign)
>
> (How would you tag this?)
>
> I'm sure that 95 per cent of the time you won't get more than one tag per sign.
>
>> I also see no reason why an application may not be able to treat this as
>> equivalent:
>> hgv = yes    (shortcut for:)
>> access:hgv = yes   (which is a valid expression also in the proposed
>> extension)
>> access:cond = yes [hgv]
> The Extended Conditions proposal treats the first two as equivalent.
> But why do you want to mix two ways of tagging (second + third)? Just for fun?
Well, probably to support different applications that understand 
different subsets only.
The comparison of combinations between amenity and highway I posted 
yesterday (or on Wednesday? not sure) shows that ambiguous tagging on 
the same object often occurs; and it's not the question, if that's 
necessary or not: Sometimes it's "I tag what I know", sometimes it's 
tagging for maximized compatibility.

regards
Peter