Rendering artifacts between small forest parcels at z10

[jeisenbe]

Expected behavior

An area of forest, which is broken up into landuse parcels, all of which are tagged landuse=forest or natural=wood, should render the same as a single large polygon of landuse=forest

Actual behavior

In some areas where the polygons that make up a forest are small rectangles, there are visible faint white (or lighter green) lines between the parcels. This is most visible on z10 in areas such as southern Poland, where many forested areas are composed of 400x400m parcels. It is not very noticeable on the current rendering, with fading at this zoom level, but is quite clearly seen if the darker color is used.

Links and screenshots illustrating the problem

Near Opole, Poland: https://www.openstreetmap.org/#map=10/50.8554/17.9970

Current rendering (Exported from Kosmtik) z10

Master branch, with fading removed z10

Screenshot from openstreetmap.org, zoomed in:

Inspector view of forests near this area in Kosmtik:

[imagico]

This is not a new problem at all - it just went mostly out of sight with the land cover fading.

Background info can be found in #672, #1043, #1117, #1566.

and for explanation of the fundamental reasons for this http://imagico.de/map/polygon_rendering.php

[jeisenbe]

It sounds like the solutions are (see http://imagico.de/map/polygon_rendering.php):

0) Keep reducing the polygon-gamma

• Causes other problems
• Papers over the underlying issues
• Continues very slow rendering of areas with well-mapped landcover at z5 to z9

1) Significantly improve polygon rendering in Mapnik upstream

• eg a) Calculate the total pixel coverage of each type of landcover from different polygons prior to rendering, or b) use a supersampling grid to render pixels
• a) would result in slower rendering, perhaps significantly slower? b) might not be slower?
• Unlikely to happen based on current level of Mapnik development?

2) Use as a raster mask for landcover at z10 and lower. This could be created with: a) the supersampling technique described at http://imagico.de/map/polygon_rendering.php or b) Render the landcover alone based on full planet data at z12 or z13, which would then be adjusted for use at z10 and lower.

• I believe the French style uses b) for landcover rendering?
• This would have the disadvantage that different types of landcover could not be easily rendered in different layers at lower zoom levels.
• Would require downloading another large data file prior to rendering small areas
• Looks very nice on the French fork.
• Renders faster than current method
• Might need to be rendered at 1 zoom level higher than the highest target zoom level, so that exporting or rendering at 2x the target resolution or at 200ppi for printing would still work reasonably well. This makes the file about 3x larger than otherwise necessary

3) Use reduced-size polygon file(s) for landcover at low zooms as described inhttp://imagico.de/map/polygon_rendering.php

• Ideally this would require a different file for each zoom level, but even one file designed for z10 could be used for lower zoom levels with results not worse than current, if the way_pixel filtering is removed. - Should render much faster, especially if files are used at target zoom levels
• The files may need to be designed for 1 zoom level higher than the usual rendering, to support retina tiles / printing at 2x resolution

4) Use simplified landcover polygons

• Perhaps a similar technique could be used for creating the simplified water and land polygons that are currently used for rendering the coastline at z9 and below?
• Would be a fairly large file
• Rendering would be somewhat faster than at present
• Would show some jagged edges at z10 (as with the simplified coastlines at z9), which would become less obvious at lower zoom levels
• Might cause issues like

5) Use generalized landcover polygons

• This could use a similar technique to that used for the built-up area outlines in the low-zoom demo shown by @imagico
• Rendering is very fast
• File size could be relatively small, depending on the level of generalization chosen. But this might need to be adjusted to allow rendering of retina tiles / printing.
• Would match well with generalized coastlines and potentially with generalized rivers and lake outlines at low zoom
• Appearance would be a change from usual vector or raster maps on the Web, but would look much more similar to a high-quality print atlas or human-drawn map.

Option 1 requires someone with the necessary ability and time to work on Mapnik. I've no idea if this is possible.

Option 2a could be done by anyone with the rendering setup, but still requires a full-planet database to create the files monthly, and a server to host them.

Options 2b, 3, 4 would require adjusting the techniques used to create the coastline/water files to make new data files, and they'll need to be hosted at openstreetmapdata or another frequently-updated source (hopefully once per month).

Option 5 probably requires coding new tools, so that the different types of landcover match up when generalized, and hopefully are similar to the generalized water polygons as well?

Any other ideas?

[Adamant36]

Faster rendering would be great. It seems like all the options have their own obstacles to implementation though. If it were me, I'd try the Mapnik route first. Since its still kind of being developed and other people using it would benefit. Then if that doesn't work try another option. Although, I have no clue which one.

What option are you leaning toward?

[jeisenbe]

What option are you leaning toward?

I am not capable of creating or hosting any of these raster or shapefiles, nor am I qualified to help develop Mapnik.

But I would be very happy if anyone wants to work one 1, 2, 3, 4, or 5 ("0", changing polygon-gamma, has already gone about as far as it can)