Another thing that slowed me down was OSM's use of 'relations' for... most everything. Relations are used for drawing shapes (mainly multipolygons) and sharing ways between two polygons, but are also used for describing one object's dependancy on another (like metro station nodes dependant on (or attached to) a metro line way). Shouldn't "relation" and "dependancy" be two distinct things?

What if "relation" was strictly reserved for shape rendering, and "dependancy" be used instead for describing one object's "belonging" to another? I think this could make data parsing and rendering - I'll get to this later - much more efficient and comprehensible.

Take my present obsession, buildings, for an example: The building itself would be a shape (relation, ways, nodes), but its address would be a node of its own (as is the case in most all of OSM). An address is rarely attached (at least, as far as I can see) to the building it 'belongs' to (it would be silly just to add extra specifically-key'd nodes to a building path just for that) - but what if the address nodes became a 'dependancy' of the building? A search for that address and its dependancies would turn up not only the address itself, but the building it belongs to.

I'd like to take that thought one step further: Imagine a house on a gardened property. The property is a key'd polygon, and so is the building upon it. If both the house and the property are dependant on the address, a search for the address (and its dependancies) would turn up both. To take this yet one step further, imagine that if everything on the property (grass, garden, trees, gates) were declared dependant on the property (automatically, because they overly the property polygon, upon submission?), a search for the address (and its dependancies) would return not only the parcel of land and the building, but everything on it. Hell, if a property were in an administrative region and we followed this logic, we could return entire, quite precise, swaths of land. But I'm not so sure if that sort of data usage is in OSM's perspective or interest.

As for the rendering side of things: I mentioned 'rendering order' in an earlier entry, and OSM most certainly has a schema of that sort (buildings drawn on top of grass drawn on top of city blocks, etc - although I don't understand it yet), but through 'dependancies' we could take this one step further: Imagine that I wanted to place a fountain (or a pool) on top of the building (terrace) in the property example I used earlier on. How would OSM place that? For the time being, I would have to use the "level=" key. Imagine instead that, because that fountain/pool polygon would be over the building polygon underlying it, it would be declared dependant upon it upon submission - if an object is dependant upon another, it could be rendered ~after~ the object it is directly above (dependant upon). And, to ensure that an object is indeed 'on top' of the object it is supposedly resting upon, we need only add a 'bring to front' button/menu to do just that to the object selected.

Let's not forget that OSM renders 'from the bottom up' (land, then covering, then buildings, etc): if there were a 'chain of dependancies' (eg: city block, garden, paths (benches dependant on paths because 'over' paths) and grass (lake dependant on grass because 'over' grass), buildings, things on buildings...) and OSM followed it all the way to the top, things could be rendered in a constant and comprehensive order - with much less design constraint for the end user.