[Tagging] Reviving the conditions debate

Colin Smale colin.smale at xs4all.nl
Thu Jun 14 11:12:28 BST 2012


On 14/06/2012 11:19, Pieren wrote:
> On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale <colin.smale at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging





More information about the Tagging mailing list