At the last OSM hack weekend i worked on something that has been a sore spot of many map styles for quite some time. The problem is pattern images. I have written on the subject of designing area patterns for use in maps frequently in the past but this always was from a design perspective. From the technical side the story is the following:

In the beginning area fill patterns meant raster images because renderers did not support anything else. At some point Mapnik started offering support for SVG pattern images. This was and still is severely limited in terms of support of the SVG feature set which requires sanitizing SVG files to only use supported features. But the real problem is that Mapnik SVG rendering still seems fundamentally broken under certain conditions (see here and here). So the only safe way to get correct and consistent rendering of patterns in maps for screen use is to use PNG pattern images.

At the same time when you want to render maps for printing Mapnik does not scale PNG based patterns when you change the rendering resolution leading to incorrect pattern scaling relative to other elements in the map. So for printing maps you want SVG pattern images.

To solve this dilemma i wrote a script that

• automatically generates both PNG and SVG pattern images from SVG source files while also for single color patterns allowing to change the pattern color without editing the SVG by hand.
• allows switching between using PNG pattern images and SVG pattern images without manually editing the MSS files.
• generates preview images for the patterns with the matching background color.

This script is for CartoCSS+Mapnik map styles but it can of course also be adapted for other frameworks.

By the way client side rendered maps with continuous zooming have their own specific troubles with using area patterns – which is one of the reasons why you rarely see patterns being used in those maps.

Most of the planning and script writing work i did at the hack weekend but preparing some of the patterns into a form suitable for automated processing took a bit more time. This was in particular a problem for the wetland patterns – which use multiple colors and are generated using raster processing as well as the rock pattern – which uses the jsdotpattern outline feature which uses white strokes for drawing a casing around geometries that needed a lot of processing to generate a visually identical plain color geometry. There are also a number of legacy patterns, in particular various hatchings, that i did not yet look at.

Here is the current set of patterns in the alternative-colors style in the form of the previews generated by the script each tiled and cropped to 128×128 pixel size.