[Tagging] Reviving the conditions debate
Colin Smale
colin.smale at xs4all.nl
Fri Jun 15 07:07:27 BST 2012
Hi Eckhart,
On 15/06/2012 01:08, Eckhart Wörner wrote:
> Hi Colin,
>
> Am Freitag, 15. Juni 2012, 00:24:18 schrieb Colin Smale:
>> "If I were king" I would be looking for a system that:
>> * makes common cases easy
> Extended conditions: ☑
>
>> * makes complex cases possible
> Extended conditions: ☑
>
>> * makes each rule as standalone as possible (one sign -> one rule)
> Extended conditions: ☑
>
>> * does not rely on the user's fluency in English grammar (knowledge of a
>> set of specific words, e.g. tags and functions, is fine)
> Extended conditions: ☑
>
>> * uses grammatical constructions which are familiar to most people, or
>> easily learnt
> Extended conditions: ☑
>
>> * has a grammar allowing for a user-extensible function repertoire
> Extended conditions: ☑
>
>> * allowing user-defined functions to be stored in an external file
>> (accessible at entry and run time)
> I'm not sure I get that one, but it sounds to me like you're trying to mix specification and implementation, which is just a bad idea.
You might be right about this. Of course it would be best to only use
the specification at entry time. What I had in mind was the ability to
share functions with the world without having them replicated millions
of times through the database, which is what will happen if you put a
"function" in a tag so you can reuse its value. Using an external file
(i.e. not in the database - analogous to how mapnik/mkgmap style sheets
are handled) will also not impose any standards on anybody so as not to
anger a significant majority of OSM users. Editors can pick the files up
dynamically and use what they choose to use. Maintaining a strict
division between specification and implementation would require some
kind of packaging. Languages like perl and python allow pre-compiled
packages, but they also allow you to share scripts and execute them
directly.
>
>> * fits comfortably with the key-value-pair paradigm of OSM
> Extended conditions: ☑
>
>> * can produce a result in a variety of data types including at least
>> boolean, number, string
> Please provide a use case.
The bulk of the discussion up to now has been about "access" type tags,
producing a boolean value: can I or can't I use this road under the
given conditions. Why limit it to boolean? Why not address the use case
of "what is the maximum speed for vehicle X under these conditions"
(returning a number) or "what are the opening hours of this amenity on a
given date" (returning a string which can be parsed as a date, or
returning an object containing some more date objects if you want to go
further)?
>
>> * can use the value of other tags as variables
> That's just a desaster waiting to happen.
Why do you think that would be such a disaster?
>
>> * can use other variables supplied at run time (e.g. weather, time,
>> vehicle type)
> Extended conditions: ☑
>
>> * supports the usual comparision and numeric operations
> Which "usual" comparison operations? '12 knots' < '35 mph' ?
The comparison operator here is "<" which is definitely "usual". Thanks
for adding "unit conversions" to the list!
>
>> * supports string concatenation operation
> name = (lang == 'de' ? 'Bahnhof von ' : 'Gare de ') + 'Lyon'
> Please provide a use case.
Well, this specific example is already adequately covered in current
tagging practise (name:fr=Gare de Lyon). It's more for completeness - if
it wasn't there, I am sure someone will miss it. I wouldn't like us to
paint ourselves into a corner by only supporting boolean operations.
I wonder if this discussion could also be useful to the "lanes"
discussion in some way? Use cases for routers like "how many lanes does
this road have", "am I allowed in lane 2" etc etc also need to be
"dynamic" and show a lot of similarity to the basic road-level access
business.
>
> Eckhart
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
More information about the Tagging
mailing list