Increasing ResponseMX performance: Part 1
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.
