In the previous article about Incident Mapping I covered off the main GIS integration bits – it’s about the map (not the GIS), it needs to be dead simple, the map is there for context (initially), layers (avoid!), and search.


You’ll note that I haven’t covered off the Incident Management System (IMS) specific capability yet. My rationale is that if you don’t get the basic map capabilities right it really doesn’t matter because your users won’t care about the incidents, resources, sites, and other information that are stored in the IMS software. This is a simple fact about operators – if something isn’t adding value to their day (saving time, showing something they can’t get elsewhere, etc.) they won’t use it and may even campaign against it. Once you get a good mapping capability though – you’re beginning to make magic. Adding in the Incident, Resources, Sites (we’ll cover Sites in a later article), and other incident-related information makes the mapping system incredibly powerful. The best systems in the world that I have seen (and built some) use a world-class GIS in the background, but the operators just call it a map. If you can get your operators to use “the map” you will likely win a place in the operations centre front room.

So – how do you go about getting the key pieces of the IMS into a GIS-enabled map? It’s dead easy if you consider anything that has, or may have, a position on the planet as being “spatial” (say “special” if you’re dealing with the non-GIS folk). If you allow a position (point, line, or polygon) to be attached to each incident, site, resource, and other items in the IMS you will be able to blow away your operators – once they see things on the map they won’t want to go back.

There are two key things that need to be considered when integrating your IMS data into the map – the Symbology and the Interactive Information that shows when a user touches/clicks on the IMS item.


Symbology must be as simple as possible. If you need to show more than a type (e.g. a symbol for an Incident type) be sure that you can train your users on what the various colours and other cartographic additions (hatches, highlights, direction arrows, etc.) are for. If you can’t create a one-pager that explains the symbology you have gone way too far into the land of complexity. Though many in the GIS and advanced realms will disagree with me, I’ll suggest looking to Google Maps and Microsoft Bing for ideas on symbology. In Canada we have the Emergency Management Symbology as well that can help start your process – it isn’t perfect by a long shot but it gets the discussion going.


The touch/click information that is displayed needs to be simple as well. If you are showing an Incident for example a few key fields should be displayed (e.g. incident name, type, and perhaps a limited description). The key here will be to present a clickable/touchable link that brings the user directly to the full Incident. This allows your operators to use the map as their way of finding things. Most operators will begin using the map as their way around things – it is just way easier for them.


There are other areas that need to be considered for an effective (and successful!) integration of GIS, but if you get the basic views done you’ll be well on your way. As your system gets traction consider the following maps that will be needed:

  • General Map (all incidents, key deployed resources, loads of external layers, etc.)
  • Incident Map – Active Sites and Resources, Incident-specific layers, Incident markup layers.
  • Detail Map – use for Sites, Resources, and other things that are managed in the system (even a Contact)
  • Command Wall – Used in an Operations Centre as a main display for use by all in the op centre.


Where you have mobile personnel you will need to consider their smartphones and tablets. They value of a map in the field is huge, but making your team effective in the field and at remote locations is critical. You will want to consider the technology footprint of your IMS and your GIS back-end to make sure that you can meet their needs. Knowing whether your mobile users will just view information on the map or if they will interact (add/change information) with it will help you decide what approach you should take. If field data collection (e.g. damage assessments, power line conditions) is needed you will likely benefit from a GIS that has a big ecosystem of tools and capabilities behind it.


I get asked a lot about whether an open source GIS is the way to go or if a commercial GIS makes more sense. To me it really depends on what kind of a team you have behind you. If your team is already using a particular technology you may be best off going with it but that assumes that you are able to meet all of your needs with that platform. The details of such a decision are way too deep for a blog article but you’ll want to consider this whole article and the earlier one but add in the following to your decision:

  • SDKs – is there a stable SDK available for use? Without this you are going to incur major revision costs as the technology churns.
  • Platform Support – does the solution work on the desktop, browser, tablet, and smartphone? If you need to support all of these platforms you’re best off using something that works “out of the box” though you’ll inevitably have to do some development if you want a fully tailored solution.
  • Community – how big is the developer and IT community behind the technology? You want a large community so you don’t end up tied to a very small vendor base.
  • Standards – does the solution really support standards (e.g. OGC standards) or does it just do the bare minimum? Claims that systems are “standards” compatible need to be tested. Assuming these claims are true has cost me dearly in the past. For a bit more on why standards are important see this past article.

Hopefully this article has added to your understanding of how GIS fits into IMS software. A properly implemented mapping system will make your IMS begin to feel magical – training costs will drop instead of rise, and situational awareness levels will rise.

If you’re enjoying this article, I invite you to join our Technology in Ops newsletter below. We’ll be sharing similar information aimed at operators and the tech teams that back them up.

Technology in Operations Newsletter

We respect your email privacy