Render lakes according to size

[daganzdaanda]

I believe it would be an improvement if lakes were rendered according to their size.
(See also #700 and #703.)

Right now, all these appear at zoom >= 6:
natural=lake
natural=water
landuse=reservoir
landuse=water

Big lakes should appear earlier, and small lakes could come later.

Looking at Wikipedia,
http://de.wikipedia.org/wiki/Liste_der_größten_Seen
my idea would be to have 4 groups:

• Huge lakes that start at zoom=0.
  Possible cut-off >=15,000 km². This would make sure the Great Lakes are still rendered (they need to be re-tagged as lakes, not as coastline) The smallest lakes to have more than 15,000 km² are Lake Vostok (under ice) and Lake Ladoga. According to WP, there are 16 lakes worldwide in that group.
• Large lakes that start at zoom=4. A possible cut-off is >=3000 km². There would be 27 lakes in that group, from Lake Onega (which is currently tagged as coastline) at 9900 km² to Amadjuak Lake on Baffin Island. About 15 big reservoirs would also fall into this group.
• Everything from 3000 km² to >= 400 km² could start at zoom=6, as it is now.
• The rest, everything <400km², could start at zoom=7
• If it's really no performance problem, one could try even more tiers.

MapQuest Open has large lakes starting at 0.
Rendering small lakes later might help #73.

"waterway=riverbank" is also rendered from z=6. I would not change this, since rivers are often divided in smaller areas. Only the largest and widest rivers and deltas are really visible at that zoom, but I don't think there is a practical way to find out which river is too small to be visible.

[pnorman]

they need to be re-tagged as lakes, not as coastline

This has been discussed a few times on talk-ca@ and talk-us@ - they're staying as natural=coastline, and not for rendering reasons.

[daganzdaanda]

they're staying as natural=coastline , and not for rendering reasons.

Ah, OK then, if it's a consensus.
I looked at the list archives -- the main reason seems that coastlines are easier to work with than huge MPs. That is true. Great Slave Lake is a MP, and I can't get it to load anywhere... Warning: This link may freeze your computer: http://www.openstreetmap.org/relation/1834172

[matkoniecz]

"small lakes could come later" how, where and why it would improve anything?

[Rovastar]

I read that as later zoom levels, which makes perfect sense.

[matthijsmelissen]

This does not work, as rivers and other waterareas can consist of multiple polygons. That means that rivers will be rendered with gaps, as some sections are large enough and others aren't. The off-line version of OsmAnd uses this approach, and it gives really counterintuitive results.

I will therefore close this issue.

[Rovastar]

Rivers use riverbank and that is not for consideration here.
if it was you only apply it higher zooms.

[matthijsmelissen]

Reopeed.

[imagico]

The current tagging practice does not ensure natural=water is used only for standing water and all flowing waterbodies use waterway=riverbank. And also natural=water representing lakes is frequently split at more or less arbitrary positions - separate naming of bays and parts of lakes for example:

http://www.openstreetmap.org/relation/1421131
http://www.openstreetmap.org/way/72668216
http://www.openstreetmap.org/way/23557078

truly arbitrary splits like

http://www.openstreetmap.org/relation/930549

not to mention the really sad cases like

http://www.openstreetmap.org/relation/3410698

And if you allow the side blow ;-) - the many years of practice in rendering all water in uniform color in the standard style have no small part in leading to the OSM water data very much lacking in geometric definition and clarity. From my experience (see for example here) today this data cannot be used for much except for uniform style rendering and any processing making assumptions about the data beyond that is likely to fail badly.

Independent of the splitting problem also note my comment on #703

[Rovastar]

well in general large bodies of water would render at lower zooms. We are talking zoom =5 and below here. I know there are a few other things in this issue but the general it is about very large bodies of water e.g.
http://en.wikipedia.org/wiki/List_of_lakes_by_area
being displayed to some degree. Accuracy at this level does not really apply as in your link we definitely have it good enough.
(To be honest we could skip the ranking stuff in the issue for z=6 or 7 as that seems to work fine at the moment - just zoom 3-6, etc or most noticeable)

For your examples they are in the scheme of things not that large. They will still be displayed at zoom =6. Which are all but a pinprick on the map even at that zoom.

Some of the very biggest bodies of water are already in the coastline, e.g. Caspain Sea. Lake Superior, etc. Others seem to be tagged as coastline but not rendered
http://www.openstreetmap.org/relation/555716#map=6/53.891/104.590 zoom to 5 and all the water disappears,
But maybe there is a tagging issue or natural earth thing has something to do with it.....

Now a simple pixel_size way_area equation could work here. If we could see it if it is a reasonable value it will be displayed but there could be a lot of CPU time, but if we do it all in the SQL maybe not as much. But I suppose it is only re-render once in a blue moon at zoom 3 or 4 or 5.
Maybe it is just best to render all at say zoom 3. That will cover nearly all cases.

More interesting is labels for these.

We need some/more labelling. You would never know that Lake Superior, etc is that body of water as it never displays (well none that I can see and none sensible).

But I am going a little offtopic now. (the whole low zooms (I suppose below 10) is neglected and needs looking at really, I cannot see countries, etc, etc. but there is another issue tracker for that)

All these are mapnik way_area issues problems not withstanding and presuming it will not be an issue.

[imagico]

natural=coastline is a way tag only - applying it to a relation like Lake Baikal has no effect.

I suppose it is difficult to make a convincing case for not using a polygon area threshold in rendering features like lakes based on arguments alone - it is simply too tempting from the implementation side. I am all for a better map at the lower zoom levels but this requires a bit more effort than this to lead to good results.

For your examples they are in the scheme of things not that large.

http://www.openstreetmap.org/relation/3367363
http://www.openstreetmap.org/relation/35904

http://www.openstreetmap.org/relation/1268072

(the latter not included in your wikipedia list since it is an artificial reservoir)

Sometimes it is best to think of waterbodies in OSM as a practical case of the infinite monkey theorem - whatever strange data construct you could envision, it probably already exists in the database somewhere.

[matthijsmelissen]

I still don't like this. It would mean that on z5, for example the Victoria lake shows up but the slightly smaller lakes don't. I don't think using an arbitrary cut-off gives good results (unless that cut-off is 1px or so). Shall we close this?

[Rovastar]

I am confused with closing this are you saying that the current rendering is ok?