[OSM-talk] keys

[Etienne]

On 6/12/06, Immanuel Scholz <immanuel.scholz at gmx.de> wrote:
>
> 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.


Sorry, not intending to be sarcastic at all.  Having re-read, I cannot see
what makes you think there is any sarcasm in what I have written...

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.


I think the users (us) are finding that the lack of any structure is
becoming a bit of a problem.  See previous discussions about UK centric
schemes, highway=autobahn, etc.  I think this initiative is not about some
complex programming changes but more about the users doing some
self-organising using the tools they have already got.  I really like the
lack of any *enforced* structure, but I also see that there are benefits to
several users sharing a common scheme - that is all that is happening.

But: Some of your ideas were thought before ;-).


Where?

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.


Can you give an example? I don't understand what you mean by "keywords can
have keywords".


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.


No, it's not a good idea.


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.


Yes, we do need namespaces (or an equivalent mechanism).  Otherwise clients
will misinterprete tags.  Right now any way that has a tag class=secondary
will be interpreted by some client as *a secondary road*.

Someone in a recent thread, proposed a scheme that used a combination of
type and class. The example they gave was type=rail, class=secondary to
describe a minor railway line.  This is a perfectly good scheme if used in
isolation, but any of the current clients that see a way tagged like this
will interprete it as a secondary road.  The two schemes are not mutually
exclusive.  That is why we do need namespaces or some equivalent mechanism.




Ciao, Imi
>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20060612/cc0590bb/attachment.html>