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. 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.
> 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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
