Don't render tiny water areas

[matthijsmelissen]

Don't render tiny water areas (4px or less).

This should resolve #73.

[imagico]

That is a bad idea for reasons discussed in #703. You would introduce bias and outright rendering errors (in particular interrupted rivers) this way. I explained in my comment on #73 how the cyan color issue can be solved more elegantly.

[pnorman]

👎, this will cause parts of rivers to disappear.

I could see going for way_area/(!pixel_width!*!pixel_height!) => 0.1 or so as an area << 1 pixel is probably safe to not render, but I doubt that will have a huge impact on #73.

[vholten]

I loaded Oklahoma and tested which threshold value is required to hide the cyan color. I found that way_area/(!pixel_width!*!pixel_height!) > 0.001 is sufficient. This will probably not cause problems with rivers.
Example images:

way_area/(!pixel_width!*!pixel_height!) > 0.001

way_area/(!pixel_width!*!pixel_height!) > 0.0001 (just to show that this threshold is too small):

[matthijsmelissen]

@imagico, thanks, closing this one.

[matthijsmelissen]

Great test! Do you have a way to test which value causes river problems too?

[vholten]

I don't see any river problems in my Oklahoma test. With my suggested threshold, only river parts smaller than one thousandth of a pixel would be hidden, and these parts are probably not observable even if they are shown.

[daganzdaanda]

Wow, the possibilities of Carto-CSS are impressive!
This may be a stupid question, but could a calculation like this be useful for more things? Are calculations like these taking a lot of time / processing power?
If anything is so small that it would only be less than 1/1000 (or even 1/10) of a pixel at a certain zoom, why should it not be dropped from rendering at that zoom? If you zoom in, it will get bigger and then it makes sense to render it, but why waste ressources trying to display something that is invisible anyhow?

(Of course, the gamma issue that @imagico mentions should be looked into anyway.)

[matthijsmelissen]

I think this might potentially also be useful for landcover.

[matthijsmelissen]

Does anyone understand the rendering algorithm by the way? Why would an area of 0,001 with non-zero gamma lead to a cyan pixel?

[daganzdaanda]

Wild guess: anti-aliasing gone bad?

[imagico]

@math1985 - the exact mechanism how the cyan color is produced eludes me, this could be some kind of accumulated rounding error (i.e. a bug) or a perfectly normal side effect of the gamma manipulation. Generally this whole gamma thing is a really ugly way to work around a systemic limitation of the rendering framework. The gamma parameter is originally not intended to be used this way, it is meant for optimizing antialiasing for specific characteristics of the output device (see http://www.antigrain.com/research/gamma_correction/). The way it is usually used in mapnik actually reduces antialiasing quality so it is more or less used against its original intent.

And limiting the gamma manipulation to larger polygons works fine, here for example with a limit of 0.1 pixel polygon size: