This is the 6th article in a series about Creating Incident Management System (IMS) Software.
If you are a GIS expert this article will be hard to read. I’m a big believer that GIS is incredibly powerful for incident management but I believe that it is powerful when the GIS is in the background – users just use the system and it works. The fact that there is a deep GIS in the background is irrelevant to users of a world-class system. Keep that in mind as you read through this article.
My intent here is to share the key capabilities that you can use from a GIS perspective in building a world-class incident management system. This topic is huge so I am breaking this article into two pieces. I’ll add that each area I cover here could easily become an article or series of articles, but I am sharing this with you to get the thinking process going.
If you take the cliché “a picture is worth a thousand words” and project it (for those in the GIS world – if you caught that pun – good on you!) to the mapping realm, what is a map worth? The answer depends but the goal should be that a map, with your key situational awareness information and incident information, should be worth many thousands of words or more. The key question is what pieces do you need in order to make the map that valuable.
GUIDING PREMISE – IT IS A MAP, NOT A GIS…
The first thing that MUST be in place is the focus on the real end user. The map tools that are part of an IMS should be aimed at the operators and decisions makers. If you think your end user is the GIS team I suggest putting your project down now and go build some GIS capabilities – because if that is the focus you will not succeed so spend the time and effort elsewhere. You may have a very valid reason to stay focused on your GIS capabilities – but let’s not kid ourselves, if you push GIS on an operator you’re not going to get the results you want. I half jokingly say that our main users “can’t even spell GIS”. The user should consider the GIS-based solution as their “smart map” or their “situation map” – if they need to know what GIS stands for, things haven’t been
For those technical folk, rest assured, that the solution must be fully GIS-based and it will expose many capabilities of GIS. However, the best solutions don’t use the GIS lingo nor do they expose the depths of GIS technology. The best provide a near magical capability though.
GOAL FOR INCIDENT MAPPING – SIMPLIFY THE SITUATION
The main goal for GIS integration in IMS software is to simplify things by making information understandable. Seeing a list of impacted areas on a spreadsheet is a completely different experience than seeing them on a map. When we see a map we immediately get a sense of how some things relate (are impact areas clumped up or spread out? Is there a particular area where everything has happened? Is there an area where we are missing information (e.g. sometime the most severely damaged areas can’t report back to tell you what has happened). The map’s job is to make the information that have been gathered understood.
USE THE MAP FOR CONTEXT
Every user will look at a map differently if they are doing different things. The Operations staff in an EOC will look at the big picture with current information while a Planning cell may look into the future at particular smaller areas. Similarly the in-field Incident Commander will have her own view of things – likely focused on the immediate tactical area. Senior decision makers will be looking for the areas that need their attention. The key thing here is that every user brings their context and needs into a situation.
The map tells a story in an incident management system. Use it to tell your users where the incident is, what its boundaries and key areas are, where the deployed resources are, what key sites are engaged, etc.
Present the information in dead-simple ways – don’t rely on a table of attributes to tell a story – use them to build a story. Seeing lookup codes (e.g. “building type: 1”, “floors = 3”, “units=6”) doesn’t tell a story – but you can use them to build a story (e.g. “Multi-unit residential building, 3 stories, 6 apartments”) that adds value to the user.
I’m not saying that the attributes aren’t useful or that they should be completely hidden. Use them to build a story and the user will decide whether they need more information or not. If they need more information they will dig in and will have justified learning the deep guts of the GIS – the tables, attributes, concept of layers, etc. This is a great example of applying levels-of-depth.
LAYERS – DON’T GO THERE, NOT DIRECTLY AT LEAST…
GIS-savvy folk know that one of the most powerful concepts in using GIS technology is the ability to control what layers are visible (or hidden). I can’t stress how powerful the layer concept is but this concept is also hard for non-GIS folk to grasp at first. I have seen incredibly talented first responders and emergency managers look at a GIS-enabled map and the “layer control” (tree or just a list) that show the list of layers – and they were completely lost. This inability to get the layer concept isn’t an intelligence or capacity issue by any means – it is a failure of the GIS team to understand the context of their users.
The operationally-focused user thinks in terms of what they want to do and what information they need. If we take a Maritime Search & Rescue (SAR) coordinator for example, they are thinking about tides, currents, current weather, location of vessels, search patterns that have been run and that are planned, and much more. The list of “layers” that a Maritime SAR Coordinator would need to turn on and off is horrendously long and in a high-stress environment you don’t want your users making natural mistake. So – what is the better approach? Simple – figure out what layers they will need depending on their context – and there may be multiple contexts/modes that they operate in. For example the Maritime SAR Coordinator will have several different views that they care about: Looking at all of the SAR incidents that they are handling; focusing on a small area for a particular SAR Event; looking at a larger area for a SAR Event. They can’t be figuring out which map layers show up so you’ll need to know what layers are important – sit with them, help them, learn what they are looking for. The operationally-focused users are amazing to work with. They are unambiguous so they will tell you what is helping and what isn’t. However, they won’t say “I want the 1:250,000 base map here instead of the 1:500,000”. Instead they’ll tell you “this map looks like crap here” – it is your job to figure out what this means. They’ll be excited when it doesn’t “look like crap” so it’ll be worth it.
When it comes to the main base maps consider the approach that has become the norm in web mapping – have a “Roads”, “Satellite”, “Hybrid” selection. Everyone that uses Google Maps, Bing Maps, and ArcGIS Viewers knows how to make these selections. Our Maritime SAR Coordinator would likely want a “Maritime” selection that turns on the nautical charts instead but you get the idea.
SEARCHING
The power of searching through GIS data can’t be underestimated but you need to remember that there may be multiple key things that need to be searched and then you need to think about how your users will be thinking when they search for something. I have never met a non-GIS person that said “I am going to select the place name layer and do a query”. That’s a ridiculous thought but many GIS tools expect the users to think in this way.
Let’s take our Maritime SAR controller again. They just took a call from someone who saw a flare from land. They are thinking “she is near Joe Bat’s Arm in Newfoundland – I need to find that on the map.” – so build a really dead simple “find a place” tool. Not an Address search tool – a “find a place” tool. In Canada, when I built the SAR software in the 90s (still in use today believe it or not) this was the single most powerful and impressive tool – we used the Canadian Geographical Names Data Base (CGNDB) as our data, allowed users to add local place names. A dead simple, single table database. The simplicity was incredible and that made it powerful.
In the next article we’ll cover off the deep IMS integration that makes the magic…
