
Communications desk. Incoming reports were posted on Google Earth/Google Maps by remote volunteers, then displayed in the emergency coordination center (ECC).
On April 27, a virtual team of volunteers from HumaniNet and GISCorps, working remotely, entered reports generated by Multnomah County hospitals and transportation teams in Portland, Oregon, during Exercise Cascadia Peril.
The process was straightforward: reports arrived in the emergency coordination center (ECC) by radio (see photo) and were submitted to the on-site HumaniNet team for entry into Trac, our collaborative workspace. They were then picked up by five “mappers” in four states, converted to kml files, and returned to the on-site team for posting in a master map created with Google Earth (GE). This was displayed on ECC monitors, side by side with the maps created by the county GIS team. The map on our exercise page is the Google Maps (GM) version.
Below, our Portland team (Matt Blair, Sue Gemmell, Marcelle Caturia, and I) will comment on the lessons learned during and after the exercise.
Our thanks to Dave Houghton, director of county emergency management, and his team for their cooperation and the opportunity to participate. Dave believes that this is the first time that a remote volunteer mapping team has supported a disaster response exercise in the U.S. We believe that the concept works, and we invite you to review our findings and post your own questions and comments.
In a separate post, we will ask the five terrific volunteer mappers to write their comments. They are: Michele Cote and Joe Ludwig of HumaniNet and Mary Meade, Mike Price, and Paul Trudt of GISCorps. Sincere thanks also to Shoreh Elhami of GISCorps for her outstanding collaboration!
Initial observations
From Matt Blair:
- An on-site coordinator could send data reports to a remote support team outside the disaster zone, and they can return useful situational awareness maps over a minimal, satellite-based internet connection.
- Using off-the-shelf, low-cost and free tools, a remote team of volunteers can identify and label critical infrastructure in a city they don’t know well, if at all.
- It is critical to give careful thought to what kind of information you need to collect in each status report, and how that information can be depicted on a map, before the disaster starts.
- The reporting date and time, reporter’s name and contact information should be required for every report submitted. This allows decision makers to understand how current the information is, whom they should contact for an update, and how.
From Sue Gemmell:
- Team must be able to stay focused on the ultimate purpose of the maps.To stay focused on the purpose, it is necessary to know who will use the maps, and the decisions and actions that will be supported by the maps. This focus will ensure that the right data model and process can be supported as it is modified during the response. My recommendation: at the initial outset of the response, write user profiles (a paragraph or two). For each profile, identify actions and decisions (scenarios) that the maps will support. For those actions and decisions, identify the data that is required. As the response unfolds, changes to data model and process will be needed. The mapping team will be able to use the profiles and scenarios to decide whether and how to make changes by answering the question, “will the changes to the process/model support the end user’s ability to make decisions and perform actions?”
- The information gathered in the reports needs to be unambiguous.
The report forms (especially the hospital form) need to be analyzed and redesigned so that the content supports the ultimate purpose of the maps, as described in comment #1. My recommendation: review reporting tools in conjunction with user profiles, actions and decisions, and data needs. The reporting tools must align with the data needs.
In conclusion: a little planning up front – review of purpose and tools – at the onset of the response – will ensure the best value of the response.
From Marcelle Caturia:
Flexibility was key in matching volunteer roles with particular tasks. For example, initially we had two volunteers filling the role of “Task Coordinator”, which required both: 1) entering data from field reports, and 2) assigning tasks to remote mappers. Soon it became clear that dividing tasks 1 and 2 between the two volunteers would streamline the tasks immensely.
Posted by greggswanson 
Posted by greggswanson 
Posted by greggswanson 
