PolygonPatternSymbolizer metatile alignment

[pnorman]

To use polygon pattern, the pattern either needs to fit into fit into a metatile an integer number of times with polygon-pattern-alignment: global or have polygon-clip: false, or artifacts at meta-tile boundaries will occur.

Without a fixed metatile size, this implies both pattern dimensions should be a multiple of two, and at most 256.

Because the defaults used to be polygon-clip: false, many of the icons do not meet this criteria. We need to check if there is more performance from polygon-clip: false, and if so, set that, otherwise, change the PNGs.

Some shell scripting (./node_modules/.bin/carto -a 3.0.12 project.mml | grep PolygonPatternSymbolizer | sed 's| <PolygonPatternSymbolizer [^>]*file="\([^"]*\)".*/>|\1|' | sort -u | xargs pnginfo | grep -B1 'Image Width') lets us get the image sizes.

The following files are not powers of two

symbols/danger.png...
  Image Width: 30 Image Length: 30
symbols/grave_yard_jewish.png...
  Image Width: 18 Image Length: 18

[matthijsmelissen]

a multiple of two

A power of two, right?

[pnorman]

A power of two, right?

Ah, fixed.

[imagico]

Currently all patterns are very regular with small tile size, most with a square cartesian grid. The most randomized are probably scrub and wetland. The question is if this is a deliberate design decision intended to be kept or if a more randomized pattern would actually be preferred. It is quite easily possible to generate a randomized power-of-two-periodic pattern and with the current symbol sizes and distances and this would mostly work well with a tile size limit of 256 pixel. Here a quick demo for the forest symbol (just a rough imitation, not really an exact reproduction):

A randomized pattern of course requires a relatively large tile size to look good - 256 pixel is already quite the minimum in this case. This might have performance implications.

[pnorman]

I'd like to keep switching to a randomized pattern as a separate issue.

[pnorman]

Updated the list.

[pnorman]

Updated, including a minor shell script change.

[pnorman]

Updated

[pnorman]

Updated, we're close

[kocio-pl]

We have the last one which is still not power of two:

symbols/danger.png...
  Image Width: 30 Image Length: 30
--

but we have more above 256 px:

symbols/wetland_bog.png...
  Image Width: 512 Image Length: 512
--
symbols/wetland_mangrove.png...
  Image Width: 512 Image Length: 512
--
symbols/wetland_marsh.png...
  Image Width: 512 Image Length: 512
--
symbols/wetland_reed.png...
  Image Width: 512 Image Length: 512
--
symbols/wetland_swamp.png...
  Image Width: 512 Image Length: 512

Why would they be a problem?

[pnorman]

Why would they be a problem?

Because they won't align when rendering tile by tile

[kocio-pl]

Should we recreate them all in 256 px then?

[pnorman]

Because they won't align when rendering tile by tile

They also won't align with some metatiling systems when taking into account buffer.

Should we recreate them all in 256 px then?

Yes.

[sommerluk]

SVG polygon pattern files currently > 256 px:

quarry.svg
scrub.svg
forest.svg

All others are ≤ 256 px and a power of 2.

[imagico]

For all of these there were good reasons to make them 512 pixel in size (as well as for the wetland patterns which are also 512 pixel). In case of relaxed random patterns there are the following requirements for a good quality irregular pattern:

• The relaxation radius should be at least about 3 times the minimum symbol distance.
• The relaxation radius should be less than half the pattern size (otherwise jsdotpattern can produce weird results).
• The pattern size should be large compared to the correlation length of the pattern, otherwise you have trouble properly relaxing the positions without running into resonance effects due to the periodic boundary conditions.

This does not mean you cannot create a decent random pattern with 256 pixel size for scrub and forest but it is significantly more difficult.

[kocio-pl]

With #2739 being merged now, and all the others being deliberately 512 px, I guess we can close this issue.

[pnorman]

Are we sure we're not running into any issues in production or with Kosmtik with the 512px patterns?

[imagico]

I would assume that through

openstreetmap-carto/project.mml

Line 2 in 9cdab72

metatile: 2

we define a minimum metatile size of 512 pixel. But if there are reasons to allow 256 pixel metatiles this would of course be possible. There would be some constraints design wise - see above - but it would be manageable.

[pnorman]

we define a minimum metatile size of 512 pixel. But if there are reasons to allow 256 pixel metatiles this would of course be possible. There would be some constraints design wise - see above - but it would be manageable.

Is the origin of the pattern at the edge of the rendering, or the edge of the metatile? I don't know the answer to this, and I wouldn't assume everything is the same.

[imagico]

Is the origin of the pattern at the edge of the rendering, or the edge of the metatile?

In a tiled rendering the edge of the metatile is also the edge of the rendering (at least from the point of view of mapnik).

polygon-pattern-alignment: global is actually a misleading identifier. local means the pattern is aligned to the geometry it is applied to. global should better be renamed render_area and means the pattern is aligned to the top left corner of whatever area mapnik is instructed to render. Real global alignment would mean the pattern is aligned to the map coordinate system origin (i.e. null island) and periodically repeated globally no matter what bounding box you render. This is what you'd normally want, it would also allow using arbitrarily sized patterns. But you don't get this with mapnik.

[pnorman]

In a tiled rendering the edge of the metatile is also the edge of the rendering (at least from the point of view of mapnik).

No, things are buffered beyond the metatile.

[imagico]

Ok, but then the alignment appears to be independent of the buffer - both in kosmtik and on the OSMF servers.

[dieterdreist]

sent from a phone

On 12. Aug 2017, at 07:00, Paul Norman ***@***.***> wrote: They also won't align with some metatiling systems when taking into account buffer.

I'd consider it a bug if adding a buffer would change pattern alignment/start.

[kocio-pl]

Related to what @sommerluk told in #2748 (comment) - there's a need to decide how do we want to go on with patterns currently? We can leave the things as they are and suspend changes for some time, but even such solution needs a deadline and decision at the end - no matter if we know all the side effects of tiling, because patterns are important tool we use.

[kocio-pl]

Looks like the Mapnik solution is getting ready - mapnik/mapnik#3989 is merged now, next thing would be 3.0.x port and release.

[sommerluk]

The Mapnik solution will bring us true global alignment of pattern, so we could use even pattern with arbitrary size (113 × 113 or whatever), which is really great.

An open pull request for the backport is at mapnik/mapnik#4005

[sommerluk]

True global alignment is part of Mapnik 3.0.22 release. Should this issue be closed now?

[sommerluk]

Closing this issue.

This has been fixed at the Mapnik side and also backported to the 3.0.x series. Now polygon-pattern-alignment: global means really true global alignment. So starting with Mapnik 3.0.22, now we can use polygon patterns with arbitrary sizes like 113 × 113, and also non-square values like 113 × 59.

I’ve verified this with python-mapnik 3.0.22, and it works correctly. (However, the current node-mapnik still hasn’t this fix, but I think it will be part of the next release.)

Note that currently we do not require Mapnik 3.0.22 in our INSTALLmd, so we can only rely on this feature if we also bump our requiered Mapnik version to at least 3.0.22.