Support metatiling and buffers in mode=tile

[pramsey]

Using mode=tile currently results in less-than-aesthetic results for any non-trivially labelled or styled layer. The solution is the same as in static cache systems: render to a slightly larger canvas and clip (buffering); render to a much larger canvas and extract (metatiling). Both approaches need to be implemented together, since metatiling alone will retain artefacts along the larger metaboundaries.

In mode=tile, the tiles are of fixed size (256) dictated by the tile APIs, and are organized such that the metatiles are obvious: the 2:1 metatile for a tile is the parent tile in the next highest zoom level; the 4:1 metatile is the grandparent tile in the zoom level two higher.

MapServer currently has a label cache feature that is used by tilecache to provide proper labeling in the presence of buffered images, labelcache_map_edge_buffer. When buffering is turned on in mode=tile, the labelcache_map_edge_buffer will be automatically set to an appropriate inverse value to ensure that labels to not wrap over the metatile edges.

Here is an example WEB object that uses the enhanced support for buffers and metatiles in mode=tile:

WEB
  METADATA
    "tile_map_edge_buffer" "16" # 16 pixel rendering buffer
    "tile_metatile_level" "2" # metatile 2 levels up (4:1 = 1024px metatile)
  END
END

The default behavior of mode=tile continues to be no metatiling and no buffering. For top zoom levels (levels 0, 1 and 2) no metatiling will occur.

[pramsey]

First cut of feature.

[pramsey]

In general, for tiled modes, PARTIALS should be set to FALSE. Do we want to autoset this (booo! side effect!) or leave it be, even knowing that the default value is TRUE, so getting bad tiles will be pretty common. Half-way compromise: change the default to TRUE when mode=tile, but leave any explicitly set values alone.

[lagerratrobe]

It would seem to me that if a user has turned on "mode=tile" that they would also want PARTIALS set to false at the same time. That's what I would want at least. What's the worst side-effect that this would cause, lack of labeling in certain cases?

[pramsey]

There's a danger when a computer starts doing "what I mean" and not "what I say". It makes debugging very hard. Even changing the default value to false in the case of unspecified PARTIALS is problematic, since the default is documented as true, and a conditional default value is a complex notion indeed. That's the argument against, in a nutshell.

[pramsey]

Committed to trunk at r9816

[sdlime]

Since this code calls GD specifically this functionality will need some updating with the graphics API. The problems show up when using "tile_map_edge_buffer" and non-GD drivers.

Steve

[sdlime]

A little more on my last comment. The code uses gdCopyImage which in turn operates on the a gdImageObj. Problem is the new rendering code features native pixel buffers so clipping with a buffer or metatile doesn't work for anything but GD. With AGG (at least) you end up with output maps that still include the extra bits that are supposed to be clipped off. I think the solution is to add an image subset function to the graphics API and use that. Waiting to hear from Thomas... -Steve

[sdlime]

I tracked the issue down to a problem with the AGG raster merge method. That has been fixed (at least it works for me) in r10962. -Steve