On 14/06/2012 13:00, Tobias Knerr wrote:
On 14.06.2012 08:38, Colin Smale wrote:
My concern with this is that it may become unwieldy and cumbersome with
anything beyond fairly trivial cases such as your maxspeed example.
For me, the goal is to make the common cases *easy*, and the rare
complex cases *possible*.
Difficult to argue with that! The second part makes a flexible grammar
essential, as you cannot predict what these rare complex cases might
look like.
It's far easier to build a visual editor if you only need to support a
limited subset of boolean logic. For example, the "filter" editor in
my mail client (Thunderbird) is limited to a subset of boolean logic
as well, for the same reason.
Sure, it's limited to match all/match any and a fixed list of operators.
But Thunderbird is not trying to represent something in the physical
world here, only to help the user.
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.
What would this look like using only AND operators?
motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural
At first glance this looks like a motor vehicle going "forward" between
those times is considered "agricultural". It doesn't feel very
intuitive, based on the established key=value paradigm.
I thought of the following, based on the premise that the class
"motor_vehicle" can be partially overridden by a subclass such as hgv or
agricultural:
motor_vehicle=yes
motor_vehicle:forward:(Mo-Fr 16:00-18:00)=no
motor_vehicle:backward:(Mo-Fr 06:00-09:00)=no
hgv=yes
agricultural=yes
Colin
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
