[OSM-dev] Using relations to save data

Scott Crosby scrosby06 at gmail.com
Wed May 5 00:39:36 BST 2010


On Tue, May 4, 2010 at 3:12 PM, Andreas Kalsch <andreaskalsch at gmx.de> wrote:

>  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?
>
> 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 (
> http://wiki.openstreetmap.org/wiki/Machine-readable_Map_Feature_list )
> regularly in the database to be able to access the data with the API easily,
> which already provides versioning and changesets:
>

FYI: This sounds like a prototype-based object system.
http://en.wikipedia.org/wiki/Prototype-based_programming

An adaptatation for a prototype-based system for OSM might be something
like:

<prototype id="...">
   <inherits id="...">
   <inherits id="...">
   <tag ...>
   <tag ...>
</prototype>

<way id="...">
   <inherits id="...">
   <inherits id="...">
   <tag ...>
   <tag ...>
</way>

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.

"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] http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf
>
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100504/92864b8d/attachment.html>


More information about the dev mailing list