[OSM-talk] keys

Andy Robinson Andy_J_Robinson at blueyonder.co.uk
Mon Jun 12 15:48:57 BST 2006


Imi,

This seems to boil down to:

1. No structure to keys or values - anything goes aka flickr - and therefore
not much different than where we are now.
2. A registry approach that provides additional information for keys (and
values?) to be interpreted - (Is that the correct interpretation? I could
use some more info on how this works in practice - or was it documented
somewhere?).
3. Expanding keys and values, each key and value potentially containing more
than one piece of information... sounds ugly.
5. Something else even more complicated.

Being an advocate of KISS, I would prefer the first method, but that does
not address the real requirement for different users to want to use the same
key for different purposes. The "name" key being a good example. Nor for
situations where we currently use separate keys in combination to mean
something different to the individual keys. As users it's a lot easier to
select from a shorter set of keys than to create an ever expanding longer
set.

There was a fair amount of flak emanating from the list last week about
limitations of the "map features" / "class" approaches. I'm happy with my
map features approach at the present time, but that's not to say it's the
best approach for the project or for all newcomers.

So I want it to remain a simple method that is easy to understand and use
but clearly there is a benefit in improving the structure or the validation
of at least the keys.

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk 

>-----Original Message-----
>From: talk-bounces at openstreetmap.org [mailto:talk-
>bounces at openstreetmap.org] On Behalf Of Immanuel Scholz
>Sent: 12 June 2006 14:08
>To: talk at openstreetmap.org
>Subject: Re: [OSM-talk] keys
>
>Hi,
>
>
>> ...
>> XML namespaces...
>> an optional prefix...
>> <tag k='mf:highway'> v='secondary'/>...
>> tags from more than one namespace...
>> mountain road might be a ski piste during the winter...
>> opm:piste=green...
>> allow namespaces to have some structure...
>> mf.us:highway=freeway, mf.de:highway=autobahn...
>> lookup table or registry...
>> unregistered namespace...
>
>I know, you all will hate me for this comment, but: At first read I
>thought you are sarcastic.
>
>Well, I think your idea is to complex to bother with. Sometimes I even
>think the original idea of not having "keys" and "values" thing but
>letting the user enter some keywords without any structure (flickr) might
>be better.
>
>
>
>But: Some of your ideas were thought before ;-). To have a "registry",
>where some metainformation about the data is stored was part of the
>key/value design from beginning. The idea was that keywords can have
>keywords and so clients are able to read out these keywords and interprete
>them by themself.  Together with a special keyword which is
>per-user-defined, this is a simple yet powerful enough scheme to handle
>"registries". Alternatives for keys can be handled as well (value to the
>key "alternative" of another key)..
>
>The absolutly best thing about the "keys have keys"-stuff is: People who
>don't like the complexity can just ignore it.
>
>
>The namespace idea came up before by just specifying "foo/bar/baz" as
>keyword. Alternative values were suggested to be used as
>"value1,value2,value3" once before some month ago. However, I don't like
>this ideas much.
>
>
>So do we REALLY need alternative, namespaced, hierarchy ordered, registry
>stored key-lists? The fastest, most robust and most performant
>implementation of a feature would be to just sacrifice the feature and
>live without it.
>
>Ciao, Imi
>
>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk







More information about the talk mailing list