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