On Tue, May 4, 2010 at 3:12 PM, Andreas Kalsch <span dir="ltr"><<a href="mailto:andreaskalsch@gmx.de" target="_blank">andreaskalsch@gmx.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">




  
  

<div bgcolor="#ffffff" text="#000000">
I am still reading some old mailing list posts ...<br>
<br>
What about a relation
with type="data", which is a relation that can include tags and other
relations recusively?<br>
<br>
This relation has no geometric reference but it
is just there to save data. So we could reuse relations for a purpose
which is not the main OSM one - instead of expensively defining a new
data type. This type could be used to save tag definitions (

<a href="http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list" target="_blank">http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list</a>
) regularly in the database to be able to access the data with
the API easily, which already provides versioning and changesets:<br></div></blockquote><div><br>FYI: This sounds like a prototype-based object system. <a href="http://en.wikipedia.org/wiki/Prototype-based_programming" target="_blank">http://en.wikipedia.org/wiki/Prototype-based_programming</a><br>

<br>An adaptatation for a prototype-based system for OSM might be something like:<br><br><prototype id="..."><br>   <inherits id="..."><br>   <inherits id="..."><br>   <tag ...><br>

   <tag ...><br></prototype><br><br><way id="..."><br>   <inherits id="..."><br>
   <inherits id="..."><br>
   <tag ...><br>
   <tag ...><br>
</way><br><br>I just read [1] below, and it may be productive to look at a prototype-based object model. At a fine-grained level, there might be one prototype for each road, which has the common tags used by that road (such as the name). Each way composing that road then inherits that prototype, possibly adding in additional tags ('bridge'), or inheriting a second prototype, eg, for a bicycle path, which could represent a shared bridge.  Or at a coarser level, there could also be a highway archeotype for all highways, which inherits a road archeotype for all roads, and a bikepath archeotype for all bike paths, etc. Migration could occur incrementally, make a prototype, move all ways/nodes/etc into inheriting from it. Repeat.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><blockquote type="cite"><pre>"Instead of having a geometric object with some properties, we instead 
think of objects with some properties (like “this is a museum” and “this 
has the name Natural History Museum”) and the added property of “this 
object is positioned at such and such a location”. ... So the geometry 
is not the object itself, as it is now, but it is just one property of 
some kind of abstract object."

I believe this is indeed the way many pros are doing it - there is an 
object and the geometry is one of many properties of the object. It is a 
concept to keep in mind for the more distant future; I don't think we 
should aim to do it with the current implementation of relations though.

Bye
Frederik

[1] <a href="http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf" target="_blank">http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf</a>

  </pre>
</blockquote>
<br>
</div>

<br>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org" target="_blank">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
<br></blockquote></div><br>