id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
4075	Ability to extract tiles from an existing cache to another	aboudreault	aboudreault	"One of our needs is to generate tiles for a specific extent/region and make a packages or those tiles. This is what I would need that utility to do:

 * Generated the tiles list of the region given (taking in account the zoom levels given, ogr intersects options etc.)
 * If a tile already exists in the cache of the tileset given, it will be simply copied in the extract cache specified
 * If a tile doesn't exists in the cache of the tileset give, render it then copy it in the extract cache specified
 * If a tile already exists in the extract cache specified, do nothing.

My first idea was to create a new utilise called mapcache_extract. I then realized that mapcache_seed handle 80% of the needs and that it would be ugly to duplicate and maintain twice that code.

Here's what I propose:

 * Add a command line option in mapcache_seed: -x, --extract <cache_name>

By specifying that command line option, mapcache_seed will render all needed tiles (if they don't already exists) and extract those tiles in the specified cache. The cache specified must have been added in the xml config. By implementing this this way, all cache formats will be supported directly.

Example of config and use:
{{{

<cache name=""beauce-disk"" type=""disk"">
      <template>/tmp/{tileset}/{grid}/{z}/{x}/{inv_y},{ext}</template>
      <symlink_blank/>
   </cache>

-----------------------------

mapcache_seed --config /opt/osm/mapcache/osm.xml --tileset osm -z 0,10 -e -71.34,45.9,-70.25,46.61 -x beauce-disk
}}}

Implementation details
----------------------

The attached patch is a simple proof of concept that test the idea. It's not the final patch that I would commit in svn. In that patch, I hack the tile->tileset->cache to do the appropriate operations. The patch works well for disk cache (DEPTH_MODE only) but do not work with mbtiles. This is due to some initial operations that should be done in the post_configuration function but aren't since my cache isn't associated to any tileset. 

In the final patch, If the extract option is specified, I would create a temporary tileset (clone of the specified tileset) with a different cache set (the extract cache) and add it cleanly in mapcache_configuration. So, things would be cleaner (no more hack with tile->tileset->cache) and all cache formats will work as expected. 

Before finalizing the patch, tbonfort, what do you think of that feature and the approach. Do you think it's worth to add it in mapcache and agree with to fact to include that in mapcache_seed? Anything else to suggest?
"	enhancement	closed	normal	6.2 release	MapCache	svn-trunk (development)	normal	fixed		dmorissette tbonfort