SVG patterns in landcover-area-symbols render inconsistently in different metatiles

[imagico]

This is a followup on the after-merge discussion in #2727.

There we observed differences in SVG pattern rendering depending on unknown conditions leading to differences between metatiles.

The fact that so far the problem analyzed in https://github.com/gravitystorm/openstreetmap-carto/pull/2727#issuecomment-322042825 only seems to occur with kosmtik bothered me. Since in the released version only three landcover patterns use SVGs, quarry does not use polygon-gamma (so would fall under point 4 in the list) and forest uses opacity in addition which might cause additional problems i looked for cases with scrub.

The OSMF servers use much larger metatiles so this is more difficult and due to the not so dense pattern you cannot usually readily see it but here an example:

https://a.tile.openstreetmap.org/19/278627/184492.png https://a.tile.openstreetmap.org/19/278870/184612.png

As with beach there are more than two variants, the above is the most extreme case i could find. And no, this is not double mapping or so, it can be found in different places. A metatile edge can be seen here:

https://www.openstreetmap.org/#map=19/46.90235/11.48643

So yes, this appears to be a real problem and it already shows up in the map.

It affects patterns in landcover-area-symbols - if observations in kosmtik are representative patterns in the normal landcover layer will render incorrectly but consistently with polygon-gamma other than 1 and correctly otherwise (the latter being the current situation for the quarry pattern) polygon-pattern-gamma does not appear to have an effect on this.

[kocio-pl]

Do you think it should be reported as an issue in Mapnik?

[imagico]

In https://github.com/gravitystorm/openstreetmap-carto/pull/2727#issuecomment-320775890 @springmeyer did not consider this a bug. You can still report it but unless this assessment changes a fix from side of Mapnik is probably unlikely.