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
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
