On 14/06/2012 11:19, Pieren wrote:
On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale <colin.sm...@xs4all.nl> wrote:
Back to my idea to move all 'variables' to the value :
Let say we create a new access keyword : "condition" (or
"access_condition", "cond", "expr" or "whatever_you_like") suffixed by
a number, eg. condition1, condition2, etc (unlimited but easy to
parse; separator unnecessary).
Then conditions are combined using a plain text language, not using
||, &&, ~, $ or any symbols only known by software programmers
(important for readability by wide audience) eg. " and ", " or ", "
not ", " in " like SQL.
I fully agree that the complexity should be principally in the value,
not the key.
Sounds good. I think parentheses (or some equivelent) will still be
necessary however for grouping, so you can say "A or (B and C) or D" as
"A or B and C or D" would not do the right thing (using conventional
precedence rules). As I understand it you are proposing that the
operands be variables (syntactically speaking). It's only a small jump
from there to allow literals, and add a couple of operators like
equals/not equal/greater than etc. Like that the definition of the
conditions as separate tags could be redundant in many cases, but it
would allow for reuse of common subexpressions.
I am sure that users will be able to get their head around something
like this - I hope so, because they will have to. The users will have to
learn a new trick anyway, whether it be this expression syntax or the
"access 1.5" proposal or its competitors. Which approach will give least
problems? Can they be understood unambiguously by humans and computers?
Or are we going to get lots of "bad data" due to people
misunderstanding/misinterpreting the rules? The set of operators is
limited (basically just comparison operations plus and/or/not), and the
editors can support the users by presenting the logic represented by the
expression in some kind of more natural language if required.
Examples:
Here's a test case. No motor vehicles mon-fri between 1600-1800 except
agricultural vehicles and good vehicles *in this direction*. Going the other
way the sign is similar but the times are between 0600 and 0900.
access=yes (this implies "agricultural=yes" and "goods=yes")
condition1=Mo-Fr 16:00-18:00
condition2=Mo-Fr 06:00-09:00
motor_vehicle:forward=not condition1
motor_vehicle:backward=not condition2
I think there should be an explicit way of identifying condition1 and
condition2 as "time constraints". There will also be conditions based on
other dimensions such as weight, length, etc.
no motor vehicles except for loading/unloading by hgvs between 8pm
and 10am
access=yes
motor_vehicle=no
condition1=loading // improving current 'destination'
condition2=10:00-20:00
hgv=condition1 and not condition2
Short, readable and easy, no ?
Definitely readable. Could be shorter. Easiness is a rather subjective
measure. How do these alternatives score?
motor_vehicle:expr=(vehicle_type=="hgv") &&
((time>"20:00")||(time<"10:00")) && (intention=="loading")
motor_vehicle:expr=(vehicle_type="hgv") and ((time>"20:00") or
(time<"10:00")) and (intention="loading")
One small point though: "loading" is not the same as "destination",
although this may vary by jurisdiction. You can't park in a parking bay
marked for "loading" just because you want to visit someone nearby.
Pieren
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
