Especially on s3 be careful to choose every of the grid settings before generating the tiles.
If you change one of them you must regenerate all the tiles.

The resolutions in [px/m] describes all the resolutions available for this layer.
For a raster layer, have a look to the maximum resolution of the source files. It is not needed
to generate tiles at smaller resolutions than the sources, it is preferable to use the OpenLayers client zoom.
Note that you can add a resolution in the end without regenerating all the tiles.

The bbox should match the resolution of the extent. CAREFUL: you will have big issue if you
use this parameter to generate the tile on a restricted area: use the bbox on the layer instead.

The srs specifies the code of the projection.

The unit is the unit used by the projection.

The tile_size is the tile size in [px], defaults to 256.

The matrix_identifier is zoom by default and can also be set to resolution. It specifies how the z index is build to store
the tiles, for example, for the resolutions [2, 1, 0.5] the used values are [0, 1, 2] based on the zoom
and [2, 1, 0_5] based on the resolution. The second has the advantage of allowing to add a new
resolution without regenerating all the tiles, but it does not work with MapCache.

To generate the file paths and the WMTS capabilities we need additional information:

The mime_type of the tiles, it’s also used by the WMS GetMap and to upload the tiles.

The wmts_style defaults to ‘default’.

The extension is used to end the filename.

The dimensions (defaults to []) is an array of objects that have a name,
a default value specified in the capabilities,
a value to generate the tiles (it can be overwritten by an argument),
and an array of values that contains all the possible values available in the capabilities.

For example if you generate the tiles and capabilities with the following configuration:

dimensions:-name:DATEdefault:2012value:2012values:[2012]

then with the following configuration:

dimensions:-name:DATEdefault:2012value:2013values:[2012,2013]

We will have two set of tiles 2012 and 2013, both accessible by the capabilities, and by default we will see the first set of tiles.

The metatiles are activated by setting meta to on (by default it’s off).

The metatiles are used for two things: first to generate multiple tiles with only one WMS query.
By setting meta_size to 8 we will generate a square of 8 by 8 tiles in one shot.

The second usage of metatiles is prevent cut label names: this is solved by getting a bigger image
and cutting the borders. The meta_buffer should be set to a bigger value than half the size of the longest label.

To be able to generate legends with ./buildout/bin/generate_controler --generate_legend_images
you should have legend_mime and legend_extention in the layer config.

for example:

legend_mime:image/pnglegend_extention:png

Then it will create a legend image per layer and per zoom level named
.../1.0.0/{{layer}}/{{wmts_style}}/legend{{zoom}}.{{legend_extention}}
only if she is deferent than the previous zoom level. If we have only one legend image
it still stores in the file named legend0.{{legend_extention}}.

When we do ./buildout/bin/generate_controler --generate_wmts-capabilities we will at first
parse the legend images to generate a layer config like this:

The additional value needed by the WMS is the URL of the server and the layers.

The previously defined mime_type is also used in the WMS requests.

To customise the request you also have the attributes params, headers
and generate_salt.
In params you can specify additional parameter of the WMS request,
in headers you can modify the request headers. See the
Proxy/cache issue for additional informations.

We can configure some tile commands to process the tiles.
They can be automatically be called in the tile generation it we set the property
post_process or pre_hash_post_process in the layer configuration.

The process is a set of names processes, and each one has a list of commands declared like this:

process:# root process configoptipng:# the process command-cmd:optipng %(args)s -q -zc9 -zm8 -zs3 -f5 -o %(out)s %(in)s# the command lineneed_out:true# if false the command rewrite the input file, default to falsearg:# argument used with the defferant log switches, all default to ''default:'-q'# the argument used by defaultquiet:'-q'# the arbument used in quiet modeverbose:'-v'# the argument used in verbose modedebug:'-log/tmp/optipng.log'# the argument user in debug mode

There two ways to serve the tiles, with Apache configuration, or with an internal server.

The advantage of the internal server are:

Can distribute Mbtiles or Berkley DB.

Return 204 No Content HTTP code in place of 404 Not Found (or 403 Forbidden for s3).

Can be used in KVP mode.

Can have zone per layer where are the tiles, otherwise it redirect on mapcache.

To generate the Apache configuration we use the command:

./buildout/bin/generate_controller --generate-apache-config

The server can be configure as it:

server:layers:a_layer# Restrict to serve an certain number of layers [default to all]cache:mbtiles# The used cache [default use generation/default_cache]# the URL without location to MapCache, [default to http://localhost/]mapcache_base:http://localhost/mapcache_headers:# headers, can be used to access to an other Apache vhost [default to {}]Host:localhostgeoms_redirect:true# use the geoms to redirect to MapCache [defaut to false]# allowed extension in the static path (default value), not used for s3.static_allow_extension:[jpeg,png,xml,js,html,css]

The minimal config is to enable it:

server:{}

You should also configure the http_url of the used cache, to something like
https://%(host)s/${instanceid}/tiles or like
https://%(host)s/${instanceid}/wsgi/tiles if you use the Pyramid view.

Update from optparse to argparse, and some argument refactoring, use --help to see the new version.

Add support of Blackbery DB (bsddb).

The tile server is completely rewrite, now it support all cache,
REST and KVP interface, GetFeatureInfo request,
and it can be used as a pyramid view or as a WSGI server.
More informations in the istribute the tiles chapter.

Add three strategy to bypass the proxy/cache: Use the headers
Cache-Control:no-cache,no-store, Pragma: no-cache (default).
Use localhost in the URL and the header Host: <host_name> (recommended).
Add a SALT random argument (if the above don’t work).
More informations in the Proxy/cache issue chapter.

Improve the dimensions usage by adding it ti the WMS requests,
And add a --dimensions argument of generate_tiles to change the dimensions values.

Extract generate_cost and generate_amazon from generate_controler.

Now we can creates legends, see the Legends chapter.

Now the tiles generation display generation statistics at the ends.

The EC2 configuration is moved in a separate structure, see README for more informations.