How to correctly draw landuse areas

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.)


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.


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 A second, bit harder example could be a lake with so long outer ring that it must be devided into pieces, like 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

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 :wink: 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 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.


“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 :slight_smile:

"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 “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 or ) 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 ( 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. "