[OSM-dev] A new "object" element?

[Frederik Ramm]

Hi,

On 04/14/2011 08:31 AM, the.promenader at gmail.com wrote:
> I've been learning/experimenting with OSM since more than two months
> now, and I've a few suggestions I'd like you to pick apart. Since I'm
> new here, I'm not quite sure where to post them (where we could have
> a localised discussion), so for now I'm just making diary entries. I
> think I have an idea that would simplify both search efficiency and
> comprehensive data creation - you can find it here:
> http://www.openstreetmap.org/user/ThePromenader/diary/13572 .

You are proposing a general "object" data type, representing a 
real-world object, which can have any number of properties, one of which 
may be a "geometry" property that describes where the object is located 
on the planet and what shape it has.

This is indeed a very common way of modeling data in the classic GIS 
industry (think for example PostGIS tables where a table row describes 
an object, the row having lots of attribute columns and - usually - one 
geometry column).

If one wanted to do it, our current data model would be perfectly usable 
for that; take a "relation" as your "object", assign all the tags you 
like to it, and then take one or more nodes, ways, or relations 
describing the geometry and make them a member of your relation.

Of course, current renderers and geocoders might be a little confused by 
that, but a change in the data model is not necessary if one wanted to 
do what you suggest.

I do not, however, think that there's any efficiency to be gained from 
that. Au contraire, you will add extra indirections where there are none 
today. For example if you wanted to solve the question "how many traffic 
lights are there in this area", then you would have to join your 
"object" information with the node locations - in database speak, first 
find all nodes in that area, then find all objects using these nodes, 
then check if any of them has a pharmacy tag, or the other way round, 
first find all objects world-wide that have a pharmacy tag, then find 
all the nodes for them, then check if any are in the area requested. 
This makes things more complicated than they are now. We have this 
situation already of course for other relations (and, in a limited 
fashion, for ways also), but your idea would suddenly make *everything* 
that complicated.

Bye
Frederik