In this blog we will look at how you can improve the performance of your ArcGIS for Server-based WebGIS applications by tweaking the content of the map services that they use.
Before you start
If you’re creating a new WebGIS application, or looking to amend an existing one, you should consider:
- Who’s going to use it?
- What do they want to do with it?
The answers to these will determine what workflows and tools the application will need to support, and consequently what data you need to expose in the application.
The simplest way of improving the performance of a map service (the stated aim of this blog) is to reduce the amount of data that it has to display. Hence if the workflows don’t require a data layer, don’t include it.
It should be noted that improving the performance of a map service will not only improve the individual user’s experience, by making their WebGIS application respond faster, it will actually improve all the users’ experience, by maximising the number of map service requests your server can process, allowing you to support more users on the same infrastructure.
Use the tools provided
The majority of the performance boosters suggested below are in turn suggested by the ArcGIS Desktop Analyze Map tool, so our first recommendation is to use that. It is accessed either from the File menu, or from the Service Editor (part of the map service publication workflow).
The output of the Analyze Map tool is shown in a panel in ArcMap:
– Right click on an entry to view a context menu showing the options for that Error/Warning/Message – note the Help entry, which will link to specific guidance regarding correcting the issue.
1) Create a separate cached basemap map service for static reference data.
If your map contains a lot of reference data, such as country outlines, which isn’t likely to change on a regular basis, then creating a cached basemap map service will improve performance significantly (a cached map service is one in which the data has been rendered into individual image tiles at a range of scales – the server simply has to return the appropriate tiles for a map request, rather than having to process the data and then return a rendered image). Having removed the reference data from your map service you will be left with just your ‘operational’ layers – less data means it will be faster.
Esri are also introducing vector tiles which are similar image tiles but which consist of vector data, allowing them to be resymbolised and labelled dynamically in your WebGIS application – these should be available for use later in 2015.
2) Create separate map services for separate themes or areas of data.
You probably have a lot of operational data, and you could just put it all into one map service, and create one WebGIS application pointing at that. This would satisfy the users who wanted to see everything, but might confuse those with more specific requirements, and would also make your map server work harder than it needed to, rendering layers that aren’t required by the end user.
You can probably divide your data up into logical themes and/or geographic areas – eg, Geology, North Sea. Creating a separate map service for each theme and/or area will allow you to create multiple WebGIS applications which work for different audiences, but will reduce the total number of layers being rendered at any time, thereby improving performance for individual users, but also improving the overall performance of the system. An additional benefit is that you will be able to easily see which particular sets of data are most in demand, as those will be the services that are used the most.
3) Use the same coordinate reference system for your data and WebGIS application.
If your data has to be reprojected on-the-fly every time a map service request is processed, then your performance is obviously going to take a hit – experience indicates that ensuring that your data is stored in the same coordinate reference system as it is displayed in will reduce the response time by up to 50%.
4) Set scale dependencies.
Displaying large scale data at small scales is unlikely to be useful – plotting the locations of individual trees on a continental scale map would be time consuming and pointless. Hence you should set scale dependencies on your layers – in addition to preventing the display of detailed information at small scales, you could flip from a coarse representation of data to a finer one as the user zooms in – this reduces the potential for confusion when layers ‘magically’ appear as you zoom in or out (and then, for example, disappear as you perform a query on the layer, which zooms to the extent of the returned features, which, whoops, means that the layer is actually no longer visible).
1) Generalise data.
If your WebMap is intended to be used for small scale mapping, then it is not worth using very detailed line and polygon vector layers – a large proportion of the stored vertices will effectively be ignored, but will still have to be processed when the server is rendering the data. Use a generalisation tool to thin the vertices. Obviously you could use scale dependency to display the thinned version at small scales, and then the original version at large scales, giving your users good performance at both global and local scales.
2) Put definition queries on your data.
Limit the number of features in your map service – if it’s not needed, exclude it! For example, if you have a feature class containing all regional wells, but your map is only interested in one country, apply a definition query to limit it. Or better still, create a separate dataset just containing the data you need.
3) Simplify your symbology.
This can benefit your map in two ways; firstly by making it easier for users to read, and secondly by improving drawing speed. An optimised style is provided in ArcMap, which is designed to provide faster rendering when the map is published:
1) Use annotation instead of labels.
Labels require placement decisions and therefore will slow your map down.
If you are going to use labels – make them simple and scale dependant! Avoid using halos, offsets and other effects which will slow map rendering down and may be difficult to read.
2) Convert vector data to raster.
If you have a large continuous vector layer that will be used as a base layer (geology, sediment, countries etc.) then converting this to a raster dataset may significantly improve performance.
Using the ArcToolbox Polygon to Raster conversion tool, I converted a sediment layer to a raster and compared the draw times of the vector and raster – it was quite dramatic – the raster was almost 3 times faster to draw than the vector.
Alternatively you might consider a mix of both – create a group layer with both the raster version displaying at small scales and then the vector one on at large scales.
We’d also suggest you refer to the online ArcGIS help, which discusses additional performance enhancing tweaks.
You can improve the performance of your WebGIS applications in a range of ways, including by tweaking the map service content as described. Doing this will improve individual users’ experience and also increase the number of users your current infrastructure can support, so why delay – tweak today (on your pre-production system first, obviously)!
Posted by Ellie Hunt, GIS Consultant, Exprodat.