Hi,
sadly this discussion was restarted before I could establish a reference
implementation for a less technical way of tagging conditional values
(for those who are interested: it is a ANTLR grammar, hopefully with
built-in evaluation code). The reference implementation is for me a key
for acceptance, because the less technical to tag, to more difficult to
parse. And we all agree that it should be possible to parse it - but not
necessarily easy.
Objective of my proposal: As less rules as possible - as close as
possible to the sign-posted information.
The proposal page does not contain a lot of information, because I adapt
the "grammar" based on what is feasible. Sadly cannot spend a lot of
time in continuing with the reference my implementation at the moment.
I will comment based on what I have already figured out:
> - "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.
This is in fact the biggest challenge in the current state of my parser
(in combination with fuzzy & context related precedence). Human language
is sadly not very precise:
"except taxis AND bicycles" does not mean, you must be in a vehicle that
is both (it means if not taxis AND if not bicycles), "except HGV AND
weight>7.5t" is by most humans interpreted differently (if not (HGV AND
weight>7.5t). There are lot of other examples for amgiguities, eg.
"except Fr, 10:00-18:00" does not mean complete Friday and the other
days, etc.
However, in this case the preliminary parser has no problem to
understand following different expressions:
maxspeed:cond = 80 if wet or Sunday
Easy tagging, isn't it?
But the grammar is flexible. Instead of 'if' I also support 'when' and
'[' ']' (I am not sure about the brackets yet - they are clearly not as
intuitive as 'if' or 'when').
maxspeed:cond = 80 [wet]
maxspeed:cond2 = 80 [Su]
Also understood by the parser:
maxspeed:cond = 80 when weekday is Sunday and condition is wet
or
maxspeed:cond = 80 weekday=Su or condition=wet
or
maxspeed:cond = 80 [wet]; 80 on Sundays
and many other variants. It is almost impossible to tag it wrong.
> - Brackets for expressions. If we limit ourselves to just "and"
> operators, evaluation order doesn't matter.
This is something I really want to avoid. Brackets for precedence
purposes are a purely technical artefact and I not seen them on the
signs with the information we want to tag...
However, the *precedence* is the major problem in the current parser.
Thus I don't think I can write a parser without any rule helping the
parser and restricting the mappers. But brackets will just be introduced
if I have no other option.
>> Pseudo-Javascript: (!is_motor_vehicle(vehicle_type)) ||
>> ((vehicle_type='hgv')&& (time<'10:00' || time>'20:00')&&
>> intention='loading')
== side note ==
A assume, this is access related.
Side-note: The current access tags are IMO just abbreviations, nowadays
we would write instead of
hgv=yes --> access:hgv=yes.
With the conditional value proposal it could be tagged as
access=yes if hgv
maxweight=x is an example for (vehicle) access = no if weight>x, even
though it can also be a non-conditional property of an object (e.g. a
bridge may have a intrinsic maximum acceptable weight, but we don't have
to go into details now).
== side note end ==
I interpreted your code as your example as
access=yes
access:cond1 = no if motorized
or "no if motor vehicle" or "no if vehicle is motorized"
access:cond2 = delivery if hgv from 10:00-20:00
or "delivery if vehicle is a hgv and time is 10:00-20:00
or many variants more...
If the evuation part of my parser works (yet I still working on the
grammar), I may also be able to create a kind of "normalized" JavaScript
expression out of the "fuzzy" human tags [but I don't have implemented a
normalized attributed tree yet].
> - defining a syntax for time intervals (opening_hours)
By using on/off, this is already the first tag which moved the condition
into the value. By using off/on, it reads like
off if ...
on if ...
However, the author struggled with the same basic problem, e.g. there is
a (non-intuitive) difference between using ',' and ';' now.
Also, except for a basic time restrictions it is impossible to tag and
also difficult to read these expressions. Clearly powerful, but too
compressed for casual mappers. Can you read this?
Dec 25-Su-28 days - Mar Su[-1]: 22:00-23:00
In this case I would stick to human readable expressions like "last
Sunday in March" and put the load to evaluate it onto the
parser/application.
> - defining a subset hierarchy of vehicle categories (such as
> "motor_vehicle" including "hgv" as a subset)
Applications must know which vehicle you drive to evaluate certain
conditional values (mainly access, speed limits and also parking
conditions). Unlike the current access tags we don't need an hierarchy.
motorized is an attribute of the vehicle, the application must know
about it. Not every taxi is motorized [rickshaws or bicycle taxis], the
attributes for the circumstances of use should be interdependently
determined by the application. The applicaton may use a tree internally,
but I don't think its the mapper's job.
For a standard taxi a application may work with following attributes:
taxi = yes
weight = 2t
motorized = yes
width = 2m
length = 5m
height = ...
permits = A38, A39
public service = yes
[however, if the taxi is empty, this attribute may be no]
passengers = 2
sex = male
age = 55
engine power = 22PS
vehicle maxspeed = 180
colour = black
etc.
[I hope the concept is clear]
Independent from that does the application also require knowledge about
date & time for certain conditions - and the application may need to
know the weather, holidays, purpose of travel (or intention),
destination of travel (especially in my area several access restrictions
depend on the area you driving to).
The mappers no longer have to worry about interdependencies between such
attributes, e.g is a rickshaw a motor vehicle or a bicycle or just a
pedestrian with a trailer? (It can be all).
Now, whenever some properties are not known, the application simply
cannot evaluate all conditional value. Either the application can accept
this and continues with the safety value (e.g. no for access, lowest
speed for maxspeed, etc.) or may have to ask the user (e.g. user can
select if the bicycle map or the motor vehicle map should be shown).
> 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.
1) I dislike proposals which try to solve only the situation for access
access is a tag like any other - and we shouldn't re-invent the wheel:
access:cond = yes if time is 10:00-18:00 (or simply yes [10:00-18:00])
maxspeed:cond = 80 if time is 10:00-18:00
parking:lane:left:cond = parallel time is 10:00-18:00
open:cond = yes time is 10:00-18:00
or - simply to emphasize the concept -
access:cond = yes if female
maxspeed:cond = 80 if female
parking:lane:left:cond = parallel if female
open:cond = yes if female
The extended access proposal can be used for any tags, thus no issue here:
access:hgv:(20:00-10:00) = ...
maxspeed:hgv:(20:00-10:00) = ...
parking:lane:left:hgv:(20:00-10:00) = ...
...
2) Value vs. key
I think value side conditions would be more intuitive, because the value
depends on the condition.
Also, it easier to filter the things in the database, especially if
left/right & forward/backward is also mixed into the conditions (or
should we simple go the next step and see them as condition too?).
Disadvantage is that values can contain any characters. This makes it
hard to identify the start of the condition in a parser.
3) The extended access proposal:
> motor_vehicle = no
> hgv:(20:00-10:00):loading = yes
Normal form is nice to parse - but do you think everybody can map it?
Non-normal form is not so nice for machines - thus I cannot promise that
I achieve to parse it - and the discussion is theoretical until I can
prove it (with reference implementation).
I also see no reason why an application may not be able to treat this as
equivalent:
hgv = yes (shortcut for:)
access:hgv = yes (which is a valid expression also in the proposed
extension)
access:cond = yes [hgv]
Then backward compatibility, extended condition tags or value side
conditions could be used. If applications need a parser anyway...
martinq
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
