[OSM-talk] keys

[Andy Robinson]

Help me out here a little imi.

I'm back in "class" and as a pupil I need to learn ;-)

You have always used the word "class", would I be right in thinking that's
more to do with data and coding than to do with maps? (other than perhaps
classifying the importance of that road say).

Since it is the editors (and not necessarily the coders) who are trying to
find the way to input data in a format that others can more easily use, what
is the best practice that we can use that speaks in map terms?

I'm not trying to be difficult here, just need to cross over a bit to your
mind.

Cheers,

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 16:11
>To: talk at openstreetmap.org
>Subject: Re: [OSM-talk] keys
>
>Hi,
>
>> 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?
>
>The usual channels. Mailing list, wiki, IRC.. I mean - coders already
>thought about possible needs of organizing the keys a bit.
>
>
>>> 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".
>
>Currently, only Nodes, Segments, Ways (and Areas) are "first class
>objects", which mean, you can attach key/values only to this.
>
>It was an original idea to give the user the possibility to attach
>key/values to Keys. (Ok, the REALLY original idea was only to have
>'keywords' and to be able to attach keywords to keywords. But it comes up
>to the same).
>
>Having this, a user can attach for example the key/value
>"possible_values=major,minor,highway" to "class". An other example is to
>attach "class_icon=http://foo.bar/baz.jpg" to the key "church"
>
>A client can then read out this values and decide to pre-fill a combobox
>which selects from a "class" with the values "major", "minor" and
>"highway". Futher, the client could display the URL for every node which
>has the class=church.
>
>
>To summarize, the "key/values for keys" is just a simple way of using
>existing API's to implement a *distribution* of ontology. It is not better
>in actually defining that ontology than any other scheme you can quickly
>come up with ;-).
>
>
>
>
>Some things to keep in mind:
>
>- You will never have *no* misinterpretation. I strongly suggest than you
>do not make applications that depend on "no wrong data" to work except:
>- If you really make an application that has to enforce some scheme (e.g.
>routing applications), then you should always add a proxy which filter out
>and preprocess your data (as gpsdrive does).
>
>
>Ciao, Imi
>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk