[OSGeo-Discuss] The state of WMS tile caching

[Christopher Schmidt]

On Wed, Nov 26, 2008 at 12:46:48PM +0100, Gilles Bassière wrote:
> I was recently confronted to the same problem. I needed a cached WMS, 
> although on some occasion I would need to perform untiled map requests. 
> Of course, it would have been much easier to send tiled and untiled 
> request to a single front server.
> 
> My idea was to hack TileCache. Indeed, TileCache already has WMS request 
> support et grid calculation and cache and so on. When the requested 
> extent/size does not match the tile grid, TileCache returns an error. I 
> guess it would be possible to catch this error. Then, instead of 
> returning the error to the client, it should be possible to forward the 
> request to the rendering back-end and return the resulting image to the 
> client (without storing it in the cache). I'm not sure whether this 
> could be possible with all back-end. 

At this time, yes, in the future, no. However, I would *never* be
supportive of that change in the code. (There are other implementations
I *would* be supportive of; just not that one.) Specifically, the
problem with that is that there is no trivial way to communicate to the
user "You are using non-cached tiles": the error is the way that we tell
the user. Additionally, the default use of TileCache is that users
*don't* want to allow non-cached hits: Take the openstreetmap example,
where a single non-cached tile hit can take 3-4 minutes to render, and 
realize that if you got a half dozen f those at once, you'd kill most
servers for minutes at a time.

> I did not think of performance 
> either. But I think that could be a solution for someone needing 
> seamless map caching.

As I said, there are other solutions. (Specifically, TileCache rendering
could take a *set* of tiles to fetch, cache each of them, then put them
together.)

> For some reasons we did not implement this idea. The main problem was 
> the lack of support for GetFeatureInfo in TileCache. I'm now thinking of 
> some kind of integration of TileCache within the OGCserver (part of the 
> Mapnik project). It is still a rough idea and, unfortunately, I don't 
> have any time to work on it. Moreover, I doubt if it's reasonable to mix 
> WMS with TMS-based cache. Of course, TMS-based cache is incredibly 
> efficient but it also impose the grid parameters to the client. In my 
> opinion it is an important restriction that reduce interoperability. 
> With such restrictions, it may not be possible to feed OpenLayers with 
> WMS-C stream coming from different servers.

I'm not sure I understand what you mean here. I've combined WMS-C with
different servers many times. (There are limitations in OpenLayers with
regard to using different grids at the moment, but none are unfixable,
just awaiting interested people to invest the time or effort). WMS-C is
reasonably well defined, well-understood, and well-supported within the
tiled clients on the web. If you can't use tiles - or don't want to -
I've already proposed ways to wrap TileCache in a 'real' WMS server.

> I'm a bit surprised because standard-compliance is an important part of 
> this thread but the OGC discussion paper about tiled WMS was not 
> mentioned (see http://www.opengeospatial.org/standards/wms). 

I missed a mention of 'standards compliance' being an important part of
this thread. Is there a specific reason that *OGC* standards are
important? TMS and WMS-C are widely used in the community, are written
as specifications, have supporting implementations, etc. These *are*
community standards -- documented ones, even -- and I would highly
recommend them over the current state of the art available from OGC to
anyone who cares about solving problems (rather than meeting the terms
of a contract). 

> The paper is more than 1-year old now, does anybody know if there is
> ongoing work or if it could become an implement specification soon? 

The discussion paper indicated has already been replaced twice in
internal OGC discussions. TileCache already implements the WMTS
described in that discussion paper, but since it is going to be thrown
out as soon as the next version of the spec is released, writing clients
for it is silly.

> An important 
> point discussed in the paper is about describing the tile grid so that 
> an arbitrary client can build a valid request.

Huh? 

"The values for LAYER, STYLE, CRS, FORMAT, any mentioned dimensions and
SCALE must exactly match the options that are specified in the
WMS_DescribeTilesResponse document.  TILEROW and TILECOL are integer
indices indicating a particular tile in the tile matrix."

This is no different from TileCache -- you have to request a tile that
the cache knows about. the WMTS request format can be used with
TileCache -- there is nothing you can get out of WMTS that you can't
*already* get out of TileCache, except the URL Format.  

Regards,
-- 
Christopher Schmidt
Web Developer