[Tagging] Reviving the conditions debate

martinq osm-martinq at fantasymail.de
Thu Jun 14 21:19:06 BST 2012


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



More information about the Tagging mailing list