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)

Arguably, 5 and 6 could be merged. Only water in the above is problematic, but any 'unnatural' water areas (say in fountains, building-tops, and reservoirs) could be a 'man-made' subclass - in fact, it would be nice that if a "building" had a man-made structure on it (say, a fountain) indicated by a later key, it would be drawn on top of (after) it. Anyhow, if each of the above were a key, it could 'default' to a certain colour, yet the key's value would determine rendering.

What led me most to think the above was OSM's (often mis-)use of the "highway" tag: the "highway=pedestrian" tag describes almost every city block within Paris, along with the (seemingly pointless?) "area=yes" tag. This use seems to have stemmed more from the 'development logic' of OSM itself, rather than any 'human logic' plan-related determination.

A road (highway) often describes the separation of properties and city blocks, but the road itself is rarely regular in breadth: in fact, with Paris in mind, it is the 'city block' form that determines the shape and path of a road, and this changes from block to block, so there the idea of a "highway" line (way) is almost moot in itself.

I like the French "Ilot" (road-divided 'block') concept - it is an entity in itself for French Civil Engineers (and available under an OmDB licence at http://opendata.paris.fr), and has been in use since forever for civil engineers the world over; why not here?

Let me give an example: say for example I want to draw a city block containing a park, I would draw:

7) building addresses and street names
6) buildings (and things upon them)
5) man-made structures (fences, stairs, fountains, etc)
4) land covering (the park would have grass polygons with perhaps 'tree' node info and perhaps 'lake')
3) the city block
1) on existing land data (elevation or no)

Forgive my digression, but it would be actually possible to have ~any~ key (road, land covering) be rendered 'on top' of another just by indicating its 'membership' (in relation, not in form) to another object, by id number: grass on a building could be rendered after the building, if the only link to the grass polygon was through the building itself.

So my basic idea is to provide first a) allow overlapping polygons and b) think of a new basic 'land use' logic to keys. And perhaps re-think the "relation" concept in a way that is more "object" than "shape".

I hope I was clear in my presentation - and if there is something I missed already in place, please forgive my oversight - and please let me know about it!

Best,

ThePromenader