[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