One of the biggest challenges to the 'Area' concept is OSM's method of treating nodes and ways - polygons simply do not enter into the equation in the present state of things. It took me a while to understand that OSM defines a polygon only by adding an "is it filled?" tag, and even longer to grasp the fact that OSM data is how it is, and it is up to the end user on how to deal with it. This, if anything, calls of consistency in contributor methods of treating areas - or polygons - and that is certainly not the case today. In my work on data concerning the City of Paris, I see that every multipolygon building was 'joined' using the 'relation' - with all the object's tags added to the "outer" way, and I have learned since that this is totally the wrong way of going about it.

Enter the "multipolygon" key/attribute, and add another level of (possible) confusion: In my work mentioned above, some buildings are simple polygons (aka simple ways with the 'building' "is it filled?" tag) and others multipolygons - the method for creating each (drawing a simple square with a "building" key, vs. creating a relation, adding a "multipolygon" key, then all member polygons) is twice as complex as it needs to be, leaves room for inconsistencies (key placement), and overall is difficult for a new contributor to grasp.

I don't think the 'relation' key should be used at all in polygon creation (and reserved for data relations, but more on that in another post) - instead it should be replaced (along with its 'multipolygon' key) with a single attribute - 'Area' seems the best solution - to which all the object's data would be attached. This would make shape creation much more coherent, 'key-consistant', and user-friendly.

There is a discussion (actually, not much) about this here: osm.wiki/The_Future_of_Areas . I'll be adding a proposition of my own later today.

… See full entry

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.

… See full entry

OSM's learning curve is long indeed - its documentation is too disperse and hard to find (you have to know what you are looking for (wiki) before you can find it), but once you've grasped the basic understanding of how OSM works (mapping and tagging methods), things become pretty straightforward. I'm almost there now.

What most confused me in my reading/experimentation was the "relation" - it is used to describe both shape and association. Perhaps it is my using JOSM that helped in my confusion, but seeing a list of 'relations' consisting of unnamed multipolygons and all metro stations 'related' to the path of the metro line crossing the wee patch of land I was working on was indeed confusing - what is the use of a list if we don't know what those objects ~are~ ? Furthermore, keys (describing the point/way(/polygon)) seem to take secondary priority over the shape itself - In all logic, shouldn't it be the other way around? I think this is the hurdle that takes new users the longest to get over, and is the main cause of the disparity in placement methods of 'key' data. If I can cite a recent example, from my work on the city of Paris (France), contributors there added the "building" key to the "outer" polygon in a sometimes multipolygon, but not to the other multipolygon members, or the multipolygon itself: this means that someone rendering OSM data through his own methods would have to search the OSM data for a) a 'master' multipolygon, and if there is one, b) all polygon members of that multipolygon.

Even that didn't work out for me in some cases: contributors would sometimes make a building an "inner" polygon in a, for example, garden multipolygon: when I used the above method to try to make a comprehensive 'building' polygon, the result was the building being but a hole in the garden multipolygon.

… See full entry

Hello,

I've been using OSM since around a month now, and would like to make a few suggestions, and please feel free to make any clarifications if I have missed anything.

First off, from a data point of view, I find it a bit confusing that there can be no overlapping polygons: If I was to place, for example, the middle of a city block, I would either a) have to make the building an 'inner' member of a multipolygon (the city block), or b) cut a building-shaped hole in the city block polygon (making it a multipolygon) and place the building exactly upon it. a) is more data-friendly but not at all logical (from an architecture point of view), and can create confusion in certain rendering circumstances (whereas building data would become inseparable from the land around it, according to the OSM 'member id' system in place, and b) would require much more work, plus placing the same polygon (building + its corresponding hole) into the database twice.

The simplest solution I can think of is: allow overlapping polygons. This would be best from both a data and land-logic point of view. This would be possible if there existed a default 'layer' logic to how the land is used, and key attributions could stem from there. It would be even better to think in three dimensions - this would both serve the logic of our mapping and future developments (3d!) of OSM.

Let's take the basic 'human logic' of land use; the lowest on the list below would be drawn first below all other elements higher above:

7) any labels, tags or indicators pertaining to any of the below.
6) buildings
5) man-made structures (fences, roads, barriers, stairs, etc - rooted to elevation data)
4) ground covering (grass, sidewalk, crops, concrete - rooted to elevation data)
3) land use (property, bridge, city block, administrative region -rooted to elevation data)
2) water ('poured' into land data, with or without elevation information)
1) the land itself (with or without elevation information)

… See full entry