I’m sure this has all been discussed many times, but there are conflicting instructions and it would be nice to summarize it all so the Wiki can be updated. The discussion a few days ago (http://forum.openstreetmap.org/viewtopic.php?id=6347) really helped, but not completely. Being a new user, I don’t really care what the “old way” was; I’m just interested in a “good way”. So here is what I’ve gleaned about how to draw lakes and islands in Potlatch, including a few questions.
Create a simple lake as a closed way:
Draw or choose a closed way for the shoreline.
Tag the closed way with natural=water, name=whatever.
Lake as a multipolygon:
Draw or choose a closed way for the shoreline.
Add the closed way a new relation (Potlatch: chain-like button right above the tag button).
Tag the relation with type=multipolygon, natural=water, name=whatever. If the lake is being converted from a simple closed way, copy these tags from the way.
Set the way’s role in the relation to outer. (Potlatch: go back to the way’s properties where the tags would be listed. Clicking on the left part of the relation accesses the relation’s tags, and the right part accesses the tag’s role in the relation.)
If the way had tags, remove them, as the tags are now on the multipolygon.
Simple island as a closed way:
Draw a closed way for the shoreline.
Tag the closed way with natural=land, name=whatever.
Make the island into a hole in the lake. How?
Add the closed way to the relation for the lake. (Potlatch: When you click relation, the dialog box should let you find the body of water.)
Set the way’s relation to the water to inner. This creates the hole in the lake, river, etc.
Question 1: Is it necessary to make an island part of a lake relation as an inner ring? Think about from a logical standpoint and from a rendering standpoint. Logically, both cases may exist. The island of Great Britain is not part of the Atlantic Ocean. But a small island in a lake may be thought of as part of the lake. OTOH, calculating the water surface area means not including the island. Renderers may be confused, as drawing the lake after the island may overwrite the island completely.
Question 2: What if a lake is part of a landuse= area, should the landuse area be made into a multipolygon with the lake as a hole? Will it be rendered properly if it isn’t? (Way 50859440 works on Mapnik and Osmarender, but not on NoName.) This is almost the same as Question 1, except that the lake would almost certainly be part of the landuse area. So would any islands in the lake.
Question 3: Is there any reason to worry about clockwise vs. counterclockwise? Some parts of the Wiki (and Google searches of the mailing list and forum) say it’s important, but the Wiki page for multipolygon says it does not matter. Does it matter for the simple closed way case?
Question 4: The openstreetmap.org slippymap doesn’t give access to relations, even with the Data overlay on. This makes it hard to inspect any body of water that uses a relation. Can this be fixed? Maybe list any relations that a way is part of, including the relations’ tags.
Question 5: The Wiki page for Elements says it’s necessary to create “C shapes” for areas with holes. Should this page list multipolygons as a better alternative to C shapes?
Your description of creating multipolygons looks correct to me apart from a little typo where “to” is missing from “Add the closed way a new relation”. I don’t think you have to use a closed way though, I think you can build the boundary by including existing ways in the relation
Questions 1 and 2 relate to my concerns about ways v areas in OSM as mentioned in the post you quoted. Yes, a lake within a landuse should be a hole, but in practice they normally render correctly so does it matter? Probably not but it should.
Q3. Whenever I’ve used multipolygons I’ve not even thought about direction, so I don’t think it matters!
Q5. There’s that word “better” again! IMHO the wiki should state the C-shape approach as one option for holes, but that multipolygons have superseded it. Perhaps even move it to the historical section.
On this point, I’m not sure. From a rendering standpoint, you may want the land of a National Park to render in green, with the lake in blue. In that sense, the blue lake is a hole in the green area. But from a logical standpoint, the lake may be part of the National Park. You wouldn’t want people to think the lake is a separate region with different laws. My gut feeling is that the lake shouldn’t have to be a hole in the national park.
Or take another example. Let’s say somebody wanted to use OSM to create a political map of the US, with state being a different color. Lakes, etc. aren’t carved out of the state relations. (Look at New York, where half of Lake Ontario is within the relation for New York.) The rendering rules they use should take into account lakes and seas to color them blue, even when they count as being part of a state’s territory.
So I guess I’m advocating for natural=water areas within landuse=* areas, without having to use make a hole in the outer area (via the C shape or the multipolygon). I’m not saying holes shouldn’t be used when they makes sense. Just that renderers should be able to deal with it when they’re not there.
On the other hand, if there area outside the lake is designated natural=* (e.g. scrub, forest, or wetlands), then the lake should be carved out of those. Overlapping areas tagged with natural= wouldn’t make sense.
I take your point, but National Parks and State lines are boundaries, not landuse. The renderers make sensible decisions about the order of rendering in some instances (probably just as well!) and put the lakes on top of the land regardless of its use so why not extend the argument and make the renderers put islands on top the lake? Or use layer tags so that the ground is layer 0, the lake layer 1 and the islands layer 2?
The answer is that it’s not how OSM is meant to work - using layer tags to force the order of rendering is precisely what you’re not meant to do! It’s all layer 0 apart from tunnels and bridges, so you have to have holes so that the order of rendering is not important. Or at least do the ground first and the ways on top of it.
OK, so what I’m gathering is this: landuse= and natural= are separate if not completely orthogonal things. They can overlap if it makes sense. So a single National Park can include areas of natural=wood, natural=scrub, natural=water, etc. It seems like the Mapnik and Osmarender versions of the openstreetmap.org slippymap can both handle this (i.e. natural= takes precedence so we can see lakes within a landuse=natural_reserve).
On the other hand, areas that have different natural= tags shouldn’t overlap. So a lake within a natural=wood should be carved out of the woods by converting the natural=wood area into a relation of type=multipolygon and adding the lake to it with an inner role. If there’s an island in the lake, then the lake in turn has to be converted into a multipolygon so the island can be carved out.