Overview 

As performance of map rendering in IntraMaps/Enterprise Maps is implicitly linked to the quality of the data supplied it follows that invalid or unoptimised data, as well as heavy use of data formats known to perform worse than others, will have a large impact on your use base and contribute to a poor user experience. This impact is felt for anyone accessing a map that contains references to affected data.  

This article is designed to provide some best practices to optimise data configured in our Enterprise GIS viewers and ensure the solution is the most performant for your user base. 

We highly recommend that you also take a look at the Spatial Performance Workshop and the Performing Health Check on your Spatial Data Workshop.

Map Configuration 

• Ensure the map and all layers are the same CRS. Mixing source projections and re-projecting data on the fly degrade performance.
  
  
• Use MapManager Health checks to troubleshoot potential performance issues with your maps. 
   
• Ensure scale layering is appropriately set for every layer. Often a layer disabled by default will cause long render times when made visible at full extents. This is particularly true of label and contour layers. It is important to always set a scale value at layer level even if you have already added scale at class, style or label level. 
   
• Contour layers tend to be very large, do not use contours below 1m. Do not classify contours as the processing time will greatly affect the rendering performance. Instead extract the data you want to classify (i.e. 5m, 10m, etc...) in its own file and use this as a separate layer. Ensure an appropriate scale is set at the layer level and test your map in MapManager with the contours on at the max scale set for the layer by panning around. The map should render in less than 2 seconds. 
   
• Avoid deeply nested group layers

• Avoid maps with an excessively high layer count.  The more layers in a map, the poorer the performance.

• For annotation layers set Min and Max Scale at the layer level. Setting exclusively at the label level results in increased processing time and degraded map performance. 
  See How to Improve Label Performance in IntraMaps

• Leverage user access layers, including group templates (25A and above), basemaps or additional modules to keep maps as lean as possible.  
   
• Test your Map in MapMananger by panning around at various scales, change the visibility of layer that are currently off and continue panning around at various scales, to try and use your map as end users would. Map rendering needs to be under 2 seconds regardless of scale and layer visibility. For a quick demonstration see How to Test Map Performance in MapManager

Raster Layers 

• For aerial photography or other RGB imagery the recommended raster format to use is a Cloud Optimised GeoTIFF (aka COG) format. This format is optimised for web mapping and you should be able to use your desktop GIS of choice (for example QGIS) to accomplish this. 

• Use Basemaps, instead of adding aerial layers directly to maps. Consume tile services directly from any relevant data providers (E.g. LINZ, Metromap, Nearmap etc). 
  If needing to create your own TMS sources and hold the required T1 license you can use the T1 Tile Engine. For more information please review the Event Recording: Spatial Workshop - Creating tile sources in Tile Manager (link requires Customer Community login)
   
• Use ECW or GeoTIFF formats only, preferably GeoTIFF. While other formats like JP2 are currently supported, they render poorly. 
  See the first point above about Cloud Optimised GeoTIFF.

• Ensure raster layers have appropriately generated overviews. Lack of overviews/pyramids in GeoTIFF has a particularly big performance impact. 
  If dealing with an RGB layer see the first point above about Cloud Optimised GeoTIFF.
  MapManager Health check now reports missing overviews and from 25A these layers cannot be imported to the Spatial Catalogue

• Use a single mosaic image for Aerial layers served via the T1 Tile Engine and not many different layers grouped together and presented as a single layer (such as VRT or Tile Index layers). The fewer images loaded and displayed at the same time, the better performance outcomes. 
  Convert VRT or Tile Index aerials to Cloud Optimised GeoTIFF (aka COG) format

• WMS layers perform very poorly and are a point of failure on a map draw, if the third-party service is unresponsive or unavailable. Never explicitly use a WMS layer in a map. WMS should only be used when printing a basemap and configured as the print layer against the basemap. 

Vector Layers 

• Use Shape files only. Other vector formats (E.g. MapInfo TAB) perform much poorer and result in a diminished user experience. 
  
  
• Ensure all vector data sources contain a single geometry type only. Do not mix geometry types in source data, including database layers that are the source for SHP snapshots/extracts used in IntraMaps configuration. Vector data and sources must not include GeometryCollection types.
  
  
• Ensure data sources do not contain null geometries. Data must be pre-processed to remove NULL geometries.

• Ensure all vector files include a spatial index. For example, all shape files generated by T1 include a qix spatial index file. Any SHP file data uploaded must include this.  

• Keep vector data sets narrow. Large vector data sets with many columns or including many wide character fields perform worse than streamlined data sources. For example anything used for a selection layer should only include fields for mapkey and any label or classification to be applied. 

• Layers with very complex and/or very large objects perform poorly and should not be used in a web GIS. Geometries in these layers will need to be simplified or rasterised to be acceptable for use in a web based GIS application. Some potential methods to simplify data:

• Process large complex line geometries, such as contours, into smaller segments by running a process in your desktop GIS of choice to split lines to a maximum length. 
  For example QGIS has a Processing>Toolbox>Vector Geometry>Split at Maximum Length function
• Simplify large complex polygon geometries, such as coastlines, by running a node thinning process in your desktop GIS of choice.
• Split large complex polygon geometries into smaller areas in your desktop GIS of choice for better spatial index coverage. Large objects covering the entire extent of a layer with many records causes the spatial index to be ineffective.
• Complex vector data that has obviously been derived from a raster format should be rasterised using your desktop GIS of choice, or alternatively use the source raster layer if you have it. Some common examples of these slow, complex vector layers are
• flooding, 
• impervious surface
• some vegetation mapping
  
  

• Avoid complex expressions when classifying your layers, it is best to pre-process the data so that the expression used to classify the data is simple.

Selection Layers 

• Limit the number of selection layers you have per module . 
  Every time a user makes a selection using one of the map selection tools, the selection is not only performed against the topmost layer (as configured in the selection layer section of the configuration for a module) but also against the other selection layers for potential results. 
• Layers with a lot of columns perform poorly. When using a selection layer (Shape or SQL) it is critical to ensure that you only include the columns you need for the purpose of rendering, in other words only include the columns required for labelling, styling and classification, and the mapkey column. Use info panel queries to provide additional information related to the layer 
• For attribute fields that will be used for mapkey references use an Integer column as it performs best. Never use Real or Decimal data types for mapkey.