OSGeo has a decent amount of information on creating tile caches for WMSs (AKA WMS-Cs). The general idea seems to be 1) establish a grid system 2) cache any request that conforms to the grid and 3) simply process any other WMS request normally [alternatively deny the request].
The universally accepted problem with caches, then, is that they take up a TON of room. They’re also usually in a single spatial representation, by virtual of their size. Hence, if your project requires the ability to reproject, you can’t reasonably build caches for everything. So instead, you build a tile-cache for the backend and refer to it as overview images, pyramids, or whatnot. If you’re dealing only with raster data, your WMS’s sole purpose now is to load tiled data, resize and reproject it if necessary, and spit out tiled data.
It starts to become clear that WMS-C is something that WMS servers would want to support, in addition to WMS clients. Doing so would allow custom WMS-C grid definitions and projections, but allow the data owners to maintain only traditional single-projection tile caches. Native projection WMS-C servers could push tiles to larger banks of WMS-C servers for reprojection and resizing. The WMS-C tile-owning servers would effectively act as ESRI’s ArcSDE, but exposed via HTTP.
In case people are already doing this, I’ll stick a toe out towards the absurd. If a standard grid was chosen in a standard projection, this would allow the caching of reprojection-related data. At minimum, bounding boxes could be stored for each projection, corresponding to the maximum extents fully contained within each native-projection tile. On the other hand, if you’re going to cache, cache something impressive!! GDAL’s complex orchestra of affline & reprojection transforms could reasonably(?) be reduced to a serializable set of pixel-pushing operatings without any knowledge of the underlying datasets.
Stick a whole foot into the absurd, and you’ll see that WMS-C reprojection engines will naturally become RRTWS’s — raster reprojection template web services — the way of the future. Pixel-pushing thin-clients like Flash will have the ability to reproject without needing bulky clientside APIs. Client-side vector libraries could use these pixel-lookups to rasterize directly to alternative projections. Oh, the places we’ll go!
