The way represents the highway AND the sidewalks. So we have to admit that the street borderline is in every cases incorrect. If you want to be accurate, you should draw polygons also for the streets. But since they are symbolized with a line, it is also valid to attach the landuse to the line. Both methods are correct. Otherwise I could also say that an offset suggests that there is “something” between the landuse and the street. A good example is a pedestrian square along a street. If you keep an offset between the street way and the pedestrian area, you don’t connect both objects and pedestrian routing will fail.
A way is only the middle line of a street and nothing more.
You can either use an area for a street (too complicated in my opinion) or add a width tag.
The rendering engine can draw an area if you have both values.
The alternative is a fixed width for different street types that is used today.
OSM isn’t very easy for new users who are not nerds, this complicated multipolygones are too much for them. You would end with a map that can be only edited from the few OSM experienced experts. That would be an epic fail if you think that this doesn’t matter.
I could point you to übercomplicated areas in the map with such multipolygons where even experienced users will have really huge issues to understand the areas but I converted them one by one to simple areas.
I think that you have to understand that OSM will never show the 100% reality that exists ion the ground. We are trying to get close to the reality but it’s always a compromise.
Our data model doesn’t allow more but that is enough for the sources of our data.
Aerial images are shifted and we have only 7m accuracy for GPS.
No. The way represents (symbolizes ?) the whole street on its whole width and its 1, 2, 3 or x lanes, including the possible sidewalks and optional cycle lanes, tag “width” present or not.
This is true until you draw polygons.
Yes, simple areas should not be modeled by using multipolygons.
But let’s take a simple lake with some islands. I think it is easier to use a multipolygon to model this structure than to use tricky ways through the lake back and forth to leave the islands out of the lake area. Using a multipolygon to model this structure by giving an “outer” border of the lake and some “inner” borders of the lake is just easier to understand. Now where should the tags go if you do that?
The outer area contains both the lake and the islands. So they should not have tags which are describing only the lake. It’s just the wrong place.
The inner areas contain the islands. They may and should have all the tags available describing the islands.
The multipolygon is the only one describing the area of the lake (without the islands). So this is the place, where the tags of the lake belong. (And so putting them there is not at all forced by the lack of ways describing areas.)
Weide
So, given this example with a lake and an island. Let say we can use single ways because we are under the 2000 nodes limit. Both, the lake and the island have names of course.
With the “new” multipolygon method, you need:
1 way for the lake, no tag
1 way for the island, no tag
1 relation multipolygon with lake way as outer role, island way as inner role and the tags natural=water + name=MyLake
1 relation multipolygon with island way as outer role and the tags natural=land + name=MyIsland
With the “old” multipolygon method:
1 way for the lake, tagged natural=water + name=MyLake
1 way for the island, tagged natural=land + name=MyIsland
1 relation multipolygon with lake way as outer role, island way as inner role
So, where is the “keep it simple” ?
Why that? The island is a simple area and should be tagged as such. There is no need for a second multipolygon.
Weide
It would be nice if people who make osm2pgsql utility and also folks generating shapefile excerpts in Geofabrik and Cloudmade could give some working examples about how to draw a lake with some islands. Islands should contain a few own tags, at least name and a knowlegde that it is land.
The desired output is one polygon with holes presenting a lake and one polygon for each island. The simple case to start with is a small lake with such a short outer ring that it can be drawn with one closing way, and all the islands without their own inner rings. For example http://www.openstreetmap.org/browse/relation/69021. A second, bit harder example could be a lake with so long outer ring that it must be devided into pieces, like http://www.openstreetmap.org/browse/relation/303406. And a third one could be something bigger, with lots of islands, some of them containing little lakes or ponds (which may also have names) like http://www.openstreetmap.org/browse/relation/402543.
Geofabrik and Cloudmade shapefiles do not include any of these examples correctly and also import with osm2pgsql leads to wrong result.
Good. You fall down in my trap 
Then to name the island, you suggest to add the tag “name” on the inner way. That’s exactly why I don’t like the “new polygon method” : it says that we should move the tags from the ways to the relations but finally you do it sometimes and sometimes not.
There are some interesting discussions at http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry about multi-way tagging where a number of “things” run in parallel. These “things” could be lanes on a dual-carriageway or a road, it’s sidewalk, the ditch and the hedge all tagged against against a single way.
If the hedge is cut down then the “hedge tag” can be removed with no other changes required.
I think that if one such way formed the edge of an area then the multipolygon approach would be my preferred method (or an equivalent)
:-))
Exactly for the same reason why I put the tags of the island into the data structure describing the island, I refuse to put the tags of the lake into the the outer way. The outer way does not describe the lake, but only a part of it’s boundary. Geographically the islands are not part of the lake. The area of the outer way is not the area of the lake, but the sum area of the lake and the islands. It’s the relation which describes the lake.
Let’s look at the practical results:
“My” solution:
If I find a closed way with natural=water in the database, then I can draw conclusions from that. I can compute the size of the area of the lake. Given coordinates, I can tell if it’s in the water or not. The meaning of the data structure “closed way with natural=water” has not changed. No one is forced to learn multipolygons to handle simple lakes.
“Your” solution:
If you find a closed way with natural=water in the database, then you know nothing. Only after searching the whole database for a multipolygon containing this entry as an outer, you can draw conclusions about the lake. Only if there is none, then it’s a classical lake, which can be handled as in the old times, when there was no multipolygon. If there is a multipolygon, then you do the above mentioned computations in a different way. Everyone has to learn multipolygons, because you cannot interpret even the most simple area entries without searching for multipolygons.
Weide
“Your” logic (Weide) makes it possible to draw a simple lake easily. However, nobody can still draw a simple island without learning multipolygons, because every island is inside a multipolygon lake. So if there is already a lake and somebody wants to add an island then the user must draw first an island, tag it, remove lake tag from the outer ring, build a multipolygon relation and tag that as a lake. Somehow I feel that OSM needs major improvements in polygon handling.
The multipolygon approach being discussed here is actually a third approach to your problem - you create a multipolygon and add the bounding ways to it to create an area
Are you sure ?
The relation describes a surface and in option holes, I agree. It doesn’t mean that we have to move automatically the tags from the way to the relation. When I stand in front of the lake Victoria, I say “here is the lake Victoria” whatever the lake has islands or not. It’s the same when I draw it. It should be the same tagging method, whatever there is an island or not. That’s the “keep it simple” approach.
First, it’s quite easy and fast to seach a way in a relation table if you know its way_id and have defined proper indexes. But anyway, we shouldn’t think too much about tools and software when we talk about tagging in general. We need to find methods that are easy to use and comprehensible for our contributors.
Yes, that’s a problem. I don’t see any simple solution. It would be possible to add some support in the editors (“convert area”).
No, not really – but I am sure, that points on an island should not be members of an area tagged with natural=water.
I do see your point.
I’m afraid we won’t reach the same same point of view here. I can’t call it simple, if a new data structure (multipolygon) changes the meaning of an old one (area described by closed way).
But is there consensus on where there isn’t a closed way? The original question was to to tag an area bounded by a number of different roads.
Glued or unglued to the way is not so important for a landuse=commercial. Glued is not wrong but unglued is better because it is more accurate. Just be aware that some areas are playing a role for routing. Thus if you create a square where you can freely circulate (for pedestirans or cars) with a closed way tagged with area=yes, and you don’t connect the area to the “network” (e.g. glue it to the adjacent roads), the routing softwares will not be able to use them.
Well, thanks for the discussion. I cannot tell that I reached any personal conclusion, but it has been very educational 
"He means the complicated way of creating Areas with multipolygons and several way members that together build an area. In that case you must put the Tags on the multipolygons because the ways itself are not a closed way.
The are more cons using this type of multipolygons:"
It seems this is used on the map, but these don’t sound like multipolygons to me - rather this sounds to me like a “multiway relation forming a polygon”, or “multiway” relation. According to http://wiki.openstreetmap.org/wiki/Relation:multipolygon “In short, a multipolygon relation can have any number of ways in the role “outer” (the outline) and any number of ways in the role “inner” (the holes), and these must somehow form valid rings to build a multipolygon from.”
However reading further on the multipolygon wiki page, I do find “Use case: Multiple ways forming a ring” - I think this is unwise, as it forces everyone and everything (every map rendering for example) to know about multipolygons. A practical example is lakes, originally closed areas bounded with natural=water. Now that people have started using these “new-style” multipolygons, that practice has changed what a normal polygon is and how it works.
Since API 0.6’s limit of 2000 points for a way, big likes (like Saimaa in Finland, just one part of which can be seen via http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=405925 or http://www.openstreetmap.org/browse/relation/405925 ) can’t be drawn with just one outer ring.
However, rather than trash the “closed rings” requirement which breaks lake rendering for every software which doesn’t learn multipolygons, I think a much better solution is to use several adjacent norman polygons to define the lake shorest, and then combine them to a multipolygon relation with touching outer rings, like the 506925 relation linked above has. This way of representing lakes works fine with for example GpsMid, which currently doesn’t grok multipolygon relations. Depending on rendering style there might be some trouble, like lines in the middle of the lake, for example, if the shoreline has a different color than the lake. But these can be eliminated by adding the support for multipolygons or adding support to recognize adjacent polygons.
However, on the wiki page there’s the following passage:
"Generally, the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard (http://www.opengeospatial.org/standards/sfs). Anything that is not a valid multipolygon according to this standard (e.g. polygons with intersecting rings) should also be considered an invalid multipolygon relation, with the notable exception of touching inner rings (see below). "
I first thought touching polygons are not intersecting, but the above wording seems to imply the OGC Simple Feature standard says otherwise, thus it would seem touching is intersecting. However, if there’s an exception for touching in inner polygons of a multipolygon, I propose an exception created also for outer polygons to make big lakes possible without forcing the world to parse all multipolygons.
There’s also wording on the wiki page which would work fine with touching outer rings:
"An implementation of advanced multipolygons should attempt to render these as if the touching rings were indeed one ring. This is the one case where OpenStreetMap use deviates from standard OGC Simple Features. In Simple Features, touching inner rings are not supported because they are unnecessary. In OpenStreetMap, they sometimes make sense if tagged individually, for example a forest with a clearing which is half occupied by a lake and half by farmland - you would have two “holes” in the forest, one being tagged as natural=water and the other as landuse=farmland. This is a convenience shortcut; requiring of mappers to create only one hole in the forest, and then create individual polygons for lake and farmland, would create too much work for them. "