Tag: WMS Tiling Client Recommendation

Some TileCache deficiencies (and workarounds).

Posted by – Sunday 2010-11-14

TileCache, as every piece of software complex enough, is not free of deficiencies. In this post I write about some TileCache features (or lack of) which, in my opinion, are deficiencies. These are: (a) a TileCache layer will only work with one set of map resolutions, (b) poor logging, (c) the TileCache seeder always stops on error, (d) the TileCache seeder cannot be restarted from a given point and (e) the lack of support for distributed computing. In some cases a workaround to partially overcome limitations is given.

TileCache version 2.11 is covered in this post.

1. Only one set of map resolutions per TileCache layer.

By nature WMS caches work with finite sets of map resolutions. In my opinion, one deficiency of TileCache is that a layer will only work with one set of map resolutions. For each layer the set of map resolutions is set in the configuration file by using the parameter ‘resolutions’ or by giving both ‘maxResolution’ and ‘zoomLevels’ parameters.

The problem comes when you have to work with more than one set of map resolutions. Say you have a WMS layer named ‘municipalities-boundaries’ that it is cached and must be shown at two different sets of map resolutions, say one with maximum map resolution 100 and the another one with map maximum resolution 200. In this case there would be two possible workarounds. One of them is creating two TileCache layers, say ‘municipalities-boundaries-200’ and ‘municipalities-boundaries-100’, as show in the following TileCache configuration file snippet:


Running two (or more) instances of TileCache.

Posted by – Thursday 2010-09-16

TileCache is caching system that caches a Web Map Service (WMS) at a discrete set of map resolutions. Sometimes two (or more) WMS caches working at different sets of map resolutions are needed, and a possible solution can be running two (or more) instances of TileCache.

In first section we briefly introduce WMS caches and TileCache.

In the second section, it is seen why running two instances of TileCache it is needed. We have created a dynamic map, based on the OpenLayers library, which is inserted in a web page. Depending on client display resolution, the map can be shown cropped. To avoid it, on map initialization its resolution (map units per pixel) is changed in function of client display resolution. A side effect of this solution is that in case the WMS layers are cached, we will need to run more than one instance of TileCache.

In the third section we show how to install and configure one instance of TileCache on a Linux server.

Finally, in the fourth section the previous setup is generalized to install two instances of TileCache.

1. About WMS caches and TileCache.

Rendering WMS images is a CPU intensive task, usually resulting in high load times on client side. Thus, WMS cache systems, that store and send already rendered images as response to WMS GetMap requests, are of interest for two resasons: on server side the rendering work already done by the computer is reused, and on client side load times decrease by orders of magnitude.

WMS caches are conceptually very similar to other types of caches. When a WMS GetMap request is received by a WMS cache, a cache hit or a cache miss will happen. In case of cache hit, the requested image is already rendered and stored in the WMS cache and it is sent to the requesting client. In case of cache miss, the requested image is not present in the WMS cache, so (a) the request is forwarded to the WMS server, (b) the WMS server renders the image, (c) the rendered image is sent to the WMS cache, (d) the rendered image is sent to client and (e) it is also stored in the WMS cache. Note that it is assumed that clients must always send all their WMS requests to the WMS cache, not to the WMS server.