Cyan colour at z6

[pnorman]

6/14/25 on orm

See the cyan colour near Oklahoma City. I suspect it has something to do with small water areas based on where I'm seeing it.

This issue is not present on yevaud, there it is a gray colour. Neither strikes me as visually great, but the cyan is worse.
6/14/25 on yevaud

[gravitystorm]

That's a mapnik upgrade thing, I suspect - I saw a similar problem with a client of mine but we eventually moved on with a workaround. If someone could confirm it with the old stylesheets and new mapnik (2.1+) that would be great.

[matthijsmelissen]

This bug is still present: http://c.tile.openstreetmap.org/6/14/25.png

[matthijsmelissen]

It is now also present on yevaud.

[pnorman]

Maybe a way_area > some fraction of a pixel's area? I know that where clauses on way_area are a bad idea, but we kind of need something

[Rovastar]

Why do you need a "where" clause in the SQL?

Something like

   [natural = 'lake']::natural,
   [natural = 'water']::natural,
   [landuse = 'reservoir']::landuse,
   [waterway = 'riverbank']::waterway,
   [landuse = 'water']::water {
  [way_area >= 15000][zoom >= 6],{
       polygon-fill: @water-color;
       polygon-gamma: 0.75;
 }
 [[zoom >= 8],{
 polygon-fill: @water-color;
       polygon-gamma: 0.75;
     }

Or whatever size you see fit. And obviously you will need to fix the syntax but you get the idea.

edit: or that that what you mean shrug is it really a large overhead for that!?

[pnorman]

It doesn't matter if you do the way_area check in MSS or in SQL, you still shouldn't generally filter by area. I think it's okay in this specific case, but in general it can lead to stuff like stretches of rivers disappearing, because they can be split in arbitrary ways.

[Rovastar]

I did consider the riverbank issue and was going to leave it out,

Personally I think the way to go is to use way_area on a load of features. I would like to see on nearly everything. The larger the area of a hospitals, airports, schools, retail parks, etc, etc render the name/area dependant on the size. Small ones would not have a name rendered at x zoom level large ones would. It gives really meaningful rendering. As most of the time teh larger an area the more important it is.
As long as the rendering time is not additionally huge I would be a great fan of this.
Being the performance stats guru on this do you what the impact is if we did say 100 of these checks.
I don't see this is much different to adding another condition.

[imagico]

The cause of the cyan color is that the gamma setting is messing with the color mixing in the renderer (without actually knowing what mapnik does internally but this is a pretty safe guess) . So you would not need to leave out small water areas completely, just use standard gamma for all smaller ones and only manipulate the gamma for areas at least a few pixel in size. This would also be an improvement independent from the color issue since the manipulated gamma setting overemphasizes the water (i.e. there appears to be more water than there actually is).

[pnorman]

mapnik/mapnik#1639 is relevant too for size thresholds

[mrwojo]

I stepped through this yesterday to confirm specific issues (which I can expand upon if you want the gory details):

1. 99.9% of the natural=water polygons in the 6/14/25 tile have way_areas smaller than a pixel

2. subpixel geometry is not exactly modeled in AGG
3. the small polygons cluster at the minimum coverage value representable in AGG (8-bit)
4. pow(0.75) gamma has its most distorting positive effects on the low end -- min coverage polygons have 4x alpha
5. truncation from multiplying 24-bit color values by a tiny alpha value reduces hue precision -- reducing to options like cyan or gray
6. accumulating many subpixel polygons magnifies the precision issues

Tweaking the gamma by setting a cutoff size >1 pixel would effectively hide this by making subpixel polygons not noticeably affect the rendering. However, a large water body represented by many subpixel polygons would still render poorly due to points 2 and 5 above. For these reasons, I'd be more inclined to simply filter out very small polygons in SQL (significantly smaller than one pixel). The net effect is almost identical and it results in a significant performance improvement for this tile locally.

"Outside the osm-carto box", AGG (or at least Mapnik's use of it) would need a few updates to support higher precision rendering. Personally, I think that'd be a little overkill if we're willing to just make this problem go away by filtering.

[pnorman]

@springmeyer, @artemp, any thoughts on this? Ultimately we'll need to do something in osm-carto, but is there an upstream issue in mapnik/mapnik?

[springmeyer]

simply filter out very small polygons in SQL (significantly smaller than one pixel). The net effect is almost identical and it results in a significant performance improvement for this tile locally.

👍

@springmeyer, @artemp, any thoughts on this? Ultimately we'll need to do something in osm-carto, but is there an upstream issue in mapnik/mapnik?

Upstream issue for what exactly? It is not clear to me there is a bug. If this is important I would recommend experimenting with the other gamma-methods AGG has which Mapnik exposes: https://www.mapbox.com/carto/api/2.3.0/#polygon-gamma-method and after the creating a standalone testcase.

[pnorman]

Upstream issue for what exactly?

Drawing cyan as a result of the truncation scenario outlined by @mrwojo

[matthijsmelissen]

Can confirm this is solved.