Month: September 2010

TileCache + lighttpd + FastCGI logging.

Posted by – Thursday 2010-09-30

In this post we will see how to configure the lighttpd HTTP server to get written to its log files the activity of TileCache (version 2.10) when they communicate via the FastCGI protocol.

Finally, we see what it seems a lighttpd feature bug that prevents the TileCache debug log get written to lighttpd log file and how to override this issue.

1. TileCache logging.

TileCache sends its debug output to the (standard error stream by default. This output includes information like the requested tile (its bounding box and x, y, z coords, where z represents the zoom level), time and whether it was a cache hit or cache miss. This information will be indispensable for debugging or estimating how much time the seeding of a WMS cache will last.

2. Configuring lighttpd to receive TileCache debug output.

The very first step to get lighttpd receiving TileCache debug output is that TileCache does generate debug output. In the TileCache configuration file the parameter debug must be set to ‘yes’ for every layer whose debug output is desired.

[cache]
type=Disk
base=/mnt/geodata/tilecache/
 
[municipalities]
debug=yes
type=WMSLayer
url=http://myserver/sdi-lugo?service=WMS&transparent=true
extension=png
size=256,256
bbox=580000,4688000,680000,4850000
layers=municipalities
srs=EPSG:23029
extent_type=loose
maxResolution=200
levels=10

More…

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.

More…