[OSM-talk] conditions as part of value/key (was: Re: [RFC] restriction=school_zone (second email))

[Tobias Knerr]

Martin Koppenhoefer wrote
> I can't really see the point of not putting values in keys
> actually. Aren't we already doing this in many tags?
> 
> why is this a value in the key:
> maxspeed:wet=40
> couldn't you interpret "maxspeed:wet" as a key? The maxspeed in wet
> condition? Could you explain the problem that arises (I am not an
> informatics person and maybe for this don't understand these details
> adhoc).

"Pure" keys are commonly thought of as unique identifiers, not subject
to any evaluation. They are often used in data structures that allow
easy access to a value if you know the key (give me the "maxspeed"
information) but are not really designed for any other operations using
keys (give me all tags starting with "maxspeed").

Of course, no one forces you to represent the OSM key/value structure in
your application. I'd also like to point out that using bicycle=yes and
similar tags, rather than access = no; [biycle]yes; [foot]yes (or a
similar solution), is already a deviation from the "pure" approach and
is in no way different from, say, maxspeed:wet.


Basically, we have the following options I know of:

- conditions in keys

This has the advantage that it will not break applications that only
evaluate the "normal" tags, will work with current API and is
relatively easy to edit.

- conditions in values:

Also possible, but means all information of the same category (e.g. all
maxspeeds) will be in a single value, which will result in rather long
tags. It will also break existing applications unless you redundantly
add both "normal" maxspeed and "modernized" maxspeed tags.

- link multiple tags using index in key (such as maxspeed[1]):

Does not result in "pure" keys either, so I don't quite see the point.

- using relations:

Too hard to edit, imo. You may still suggest this if you are
willing to implement support for this in all major editors. ;-)

There is a proposal in "brainstorming mode" (read: vague collection of
ideas) for this, though, but it doesn't seem to make any progress:
http://wiki.openstreetmap.org/wiki/Proposed_features/Access_restrictions

- hierarchical tagging:

Nice but would require major API change. Not possible right now.


The issue of keys vs. values was recently brought up on the talk page of
the "Extended conditions for access tags" proposal, btw:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extended_conditions_for_access_tags#Move_parameters_from_key_to_value

However, I'm still wondering if someone has any *practical* objections
to conditions in keys or if it's just the (understandable) "that's not
really 'key-ish'" feeling.

Tobias Knerr