way_area filtering

[pnorman]

Currently we filter by way_area to require some areas to be at least 1% of a pixel with way_area > 0.01*!pixel_width!::real*!pixel_height!::real

0.01 was chosen as a very conservative value for water rendering problems, and may not be the best value.

It turns out that dropping small areas significantly reduces the number of objects returned by the database at up to medium zooms.

Going from 0.01 to to 0.1 or 0.25 would cut the areas returned by a factor of 3-5 and make partial indexes on area useful two zoom levels sooner.

Data from Europe extract.

[imagico]

This is a tricky matter and will require some rendering samples.

Am i right to assume that your graph includes all areas including those not rendered at the zoom level in question and those rendered with an outline (most notably buildings at the higher zooms)?

Size filtering in combination with the AGG polygon rendering and the size dependent gamma manipulation introduces a bias into area rendering, i.e. the acutal fraction of surface areas covered by a certain area type differs significantly from what is shown. Parameters could be tuned to minimize this but unfortunately this also depends a lot on how small grained the mapping is. This is already a problem right now, notice the brighter color of forest areas around

http://www.openstreetmap.org/#map=8/52.655/15.614

resulting from the regular grid splitting of the forest mapping there. Such effects would be even stronger when you fully leave out polygons already when they still cover a significant fraction of a pixel.

[pnorman]

using tile 8/138/83, sampling with gimp at pixel 52,16, averaging with a radius of 3. Area highlighted below.

1
0.01 (master)
#a9d294

0.05
#a9d294

0.10
#a9d294

0.25
#a9d294

0.5
#a9d294

1.0
#aad294

I wouldn't advocate going all the way to 1.0, but did it to put something in place at the extreme end of the scale.

Up close, the area looks like

[pnorman]

based on the above, the fraction of a pixel in the SQL does not impact rendering of those forests at reasonable cutoffs.

Doing a difference shows the following

Or, after streching the difference out by 5x

Flipping back and forth between the 0.01 and 0.25 and looking at the bottom left, i can see the difference at a 400% zoom, but I have difficulty perceiving it at a 200% zoom.

Do you have a different area that might show more significant rendering differences? I must admit, I'm surprised at the lack of difference between 0.01 and 0.50.

[imagico]

That area obviously does not make any particular difficulties for raising the way_area limit since it contains mostly large forest areas and the tiling is larger than the pixel size at z=8.

Areas with many small lakes will usually offer a better test case since they have a more continuous size distribution. In Europe you could try southern Norway or this area in France: http://www.openstreetmap.org/#map=9/46.8423/1.1467 - in North America Newfoundland and Labrador offer a good size distribution of lakes.

I also have my doubts about how much performance gain this will actually bring. Water and wood/forest at z=6-8 is the obvious candidate but these zooms do not weigh much in terms of overall rendering ressources i think. Landcovers at z=10-12 might be more relevant but how many polygons of those types actually exist in the <0.1-0.25 pixel range at those zooms?

[pnorman]

Landcovers at z=10-12 might be more relevant but how many polygons of those types actually exist in the <0.1-0.25 pixel range at those zooms?

The advantage is that it enables use of partial indexes on way_area, which use the first graph.

For landcover, it can be approximated by building IS NULL, and of those, 10% exceed 0.01 pixels at z4.5, 0.10 pixels at z5, 0.25 pixels at z6.8, and 0.5 pixels at z7.4

[imagico]

That looks more like it - as already hinted the fraction of very small polygons probably varies a lot depending on types - some urban landcovers, in particular leisure/amenity things and water have a lot of very small features while others like wood/farmland do not. For urban stuff a change in threshold will probably have little practical effect since these areas are extremely crowded anyway at these zooms and it is just a subtle change in noise. But i am pretty sure the effect on water areas at z=6-8 will be noticeable even if it is not stronger that the general bias we already have.

[kocio-pl]

I think we have effectively closed this by #2874. If you think it would be useful to have it opened, feel free to do it.

[jeisenbe]

Currently low-zoom landcover and water are still filtered at < 0.01 pixel size to z9, while mid-zoom to high zoom landcover (z10 and greater) is filtered at 1 pixel, and inland water areas (natural=water and waterway=riverbank) are filtered at 1 pixel at all zoom levels.

Also, above @pnorman had said that "I wouldn't advocate going all the way to 1.0 ... at the extreme end of the scale", yet that's what was implemented.

I think this issue should be reopened to discussion.

[jeisenbe]

Low-zoom waterbodies should be filtered at 0.01 again, same as landcover at <z10.

To use indexes efficiently, we could set the filtering to 0.04 at z10 and 0.16 at z11. Thus the filter would be at the same way_area size from z9 to z11. Then z12 could be set to 0.25, or 1/4 of a pixel, if in fact this is a safe limit.
pnorman showed above that using a 1 pixel cut-off causes rendering problems, way back in 2015.

As more fine-grained areas of landcover and water are being mapped near the equator, it is likely that many areas will show problems at 0.5 pixels as well.

I'm not certain that 0.25 is safe; this requires testing. Hopefully we can find an area with very-well mapped small plots of farmland or forest near the equator?

[imagico]

Three remarks:

• low zoom landcover is currently the only case where a 0.01 pixel size threshold is used.
• database indices should be adjusted to rendering decisions, not the other way round.
• the effect of a way_area threshold is continuous, there is no such thing as a safe value. The effect also interacts with the gamma setting since both create different kinds of bias in rendering which manifest differently depending on the size distribution of polygons in an area. What you can ultimately determine is at what level the bias introduced by way_area filtering is significantly smaller than the bias due to other effects. This can only be evaluated through practical tests.