Hi.
I'm a little bit afraid about the discussion here and would like to
point out that a key IMHO should be different than a value.
I like the idea of "namespaces" for keys, to be able to group tags that
belong together, but I think, even namespaced stuff should belong "keylike".
A key access:weight is okay IMHO and can contain weight-related access
restrictions.
access:length, access:time and so on - okay.
but the specific weight a restriction belongs to should be part of the
value, not the key.
It's true: mappers are free to introduce new keys where these are
necessary or wanted; but i oppose to encourage the definition of
placeholder-keys for arbitrary key-strings following a pattern. Let's
code these to the value.
if the KEY structure for access keys get's that complicated alone, the
problem isn't any more users who don't know how to code the value, but
how to code the key itself.
Let's keep keys well defined and as simple as possible (while staying
well defined of course) to keep at least the task of "ignoring
non-understandable tags" easy.
regards
Peter
Am 13.06.2012 14:35, schrieb Eckhart Wörner:
Hi everybody,
I want to revive the discussion on how to tag restrictions that depend on
certain conditions. My idea is to finalize the proposal described in
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
and finally accept it.
The reasons for picking this proposal:
* The proposal mostly describes syntax that is already used for tagging, e.g. a
maxspeed in a certain direction is almost always tagged as maxspeed:forward,
maxspeed:backward
* The proposal is intuitive and simple to use: the key of a tag is the base tag
+ a set of conditions that all have to be true for the key to apply (i.e.
logical AND).
* The proposal is complete: every logical formula of conditions can be
expressed in it (technically, it's pretty similar to disjunctive normal form).
* The proposal is consise: it follows the pattern most dominant with road
restrictions, namely overriding general restrictions with special restrictions.
It normally uses no more than one tag per sign.
* The proposal is extensible: the set of conditions is not fixed and can be
extended to new conditions. It is possible to set a sane default for new
conditions that are experimental.
* The proposal is easily implementable: I implemented it in a prototype already.
The only real negative aspect that has been mentioned until now:
* the proposal puts a lot of information into keys and theoretically allows for an
unlimited set of keys. (The reality however shows that those keys tend to be the same,
e.g. taginfo shows no less than 335 elements with key "maxspeed:(22:00-06:00)").
Competing proposals:
* http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a
horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses
(for example, "maxspeed:hgv:wet" in the Extended Conditions proposal above is
"access:lgv?wet.speed" in the Access Restrictions 1.5 proposal)
Opinions?
Eckhart
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
