ResponseMX Blog

It’s been over 6 months since we integrated MapServer with ResponseMX. In that time we’ve used the open source mapping engine for several custom ResponseMX applications, but until now we’ve only been able to offer ResponseMX with MapServer on a Windows operating system.

While the interfaces into MapServer (using MapScript Java) are consistent across both platforms the installations of MapServer are, as you would expect, radically different. All the binaries for MapServer on Windows come as a single package (MS4W). On Linux, however, MapServer is distributed as source code which must be compiled - along with all its dependent libraries.

Help is at hand, though. Frank Warmerdam provides an excellent set of libraries known as FWTools which bundles together most of the libraries required to compile MapServer. This package is a huge shortcut, saving several man-days of effort over configuring and compiling the libraries individually, from scratch.

While there are a number of pitfalls en route to successfully compiling MapServer, nearly all are well documented on the mapserver user forum. However, there was one issue we couldn’t find help for. The following error message occurred when the MapServer library loaded in the JVM:

java.lang.UnsatisfiedLinkError:<br />/usr/local/mapserver-4.8.4/src/mapscript/java/libmapscript.so:  /usr/local/FWTools-1.3.1/lib/libtiff.so.3: undefined symbol:  jpeg_resync_to_restart.

This error originates from the libtiff library, and occurs even if tiff support is turned off when compiling MapServer. It had us scratching our heads for some time. The problem is caused by a conflict between the jpeg library in FWTools and the jpeg library that comes with Java (read more). Fortunately this problem is specific to the latest versions of FWTools, v1.3.1 and v1.3.2. Installing and using an earlier version (v1.1.1) resolves the runtime error.

Don Murray from Safe Software just drew our attention to a new development in the JSON world GeoJSON, which is a draft specification for a data-interchange format for a variety of geographic data structures.

We’ve been using JSON in this way for a little while to encode features when they are passed between a ResponseMX client and the server as it’s a far more compact than say GML. The draft spec. looks pretty good and we will be considering adopting GeoJSON in the near future.

Working in support at Dotted Eyes we are often asked how to get best performance out of ResponseMX.

This answer to this question can be split into a few different categories:

1. Preparation of your map data

2. Optimisation of Server Client communications

3. Server configuration

Today’s post is going to cover topic 1, the other two topics will be covered in the coming weeks

Preparation of map data

This really means make sure you are showing your data in the most efficient manner.

Where possible the more visible information you can display on a raster layers the better, remember, ‘if you want your data faster, choose vector not raster’. If you have several vector layers being displayed for illustrative only purposes you may want to consider creating a raster version of them, or superimposing them onto your current raster layer.

Many people think this is not possible because they require their vector data to perform geospatial queries on. However this can still be achieved, using MapInfo Pro you can create raster images with imposed vector data (practically for scales up to 1-20000k and upwards), then add your vector data to the map as non visible layers, in the latest version of ResponseMX you can still query non visible layers using the info and search tools. (Even if you haven’t got MapInfo Pro I’m sure the helpful data team at Dotted Eyes will be able to sort you out).

It is of course not always possible to raster a vector data set if for example the vector data changes frequently as it does in the Exclusion and Restriction layers used in the Countryside Council for Wales Access Land application.

If you have to show vector data on your map the thing to remember is “the more you show, the slower you’ll go”. The reason for this is the Map Engine will first display the raster image very quickly, and will then have to draw each individual vector feature on top of it.

ResponseMX comes with a few tricks to help you manage this problem.

Layer Zoom Thresholds: this allow you to set the maximum zoom width a layer can be displayed at, a useful trick to stop too much data being shown at once.

Map bounding: setting the maximum zoom-width the map can be displayed at stops the user zooming out and viewing too much data at once.

Layer Behavior: The ResponseMX layer control allow you to set how groups of layers behave. A useful trick is to group multiple layers of vector data together and only allow one to be shown at a time (similar to how radio buttons) limiting the amount of vector data being shown at once.

Data Filtering: In extreme cases where a lot of vector data MUST be shown at a very high zoom-width you may want to implement filtering of your data by attribute. Although ResponseMX does not come with our of the box configuration to do this the ResponseMX development team have implemented such logic for customers, and would be happy to talk through your needs should you wish similar functionality.

A similar result can be achieved without development by splitting your data into separate tab files and using the layer behaviour functionality to limit how much of it can be shown at once.

What this all boils down to, when it comes to performance, showing data graphically on a map using ResponseMX is no different then showing data as html on a web page, the more information you want to show at once the slower your responses will be. The key is short snappy requests controlling the users need to get at information through a well managed user interface.

Dotted Eyes has just deployed a ResponseMX application as part of Corporate GIS solution at Ashfield District Council. The project involved integration with Northgate’s FrontOffice CRM application, allowing customer service representatives to call an instance of ResponseMX to report abandoned cars and streetlight failures from information supplied by members of the public making inbound calls.

Once the location of the event is confirmed (either over the phone or by searching for an address using a BS7666 compliant gazetteer), the coordinates, id of an asset (e.g. streetlight) and a captured map image are all passed back into the CRM application, and ResponseMX closes down automatically. This will assist Ashfield District Council in improving the call response targets that have been set, as well as providing a high level of customer service for the general public. David Cleary, Ashfield GIS Technician has said “The CRM system is working fine and the Customer Services Manager has been showing it to the CRM Staff who can’t wait to use it.”

Following a request from Saj at Leicestershire County Council I’ve put together a demo page for the FlashVars Action API that can be used in conjunction with the RMX Wrapper JavaScript API to specify the actions that are executed in the initial map request when your application loads.