[OSM-dev] Using relations (or NoSQL?) to save data

[Andreas Kalsch]

Am 06.05.10 16:36, schrieb Roland Olbricht:
> Am Dienstag, 4. Mai 2010 22:12:02 schrieb Andreas Kalsch:
>    
>> I am still reading some old mailing list posts ...
>>
>> What about a relation with type="data", which is a relation that can
>> include tags and other relations recusively?
>>      
> It is a really good idea to store definitions of tags directly into the
> database, but relations leave some drawbacks open:
>
> - A description might easily surpass 255 characters. Or you might want to use
> markup (e.g. for a link or for emphasizing things).
>    
Right, so what about dropping this limit? Even better for OSM data as well.
> - Often tags apply only to a part of the world. Or, even worse, do have
> different meanings in different part of the worlds. Think of different
> maxspeed restrictions on motorways in different parts of the world.
>    
But tags and value are global, semantics can vary, of course. This is 
our job: to describe a tag depending on language / country / ... so that 
everybody will understand it by reading the right description appended 
by a country or language code.
> I'd encourage you to start using those relations now but we should have a more
> versatile solution with the next API. See
> http://wiki.openstreetmap.org/wiki/API_v0.7#Classes
>    
It seems that the class feature was suggested mainly for the purpose of 
storing tag descriptions. So isn't it unnecessary work to define an own 
feature instead of reusing relations and dropping the length limit? 
Additionally, to include a bounding polygon is a bad idea. It's better 
to reference the relation ID of the multipolygon. Example in OSM XML:

<relation ...>
   <tag k="type" v="data"/>
   <tag k="class" v="CountryCodeToFeatureMapping"/>
   <member member_class="relation" member_id="12345" role="de"/>
   <member member_class="relation" member_id="23456" role="fr"/>
</relation>

<relation ...>
   <tag k="type" v="data"/>
   <tag k="class" v="ValueDef"/>
   <tag k="key" v="highway=motorway"/>
   <tag k="description:de" v="German">
    <tag k="implies:fr" v="highway=trunk"/>
   <tag k="photo" v="http://..."/>
</relation>

So we reuse OSM's data as well to define the area where the property 
applies. A simple class to map from country code to admin area ID is 
setup, so that we can demonstrate that we have got the best data - we 
can exactly show what a country code means geometrically.

Let's think about setting up MongoDB to handle nested objects and schema 
changes more easily. In MongoDB, collections are the equivalent of 
tables, so we would have several collections or classes, examples in JSON:

1) AreaLabel, example:
{
  de: {class: 'Relation', id: 12345},
  ...
}

2) KeyDef

3) ValueDef, example:
{
  keyDef: {key:'highway'},
  value: 'motorway',
  description: {
   de: '...',
   fr: '...'
  },
  impliesValueDefs: {
   fr: {
    keyDef: {key:'highway'},
    value: 'trunk'
   }
  },
  photo: {
   __: 'http://...' /* '__' means global */
  }
}

4) Preset

5) Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100506/b034d196/attachment.html>