[Tilecache] cascading TileCache / WMS layers cached individually

Christopher Schmidt crschmidt at metacarta.com
Thu Apr 3 07:15:44 EDT 2008


On Thu, Apr 03, 2008 at 11:38:19AM +0200, Pierre GIRAUD wrote:
> Hello,
> 
> Context :
> 
>   We have a project with one OL WMS layer combining several WMS layers
> (coma separated layers list param in the WMS getMap service).
> By using MapFish layerTree widget (and OL mergeNewParams), the list of
> WMS layers may be changed by the user. This said, it's obvious that we
> can't get this OL layer cached. One can easily imagine that for 3
> different WMS layers, there are 4*3*2*1=24 possible combinations.
> 
>   But as performance is really important, we propose to find an
> alternative to that.
> 
> Proposal :
> 
>   Each WMS layers could be cached individually and then merged by a
> WMS client also being a WMS server for OL.
>   This way, no geospatial data would be processed. Only image
> transformations (blending) would be required.

The way I would do this is to configure the WMS Driver (from GDAL):

"It is possible to configure a WMS Service conforming to a WMS-C cache by
specifying a number of overviews and specifying the 'block size' as the
tile size of the cache. The following example is a sample set up for a
19-level "Global Profile" WMS-C cache:"

http://gdal.org/frmt_wms.html has an example pointing to the Labs WMS-C
server.

This requires GDAL 1.5, but ensures that your requests match up exactly
to the tiles that TileCache wants.

I think this would fix both of your problems.

If you need help setting up such a thing, please let the list know what
your TileCache config looks like, and we can hack it out.

(A GDAL WMS driver is configured in the same way as most RASTER layers,
with the "DATA" statement pointing to the XML file on disk.)

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the Tilecache mailing list