Let's take a step back and look at what the discussions in this thread
have actually been about.
There's a lot of discussions about possible solutions, without much
analysis of "the problem". 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. If the human
aspect was primary, then using a free-text field would be enough as
humans are capable of incredible inference - something which "normal"
computers still find challenging. This is about structuring the
information, so that it is clear what is what. Editors can be extended
with an expression builder and for advanced users they can be taught to
check the syntax before comitting a change. This is of course also true
for the tag-based suggestions being discussed elsewhere in this thread.
I can see it being rather challenging to find a way of getting the
editors to keep up with the tagging if the rules have to be hard-coded
because there is no proper definition of the grammar for these complex keys.
Next point is that we really shouldn't be spending all our time
discussing which delimiter to use and other similar aspects of the
physical representation of the data. These discussions take no time at
all if we simply adopt an existing solution for that part of the
problem. We are all mappers and should be discussing mapping issues,
like modelling real-world constructions, knowing that getting it right
will give years of pleasure and getting it wrong will mean
I deliberately suggested a "javascript-compatible syntax"and NOT
"javascript". There is such a thing as overkill...
How about those examples then? Well, I didn't actually want to let
myself get dragged into the current discussion. I am making an attempt
to change the level of the discussion, to get it out of the
beauty-contest mode and into requirements analysis mode. It is also not
my intention to rubbish any of the current proposals as they have all
been made by clever people in good faith. I just want to put a different
angle on the discussion.
Having said that, these are some real-world examples that sprung to
mind. I apologise in advance for any typos - this was typed in on the
fly without any checking. This is not to say that "my ideas are the only
good ones" - only to demonstrate that there are other viable ways of
approaching this.
1) no right turn for hgvs with length > 7.5m (on turn restriction
relation - assume restriction only applies if expression is true)
Pseudo-Javascript: (vehicle != 'hgv') || (length<'7.5m')
XML:
<or>
<condition>
<var id="length" />
<operator><</operator>
<value>7.5m</value>
</condition>
<condition>
<var id="vehicle_type" />
<operator>!=</operator>
<value>hgv</value>
</condition>
</or>
2) max weight 10t except for buses (assume access only if expression is
true)
Pseudo-Javascript: (weight<'10t') || (vehicle_type='psv')
XML:
<or>
<condition>
<var id="weight" />
<operator><</operator>
<value>10t</value>
</condition>
<condition>
<var id="vehicle_type" />
<operator>=</operator>
<value>psv</value>
</condition>
</or>
3) no motor vehicles except for loading/unloading by hgvs between 8pm
and 10am
Pseudo-Javascript: (!is_motor_vehicle(vehicle_type)) ||
((vehicle_type='hgv') && (time<'10:00' || time>'20:00') &&
intention='loading')
XML:
<or>
<condition>
<not>
<call function="is_motor_vehicle">
<param>
<var id="vehicle_type" />
</param>
</call>
</not>
</condition>
<condition>
<and>
<condition>
<var id="vehicle_type" />
<operator>=</operator>
<value>hgv</value>
</condition>
<condition>
<call function="time_in_range">
<param name="input">
<var id="time" />
</param>
<param name="start_time">
<value>20:00</value>
</param>
<param name="end_time">
<value>08:00</value>
</param>
</call>
</condition>
<condition>
<var id="intention">
<operator>=</operator>
<value>loading</loading>
</condition>
</and>
</condition>
</or>
4) speed limit is 80, except for thursdays in september when it is 100
(returns an integer)
Pseudo- Javascript: if((weekday(date)==THURSDAY) && (month(date)==9)
{return 100;} else {return 80;};
OK, I admit this one is a bit contrived, but it serves to illustrate the
way this technique could be used in other ways. I will leave the XML
representation as an exercise for the reader...
Colin
On 13/06/2012 21:16, Martin Vonwald wrote:
Am 13.06.2012 um 20:47 schrieb Colin Smale <[email protected]>:
my sarcasm detection seems to be broken - are you seriously suggesting
JavaScript or XML? Or are you suggesting that the proposal is too complex?
Yes, yes, and yes.
Is your first yes referring to JavaScript or the sarcasmus detector?
No, seriously: would you provide some examples?
Martin
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
