Switch sand and wetland patterns to SVG

[sommerluk]

Some more work to eliminate raster images. Should not make a visual difference when rendered at default resolution.

[kocio-pl]

Sand looks much different now, could you check beach.svg? Wetland looks the same and mud.png is really not used anywhere, thanks for spotting it.

Before

After

Before

After

[sommerluk]

Okay, I see. What I get here is (left before, right after):

That’s not good.

@imagico Do we have to apply some transparency to the pattern? Does Mapnik support transparency?

It seems still different from your rendering, but I do not know why.

[imagico]

I noticed two things when looking at this:

• i apparently forgot to add the beach patterns to generating_patterns - should supplement that which will allow you to better pinpoint where Mapnik's SVG rendering differs. There is no distinct transparency involved in generating the PNG though.
• i distinctly remember the generic wetland pattern being semi-transparent but apparently only the more sophisticated wetland patterns are (leading to the dashes differing slightly in color between those which should probably be changed).

[kocio-pl]

It seems still different from your rendering, but I do not know why.

How do you render it then? I use Kosmtik with export.

[imagico]

See #2729 for the source SVGs and the process to generate the PNGs.

[kocio-pl]

Now it's OK. You should probably join two commits into one and it's ready to be merged soon.

[imagico]

This is still very different from the PNG:

[kocio-pl]

For me it's close enough, so I would leave it as it is now. What would you propose?

[sommerluk]

Here two screenshots that I have made:

At the left a screenshot from openstreetmap.org.

At the right a screenshot from kosmtik running the code of this PR.

It’s indeed not identical, but almost identical.

On the other hand, it is quite different from the picture that you have posted. I wonder where these rendering differences come from.

[imagico]

@sommerluk - my sample is based on the screenshot by @kocio-pl. I have not yet tested this myself (will do when i find the time). Your comparison indeed looks fine (and probably within the bandwidth to be expected due to rounding errors etc. due to different processing).

Your SVG and mine differ in the individual symbols but not the pattern so some small difference will always be there but this is not a problem if the overall impression is the same.

[sommerluk]

It might be worth to mention that at a first try, I had used the same colour in jsdotpattern that you have mentioned in the ImageMagic command for coloring. But this did not work well, the overall impression was quite different. I suppose that this difference is because it’s not the same thing coloring _before_ or _after_ rastering. So I have fine-tuned the color in jsdotpattern until the final result looked as close as possible to the rendering with the PNG.

…

-- Lukas Sommer

[imagico]

Yes, for explanation: the SVG used for the raster process has gray symbols (#969696). This color is used for the alpha mask with ImageMagick (CopyOpacity). So your foreground color essentially has to be a mixture between my foreground color (#685d45) and the background color (#fff1ba). And there are also probably some color mixing differences between Mapnik and ImageMagick.

[kocio-pl]

Export test shows that there's really a difference:

[imagico]

I tested the change and can add to the confusion - screenshot directly from kosmtik (no composite):

The left version which is probably what @sommerluk saw is a bit more reddish in the pattern than the PNG version which is to be expected with the colors used:

http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker#685d45,fff1ba,dbb677

Looks quite clearly like a Mapnik bug to me - it generates different renderings based on the same data and the same code depending on some unknown condition.

[kocio-pl]

It would be good to create an issue ticket then, if you can explain them what's going on.

[sommerluk]

@springmeyer Do you have an idea what could be the reason for #2727 (comment) ?

[springmeyer]

@sommerluk I don't detect a Mapnik svg rendering bug here. The beach.svg renders in mapnik nearly identically to chrome.

[imagico]

I have analyzed this a bit further:

1. There are more than two variants produced when rendering from kosmtik:

I of course have no way to reliably reproduce this or to reliably determine conditions where this does not occur.

2. The differences look like different gamma settings or multiple renderings of the pattern.

3. If i don't render the pattern in a separate layer like it is done for beaches but together with the base color fill i seem to reliably get the darkest variant (see bottom left above) everywhere.

4. If i render the pattern together with the base color fill and set polygon-gamma: 1; (not polygon-pattern-gamma!) i seem to consistently get the correct (lightest) result.

5. The problem is not specific to grain patterns like for beaches but also shows up with normal patterns unless they are trivial b&w pixel painting geometries like the base wetland pattern. This is not always clearly visible of course given the typical low contrast between symbols and base colors.

I have not checked if observations 3. and 4. could be due to a Carto bug rather than a Mapnik bug or if any of the observations is specific to the kosmtik setup.

Wherever the problem lies exactly unless someone finds a workaround to reliably get the correct rendering that is not overly complicated my conclusion would be that SVG patterns are not ready for production use here.

[kocio-pl]

Thanks for looking deeper into this subject. Are these images screenshots or exports? Is there a difference in how Kosmtik shows them on screen and how it exports them?

[imagico]

Since the differences are at the metatile boundaries they obviously only show up with a tiled render. I don't know if this also happens with tiled rendering outside kosmtik. Update: it is confirmed that this also happens in production rendering - see #2750.