geographika

There a number of benefits to using a cascading WMS service – a WMS service that is read and then forwarded on through an intermediary WMS server:

• you can cache the service (for example with TileCache) to greatly improve performance
• your application need only worry about a single point of connection, using WMS layers aggregated from many different sources
• you can add additional metadata missing from the source
• services can be reprojected (using GDAL)
• you can merge WMS layers together and server them out as a new map layer

There are also some negatives:

• you have additional server configuration to set up and maintain
• if you are not adding or changing the WMS service you should probably connect to the WMS service directly in the client applications, otherwise there will be a performance hit
• caching may contravene the licensing agreement of the original WMS source

The rest of this post details the steps in setting up a cascading WMS using MapServer. You need MapServer 5.4.1 or higher to implement a secure cascaded WMS service. This example uses a 64-bit version of MapServer 5.6 taken from Tamas Szekeres’s autobuilds site installed in a C:\ms4w64 folder. It also assumes MapServer has been configured with SSL as detailed in another post. In this example I use IIS and Windows Server 2003.

MapServer makes use of libcurl.dll to connect to web resources. The reason I’ve had to learn this is because libcurl.dll is vital when using MapServer as a WMS client, or “a cascading WMS server” – using MapServer to connect to another WMS server and then “forward” them as if they were any other map layer.

libcurl.dll is the library version of the command line tool cURL – a tool written in C (hence the name) that:

The following is the first in a series of posts related to configuring a 64-bit Windows server as a GIS server  using MapServer and Python.

Why move to 64-bit?

If a server’s operating system and hardware are 64-bit it seems a waste not to take advantage of them. It may be better to look at the question why move to 64-bit software, as why wouldn’t you move to 64-bit software?

Its nice to be able to claim one-upmanship over commercial GIS products who are only now bringing out 64 bit versions. However having gone through the pain of setting up Open Source GIS applications on Windows I’m not surprised companies took the time to simplify the process (and wait for Microsoft to do some of the legwork) rather than dealing with all the 32/64 bit support issues too early.

I’ve previously written about using PyISAPie to run Python under IIS – this allows Python scripts to run faster than using CGI. Rather than starting up the Python interpreter each time a request is made to the web server, PyISAPIe starts the interpreter once and only needs to run the script at each request.

TileCache provides a Python-based WMS-C/TMS server – this is allows you create a local disk-based cache of any WMS server (in my case MapServer), and then connect to it through a WMS-C client such as OpenLayers. Using a cache means that rather than have MapServer create an image for every single request for a tile, the first time a tile is requested the image is saved in a folder on the server. On all subsequent requests for the same data TileCache can retrieve this file without needing MapServer. Performance increase is incredible – however watch out for filling up disk space, and remember to empty the cache if you change symbology or update your data.

As mod_python is now officially dead (and has been moved in Apache’s attic), it is yet another reason if you are using Windows servers to run everything through IIS rather than the rather clumsy Apache on Windows. Why pay for Windows, and then install a web server port, thereby losing all the tools, security, and utilities within Windows to manage and administer the web server?

The aim of this post is to describe the set up of TileCache, running through IIS. Read the rest of this entry »

Moving to new versions in OpenSource has in the past been like playing Russian roulette. Just now clicking on “Upgrade to WordPress 3.0″ I thought would lead to a greater understanding of the database schema, template inconsistencies, and plug-in idiosynchrocies of WordPress as I met an inevitable “Upgrade Failed. Please see log for details” message.

But no! Five seconds later, all was successful, and everything looked as before. There have been numerous bug fixes and improvements, but after a brief look through the list I didn’t see any “killer” new features.

In the world of GIS however there are a number of important new versions coming up this summer.

Read the rest of this entry »

There are already a couple of official quick start guides to using Mercurial’s Window’s client program TortoiseHG, but below are the bare details of how to use it with a new account on the BitBucket service.

Read the rest of this entry »

Putting code under source control is on most checklists for modern software development. Even small side projects, scripts, and code snippets can benefit from being under source control. For example:

• When you improve the code others can see the changes and get the benefits
• If someone else improves the code those improvements can be passed back to you via an automated process

BitBucket is a hosting service for the code-source control system Mercurial. Mecurial is part of a new-wave of distributed source control systems that have the following advantages and disadvantages over regular non-distributed source control:

Read the rest of this entry »