[OSM-dev] Using relations to save data

Andreas Kalsch andreaskalsch at gmx.de
Wed May 5 15:36:23 BST 2010


This is what I didn't propose - introducing a new data type to make 
things more complicated.
Semantically, a prototype-based object system - know from ECMA - is 
related to my concept, but my idea is just about data and using OSM's 
existing structures and functionality to save data which should be 
machine readable.

Using prototypes for common features would complicate things a lot, 
because mappers would need to use an additional definition next to the 
feature list in the wiki.

Am 05.05.10 01:39, schrieb Scott Crosby:
> On Tue, May 4, 2010 at 3:12 PM, Andreas Kalsch <andreaskalsch at gmx.de 
> <mailto: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 <mailto: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/20100505/c85ec6f4/attachment.html>


More information about the dev mailing list