Inconsistent way_area filters for water and landcover

[jeisenbe]

Expected behavior

• At a certain zoom level, all landcover and water features (including natural=water and the ocean polygons represented by the coastine) should be rendered at the same minimum size
• This limit should be low enough that the rendering is not visibly affected by splitting or combining polygons, so that mappers are not given misleading incentives to create large multipolygons, or discouraged from finely mapping small areas of woodland, scrub, farmland, sand, etc.

Actual behavior

• The minimum way_pixels limit for inland water features is 32 way-pixels at z5, z6 and z7, and 1 pixel at z8 and z9, currently
• The way_pixels limit for low-zoom landcover is 0.01 pixel at z5 to z9, currently
• The way_pixels limit for water and landcover is 1 pixel at z10 and higher currently
• The ocean shapefiles show full detail at z10 and up, and z0 to z8 they have sub-pixel accurace. At z9 it's possible that the accuracy is closer to one pixel (since this is the lowest zoom level where the simplified shapefiles are used), but I think it is still better than this

Solutions

1. Switch to pre-processed data for low-zoom landcover and water:
   a) Raster image: for example, as done by the fr.openstreetmap.org style (using a large png raster file, which is generated with z10 data approximately)
   b) Simplified polygons, like in the de.openstreetmap.org style (which used pre-processed data for water areas at z0 to z6, so that full data of water areas can be shown without performance problems - though this wasn't done for landcover yet)

2. Change the water limit to 0.01 pixels at low zoom again. This may slow down performance, but since these tiles are only rendered once a month or so, it may not be an issue for openstreetmap.org at least. But this will not solve the problem with landcover areas that consist of very small, detailed pieces, which will end up as less than 0.01 pixel at low zoom (z5 to z7 especially)

3. Stop showing inland water areas at low zoom (z4 and below) again. This would at least be consistent with landcover stopping at z5, and would acknowledge that the low-zoom rendering in this style has multiple issues which we can't easily fix without preprocessing. Some of the low-zoom issues cannot be fixed in this style, since they are inate to the Mercator projection at continent and global scales.

Links and screenshots illustrating the problem

[jeisenbe]

See also the discussion in #1566

[jeisenbe]

Examples from Latvia:

z5 Latvia

Current (32 pixel area limit for water, 0.01 pixel are limit for landcover, e.g. woodland)

After 0.01 pixel limit for water

Current export at 3x (retina tiles)

After 3x export with 0.01 pixel limit for water

Comparison: zoomed in 3x export, master (left) vs 0.01 limit (right): 2 rather significant lakes are missing, leaving white gaps in the green forest.

z6 Latvia

Current (32 pixel limit for water, 0.01 for landcover)

After (0.01 for both)

Comparison (standard resolution, zoomed-in)

z7 Latvia

Current

After 0.01 pixel limit for both

Current - 3x export, SE Latvia

After 0.01 pixel limit - 3x export, SE Latvia

Filtering out small lakes, but not small woods, leads to the impression that certain areas are unmapped, when in fact they are covered by water.

[jeisenbe]

How about the opposite, changing the landcover limit to 32 pixels at low zoom?

Or compromising on 1 pixel for both low-zoom-landcover and water-areas?

The problem is that too many small features are dropped, especially with the limit at 32. This makes it look like well-mapped, finely-grained areas are blank, and would encourage mappers to create big multipolygons for forested areas, instead of mapping them in small, manageable pieces.

z5: 0.01 pixel for both (landcover and water)

z5: 1 pixel limit for both

z5: 32 pixel limit for both

z6: 0.01 pixel

z6: 1 pixel

z6: 32 pixel

z7: 0.01 pixel

z7: 1 pixel

z7: 32 pixel

[jeisenbe]

@imagico, what is your preferred method to address the lower zoom levels?

Previously you worked on the preprocessed shapefiles for water, which openstreetmap.de was using (but perhaps these are no longer available?)

You also showed a custom renderer which uses a sort of supersampling technique to create low zoom level landcover/water rendering, for the alt-color low zoom demo.

And openstreetmap.fr creates a large raster file at mid-zoom level, and then uses that for landcover/water areas at lower zoom levels.

[imagico]

Note your rendering samples are of limited use for illustrating the problem because they already feature an infinite way_area threshold so to speak for most landcover types (which are not rendered at all). In Latvia also most non-wood landcover mapping is very spotty so it is not the best area to check this.

@imagico, what is your preferred method to address the lower zoom levels?

I have no strong preference here except the usual do something right or don't do it at all.

Previously you worked on the preprocessed shapefiles for water, which openstreetmap.de was using (but perhaps these are no longer available?)

Yes, that was so far not ported to the new platform the fossgis data preprocessing runs on. And it has also essentially been superseded by the method that covers both water areas and landcover that i discussed in http://blog.imagico.de/on-basic-small-scale-landcover-rendering/. All of this requires more work to be turned into a practically well usable framework. But the overall interest in that is very small since most map producers either look for more sophisticated processing (which would be neither feasible nor desirable here due to mapper feedback function) or are firmly tied to the misguided wishful thinking for there to be a fee lunch (i.e. that you can solve the problem with trivial methods like way_area filtering).

[jeisenbe]

In Latvia also most non-wood landcover mapping is very spotty so it is not the best area to check this.

True, though at least it didn't matter that other landcover types were not shown, since Latvia didn't have much of them other than wood.

I was mainly trying to show woods vs water, and Latvia was what I had on hand. Though it's true that considering residential areas and farmland would show the problem even more.

Do you have a good example of a reasonable-sized extract (<100 mb .pbf) where landcover/landuse is nearly completely mapped?

... method that covers both water areas and landcover that i discussed in http://blog.imagico.de/on-basic-small-scale-landcover-rendering/ ... but the overall interest in that is very small

Perhaps "if you build it, they will come?" Or is the problem that this is too big of a project to work on without a buyer in advance?

As an alternative, the French style's solution seems to work fairly well right now, with the existing toolchain. We would just need osmdata to host a low-zoom landcover/water png or tiff which was updated based on a global water/landcover extract on at least a monthly basis, and add that to the list of data that needs to be downloaded, in addition to the water and ice shapefiles.

[jeisenbe]

Also see #4071 - right now we are showing the wetland pattern at z5 to z7 when the wetland area is only 1 pixel, so it's possible to have a tiny dark blue dot for a 1 or 2 pixel area wetland, while a nearby lake is not shown even though it would be 30 pixels in area.