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?
