[Tagging] Reviving the conditions debate

[Colin Smale]

Tobias, thanks for your constructive response.

On 14/06/2012 03:22, Tobias Knerr wrote:
> On 13.06.2012 23:48, Colin Smale wrote:
>> Taking the access discussion to a higher
>> level of abstraction, and without abandoning the key-value pair
>> paradigm, I believe we are looking for a way of giving a tag a value
>> which "depends" on all kinds of "variables". *IMHO* we need a way of
>> making expressions, with operators to combine basic values in different
>> ways. These basic values might be literals, other tags, runtime values
>> or function calls. These functions might be built-in (or assumed) for
>> the most basic stuff, but it would be good if we could define additional
>> "user-defined" functions.
>>
>> Whatever syntax is used, the *primary* requirement is that it is
>> "usable" by programs - editors, renderers, routers etc. followed by a
>> secondary requirement that it be understood by humans.
> Any condition syntax needs to be parsed by programs, this much we should
> all be able to agree on.
>
> As for the secondary requirement, I think that keeping the number of
> different basic constructs small can help a lot. The resulting
> micro-language can then be easier to read, and also easier to wrap into
> a GUI than a language construct that gives the user a lot of freedom.
>
> So when we talk about requirements, we should also consider whether
> there are things we _don't_ need.
Fully agree.
> And imo there are several, such as:
>
> - "Or" operators. "Maxspeed is 80 if it's wet or Sunday" can be
> rephrased as "Maxspeed is 80 if it's wet. Maxspeed is 80 if it's
> Sunday." IOW, these can be modelled by using two tags instead of one.
>
> - "Not" operators. These can also modelled by using two tags, and common
> tagging idioms like access=no + x=yes even do this already.
>
> - Brackets for expressions. If we limit ourselves to just "and"
> operators, evaluation order doesn't matter.
My concern with this is that it may become unwieldy and cumbersome with 
anything beyond fairly trivial cases such as your maxspeed example. Then 
the debate will erupt again, and PhD's in boolean algebra will point out 
that it *can* be done... In the mean time everyone has to learn a new 
grammar and mistakes will be made. "and", "or" and "not" are the 
building blocks of boolean logic and are easily understood by computers. 
For the human audience who can't grasp it yet there are millions of 
books and websites. The way it is presented in map editors will be 
extremely critical in any case. Also, let's not forget to peek beyond 
the boundaries of the current discussion about "access" (i.e. routing) 
to see how the conclusion here would fit in other domains.

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. 
This is a short stretch of narrow road and the restrictions are intended 
to stop commuters using it as a rat-run, while at the same time allowing 
work to carry on as usual on the farms and businesses along that road.

     http://goo.gl/maps/ymvt

motor_vehicle:forward:expr=vehicle_type=="agricultural" || 
vehicle_type=="goods" || weekday == SATURDAY || weekday == SUNDAY || 
time<"16:00"|| time>"18:00"
motor_vehicle:backward:expr=vehicle_type=="agricultural" || 
vehicle_type=="goods" || weekday == SATURDAY || weekday == SUNDAY || 
time<"06:00"|| time>"09:00"

What would this look like using only AND operators?

>> Pseudo-Javascript: (!is_motor_vehicle(vehicle_type)) ||
>> ((vehicle_type='hgv') && (time<'10:00' || time>'20:00') &&
>> intention='loading')
> So starting from your Pseudo-Javascript example quoted above,
> we could get to something like
>
> is_motor_vehicle(vehicle_type) -> no
>
> (vehicle_type='hgv') && (time<'10:00' || time>'20:00') &&
> intention='loading') -> yes
>
> It has fewer language constructs, but expresses the same thing - and
> still fulfils all the requirements.
>
>
> Another aspect to consider is that some of the problems we are trying to
> solve here have already been tackled elsewhere in OSM. This includes:
>
> - defining a syntax for time intervals (opening_hours)
> - defining a subset hierarchy of vehicle categories (such as
> "motor_vehicle" including "hgv" as a subset)
>
> Probably it would make sense to re-use these existing building blocks.
> This could be done with a small change to the example above:
>
> in_vehicle_category('vehicle_type') -> no
>
> in_vehicle_category('hgv') && in_time_interval('20:00-10:00') &&
> intention='loading') -> yes
>
>
> So how do the existing proposals fit in here? Well, the primary
> difference between the example above and "extended conditions" is that
> the latter aims for for short, manually editable strings by letting
> literals for vehicle classes, weather conditions etc., as well as time
> intervals, stand for themselves - based on the assumption that a parser
> will be able to unambiguously identify them.
>
> If we chose to do this for our returning example, it might look like this:
>
> motor_vehicle -> no
> hgv && 20:00-10:00 && loading -> yes
>
> And that differs from "extended condition" just in superficial details:
>
> motor_vehicle = no
> hgv:(20:00-10:00):loading = yes
>
>
> Maybe this explains some of the motivations behind the current
> proposals, and the goals and assumptions and they are based on. Because,
> yes, understanding these high-level motivations is a necessary first step.
>
> Tobias
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging