1 Introduction

Collaborative technologies are indispensable tools to share information and knowledge in real time, but many standard collaboration tools are inadequate for managing complicated and dynamic events such as emergencies and natural disasters.

Standard teleconferencing systems typified by WebEx (Cisco 2012), Skype™ videoconferencing software, and the Access Grid (Childers et al. 2000) provide a gamut of information-sharing media that include, but not limited to: voice and text chat, real-time video, and “shared” slides, applications, and desktops. However, information sharing using slides and desktops are usually not collaborative; merely presentational, facilitating the dissemination of information, but not interaction or the gathering of knowledge. While well suited to business, organizational, and some educational tasks, this “presentation with discussion” mode is only one way of to enable collaborations.

We present a flexible, collaborative tool for geospatial data called “Big Board” that is based on the gather and share paradigm. In a gather-and-share environment, no particular person is the leader of the conference; rather each individual contributes directly to the content of the conference. Gather and share systems are common in non-real-time software such as Wikis.

The Big Board has been developed to support shared situational awareness primarily on emergency response phase and partially on planning phase; though, the underlying concept of the Big Board allows it to be adapted to handle a wide range of geo-referenced information.

The Big Board facilitates real-time gather and share style collaboration over maps. Big Board is built using open source technologies and runs in all modern browsers and standard handheld devices such as smart phones and tablets. Our system supports a number of standard features such as shared and synchronized views of information; annotation and drawing over maps; integration and display of data obtained from mobile devices and sensors; and a built-in chat client for real-time communication. Many of the design considerations and data visualizations in the Big Board are motivated based on evaluation of information requirements and exchange during a simulated adverse weather scenario and based on feedback from actual end users (such as, school representatives and emergency managers).

In addition to the standard tools for collaboration in Big Board, our system makes following key contributions to the field of geospatial collaboration:

  • Big Board allows extensive customization of shared information: Views of information and data layers can be customized according to roles of participants or based on requirements of specific types of emergencies (for example, adverse winter weather, tropical storm events, and fire weather scenarios). Each teleconference session is assimilated into an individual virtual, persistent “conference room.” Once created, the conference rooms can be duplicated or reused, thereby allowing the Big Board to be quickly adapted for different types of future emergency management operations or for post-event analysis scenarios such as evaluation of emergency responses and for training purposes.

  • Big Board allows integration of data from a variety of extraneous sources: Users can organize and overlay Open Geospatial Consortium (OGC) standard Web Mapping Service (WMS) feeds (OGC 2006). This feature permits a variety of historic and stream data to be overlayed onto maps as customized “layers” of information in addition to human-generated content. Some of the existing data feeds in the Big Board include storm surge models and real-time weather data derived from National Digital Forecast Database (NDFD) data feed from National Weather Service (NWS). In addition, data from mobiles/handheld devices and sensors can also be easily integrated into Big Board.

In this paper, we describe the architecture and functionality of Big Board and discuss a field evaluation that we conducted to understand design requirements for the Big Board for emergency managers in North Carolina. We begin with a review of basic concepts in emergency management and survey existing tools for geospatial collaboration for emergency planning and management. In Sections 3 and 4, we present architectural and implementation details of Big Board and describe tools and user operations available for collaboration. In Section 5, we describe a case study involving application of the Big Board to plan for adverse winter weather. Finally, we discuss limitations of our existing work and goals for future work in Section 6 and provide concluding remarks in Section 7.

2 Background and related work

2.1 Emergency management and response

Emergency management and response (EMR) is a discipline that deals with disruptive events that can cause damage to life and property (Drabek and Hoetmer 1991). A standard EMR framework called Comprehensive Emergency Management (CEM) (Drabek and Hoetmer 1991) is used to describe various tasks in EMR that are needed to manage disasters after they have occurred and to prepare for imminent threats. Figure 1 shows some of the key phases of the CEM framework, which include mitigation, preparedness, response, and recovery; these phases have tasks and roles that often overlap. Cova (1999) provide details of the phases and describe some of the tasks involved in each phase.

Figure 1
figure 1

An overview of important phases of a framework for emergency management and response; adapted from (Godschalk 1991). In our modified version of the diagram, four phases of emergency management and response are categorized as pre disaster activities (risk management) and post disaster activities (crisis management). These two categories are highlighted by the ovals in the diagram. Note that this is a general categorization and activities in the four phases can overlap.

Full size image

There are many challenges to effective management and response to emergencies. An important challenge is coordination of activities and information sharing among multiple different agencies such as first responders, relief teams, analysts and emergency managers, and security personnel (Thomas 2005; Haddow et al. 2010). In addition to management of responders, EMR requires close coordination among tasks and services, resource utilization and dependencies, information collection and analysis, and decisions (Chen et al. 2008). Other activities such as emergency planning involve a number of sub activities that require extensive geocollaboration (Schafer et al. 2007). To manage such distributed activities, and sometimes fast-evolving situations, emergency managers require collaborative tools that can augment their situational awareness and allow rapid sharing of vital information (Oosterom et al. 2005; Andrienko et al. 2007; Harrald and Jefferson 2007; Graves 2004). Furthermore, because geo-spatial context is implicit in many types of emergency situations and disasters, effective EMR requires sharing of geographic information, support for geospatial analytics, and collaborative decision making (Cai et al. 2005; Tomaszewski et al. 2007).

2.2 Overview of geocollaborative tools

MacEachren and Brewer (2004) first used the term geocollaboration to describe these collaborative technologies to facilitate geo-spatial information exchange, visual analytics, and knowledge management. In general, collaborative tools and techniques can be classified using a standard scheme that is based on locality of participants in space (co-located vs. remote or distributed) and time (synchronous or same time vs. asynchronous or different time) (Ellis et al. 1991; MacEachren and Brewer 2004). Figure 2 shows the classification scheme and some representative tools used for different scenarios. We note the scope of our Big Board system in relation to some general collaborative tools.

Figure 2
figure 2

An overview of tools that support collaborative activities. The tools are partitioned based on nature of communication. The figure also shows the scope of our Big Board approach. The image is adapted from (Ellis et al. 1991).

Full size image

Extensive research has focused on approaches and tools for effective geocollaboration. MacEachren and Brewer (2004) describe a framework for geocollaborative group work that addresses some important issues such as nature of collaboration tasks; decision making in a group setting; visual representations for geocollaboration; and properties and design of collaborative tools. The authors also discuss applications of their framework to case studies dealing with collaborative exploration and analysis of climate data. Convertino et al. (2005, 2011) discuss the important design and cognitive challenge of developing common ground in synchronous, distributed geocollaboration. They have developed a multiple-view coordinate display approach to support geocollaborative to disambiguate personal and public/team-level views of shared information. Heiser et al. (2004) demonstrated the effectiveness of shared views in a study that involved developing emergency routes collaboratively. Their results demonstrate importance of some characteristics of shared-view collaboration such as gestures and interactivity on efficiency of the collaborative work.

A number of solutions have been developed to enable remote geo-spatial collaborations. One standard approach is to exploit web-based client–server models to serve shared content and geo-spatial information such as GIS data and maps. Some examples are GeoBoost (Eick et al. 2007) and GeoSpaces (Baraghimian and Young 2001), which is part of a larger commercial tool for interactive collaboration (InfoWorkSpace™). Availability of open-source GIS platforms such as GeoTools (GeoTools 2012) and GeoNode (GeoNode 2012) have made the web-based GIS and map-based applications easy to build and access. Big Board shares architectural features with some of these web-based tools and we discuss our system in relation to these tools in Section 3.

2.3 Geocollaborative tools for EMR

An essential resource for emergency planning and management are gather and share systems in which collaborations are centered around shared geographic maps and the emphasis is on human-generated content (Schafer et al. 2007). These types of systems have been explored extensively in past. For example, (Resch et al. 2007) have developed a system they call eMapBoard that combines GIS components and an interface that allows sharing and annotation of information. Another map-centric tool is CIVIL (Wu et al. 2009), which integrates existing map services such as Google Maps and interactive tools to create, share, and analyze content. Gupta and Knoblock (2010) present an approach for crisis management based on geospatial mashup, in which they combine standard information visualization displays with standard mapping services such as Google Maps. The mashup supports integration of standard data formats such as spreadsheets and internet HTTP requests. A general collaborative planning tool has been developed by (Antunes et al. 2010), which provides a collaborative problem solving tool and interactive creation and sharing of human-generated content on maps.

Some of the existing tools provide support for real-time situational awareness for specific scenarios. For example, Starlight (PNNL 2012) is a general command-and-control virtual environment for analytics and decision-making process for security applications. GeoTime (Eccles et al. 2007) is another tool that allows multiple parties to share information about a complex scenario such as battlefield planning and execution.

A general map-centric approach is based on integrating standard Geographic Information System (GIS) tools and geo-spatial visualizations. Some examples include a system that integrates scanned images of terrains with standard user interface application (Brunner et al. 2009); a prototype geo-collaboration tool developed to support geo-analytics (MacEachren and Brewer 2004); and ESRI’s module for situational awareness (ESRI 2010) based on their standard GIS platform. Tomaszewski (2011) has developed an approach using Google Earth™ to display disaster incident data. Data in the system are obtained from real simple syndication (RSS) feeds and are visualized to support situational awareness for disaster management. Yet another tool is eStoryS (emergency storyboard system) proposed by (Malizia et al. 2011) that is centered around the concept of storyboarding. The eStoryS system integrates information such as text and pictures from a number of social media sites and other georeferenced information on the web to present a unified map-based system for emergency communication.

Other related work, notably by Schafer et al. on geocollaboration, has focused on specific needs for emergency planning and management. They have developed a geocollaboration software for synchronous geocollaboration, which is based on the BRIDGE (Basic Resources for Integrated Distributed Group Environments) and CORK (Content Object Replication Kit) Java-based platforms for distributed content management (Schafer et al. 2005). Their tool allows multiple users to create annotations and overlay different types of GIS information directly over shared views of maps. They conducted extensive field observations to identify collaboration needs and activities for emergency planning during local, community-oriented emergency events (Schafer et al. 2007). Schafer et al. (2007) have extended their geocollaboration tool to support emergency planning activities based on the findings of the field studies.

While the Big Board is similar to some of the exiting solutions for geocollaboration in scope and design goals, there are notable differences. For example, compared to (Schafer et al. 2007), Big Board uses quite different architecture and underlying software modules. In addition, Big Board uses iRODS (DICE-Group 2012) for data storage and curation, unlike GeoTools used in (Schafer et al. 2007). iRODS is a flexible data management system that enables implementation of varying levels of rules and policies for data access. Furthermore, Big Board proposes two approaches that can enhance effectiveness of geocollaborative tools. The approaches include the ability to customize role-based access to data and information and the ability to integrate extraneous data from a variety of sources such as Open Geospatial Consortium feeds and data from mobile/handheld devices and sensors.

We next describe details of the design and architecture of the Big Board.

3 Our approach

We have built Big Board, a web-based system that allows emergency managers in the field with laptops or mobile phones and in the operations center to gather and share data and direct their operations over the top of a shared, web-based map, analogous to a teleconference room.

3.1 Design of the Big Board

The Big Board is designed as a web application whose client will run on all popular modern browsers without plug ins or other modifications, and without change to most IT infrastructures. Additionally, the Big Board runs flawlessly on tablet devices such as the iPad or the Android-based Motorola Xoom. We achieve this using HTML5 (W3C 2011), JQuery (2012), and OpenLayers (2012) for user interface and client–server communication and graceful degradation of functionality in less-capable systems.

The server side of the Big Board uses RENCI’s open source Geoanalytics system (Heard 2011), Django (Foundation 2011) and MongoDB (through MongoEngine (Labs 2012)). Django is a rapid development framework similar to Rails (Hansson 2012), which includes an object-relational model, an engine to create templates, and other common facilities for developing server-side apps. MongoDB is a distributed document database built on the NoSQL paradigm, meant for fast insertion and lookup of semi-structured data. Geoanalytics is a system built on top of Django, MongoEngine, PostGIS (Research 2012), an iRODS (DICEGroup 2012) data grid, and RENCI’s high-performance computing resources to rapidly develop web-applications using OGC web standards based on rapidly changing requirements. This combination of systems provides both for serving up the user-interface of the system and for message passing and state storage for conference rooms.

The underlying software platforms in Big Board have been used previously to create geocollaboration applications. Most notable is GeoNode (GeoNode 2012), which relies on many of the above-mentioned software tools and modules to enable sharing of geospatial data. GeoNode, however, requires that users know something about geospatial data to use it properly. GeoNode users can upload shapefiles and similar open-source data formats but must be skilled enough to use these tools. The Big Board was designed to allow for online editing of annotations and annotation markup, relegating more data intensive overlays to a skilled administrator. This allows for a lower barrier of entry for emergency managers rather than only emergency managers who are also GIS experts to use the system.

3.2 Architecture of the Big Board

The general architecture of the Big Board system can be seen in Figure 3. Important components are marked in the figure and include: conceptual organization of users and conference rooms (A and B); internal models of the system (C); user interface and some ways to access the Big Board (D); and data and event flows in the system.

Figure 3
figure 3

Architecture of the Big Board. Some of the important components of the system are marked in the image: (a) Users can participate in one or more conference rooms; (b) Organization of teleconferencing sessions of the Big Board as conference rooms; (c) Important modules within a single conference room; and (d) Conceptual view from the outside of shared, synchronized information and maps in the Big Board.

Full size image

The browser sends UI events including the GPS location when available through the HTML5 Navigator Application Programming Interface (API) to the server through AJAX calls (see lower left of Figure 3). The server updates the models associated with the conference room. Every function in the Big Board Server can be accessed through a RESTful HTTP API call.

Data models in Big Board are defined through the MongoEngine model API. These store objects that are created as side effects of conference participation as JavaScript Object Notation (JSON) objects in the MongoDB document database. The models are exposed in a controlled way through the Django “views” and templating API. The browser containing the conference room continually asynchronously polls the server side for updates on chat items, conference participants, shared overlay states, hand-drawn features created by participants, and contextual feature information provided by participants for these hand-drawn features.

3.3 Data integration into Big Board

Existing geocollaborative tools obtain data from a number of standard web-based sources such as HTTP requests (Gupta and Knoblock 2010), RSS feeds (Tomaszewski 2011), and social media (Malizia et al. 2011). In the Big Board we have chosen to exploit a potentially huge number of web-based mapping services to layer content from. Just in the US, the US National Weather Service, Census Bureau, the U.S. Geological Survey (USGS), NASA, and many other national, state, and local governments provide web services capable of being layered onto the Big Board. Any OGC Web Mapping Service (WMS) can be layered into the Big Board. To make a layer available, a system administrator adds the layer as a resource in the back end, optionally renaming it, describing it. The administrator then attaches a number of roles to the resource, marking the resource as relevant to conferences or users including those roles.

3.4 Role-based support in Big Board

Role-based customization of information is a useful approach to facilitate collaboration in teams with multiple different experts (Convertino et al. 2007, 2008; Wu et al. 2009). For example, (Convertino et al. 2007) generate multiple views of information that are customized according to roles of individual participants; for example, one view is specific to a participant’s expertise while another is a shared, team view of the information. Their approach allows users to share some or all information that is specific to their roles. They also describe approaches such as telepointers to manipulate and synchronize the two views.

In the Big Board we have implemented the concept of role-based customization slightly differently. Roles allow tailoring of responsibilities of participants, as well as, customization of content and process according to specific needs of different types of emergencies. Roles at the layer or conference room level can be used not only to restrict access of participants to appropriate layers, but to customize the presentation of those layers data to the expertise level of the participant. For example, one participant might view a temperature layer as a continuous gradient, because he or she is experienced with such maps and knows what to look for. Another user is interested not in temperature itself, but certain “decision thresholds”; the same information can be presented to this user as a banded map containing only which side of the threshold any point lies upon.

In the Big Board roles can be applied either to individual participants based on their expertise or to individual overlays derived from data feeds. In the latter case, roles determine the availability to users of layers kept in a master catalogue. For example, fire fighters might have available to them layers concerning brush cover, drought extent, and built land, while school superintendents (who make the decision to close schools for inclement weather) might have layers available concerning freezing precipitation forecasts and local climate office observations. They are assigned different roles in the system, and cataloged overlays can be declared relevant to one or more roles.

3.5 Mobile support

Handheld and other portable mobile devices can be valuable resources during emergencies to gather and coordinate information from multiple distributed agents and people deployed at an emergency site. There has been previous work to integrate mobile devices for EMR application. Examples of some of the existing applications include a peer-to-peer framework called WORKPAD (Mecella et al. 2006); an emergency notification system for evacuation and surveillance (Xu et al. 2008); and a framework to pool and coordinate data feeds from multiple sources (Natarajan and Ganz 2009). Other related work involves crowd-sourcing applications that exploit current capabilities of smart-phones and handheld devices. An interesting example is FixMyStreet (2011) in which residents can log issues pertaining to civil amenities in their local neighborhood. Another example is a platform called MoCoMapps developed by (Hupfer et al. 2012) that allows lay users to create and access map-based crowd-sourcing applications.

In the Big Board, mobile devices are supported through two avenues. For larger devices, such as the iPad and Motorola Xoom, the normal UI view of the Big Board is supported with minimal modification to allow for more intuitive user input, taking advantage of touch screen technology.

For smaller devices such as mobile phones, a user can interact through administrator-customizable mobile web forms using a toolkit such as JQuery Mobile (jQuery Project 2012). These forms send AJAX calls that create Drawing objects in a codified way. Furthermore, these forms can also be associated with roles or conference rooms to allow users to enter specific data very quickly. For example, a form might be made available that allows a mobile user to quickly note road conditions in terms of freezing precipitation, flooding, or obstruction. The Big Board can also respond to queries that find out which users are close to a location or if there are annotations (drawings) on the map near a location. An example iPhone UI form is shown in Figure 4. The figure also shows an example of how data obtained from mobile devices might be displayed in the Big Board.

Figure 4
figure 4

An example of using the Big Board with mobile devices. (Left) Forms running on the iPhone 4. (Right) The Big Board system showing data on road conditions. The data were obtained from our mobile crowd-sourcing application shown on left. A dot on the map indicates a location where road conditions were noted by a human observer. Colors of the dots indicate conditions such as clear, icy, snow, and rain, and mix of rain and snow.

Full size image

Data entered via mobile phones is associated with the participant that entered it. Entering data directly into the conference room is restricted to specific participants; thus trust in accuracy and quality is based upon participant’s familiarity with each other. Entered data is associated with the annotations layer and is considered part of the data associated with conference participation. Data could in principle be automatically modified, deleted, or otherwise processed on a per-participant basis by automated processes (agents) accessing the data stored in the MongoDB backend system.

The framework for mobile crowd sourcing application can also be adapted for inputting data from a network of sensors. In general, all that is needed is an instance of a WMS server like MapServer (Foundation, 2012a) or Geoserver (Foundation 2012b) running on top of a PostGIS (Research 2012) database. Then a data model is created for the sensor network using the same Django framework that we use to create the models for the Big Board. Sensors can then use HTTP POST calls to send data to the Big Board, which stores it in the model, and it is served up graphically as a WMS overlay through Geoserver or MapServer.

4 User interface and functionality in Big Board

The Big Board system associates one or more administrator-assigned roles to each logged in participant. This mapping between users and roles is shown in panels A, B, and C in Figure 3. When users log into the system, they first create a conference room and provide a name to it. Next, they assign a number of roles (including at least his or her own role), select a center focal point, and select a base map. Base maps can be any of the various Google layers, Open Streetmaps, or any custom Open Geospatial Consortium (OGC) WMS feed. Once the base map has been created, the user is logged in and the conference begins. The user interface of conference system itself consists of a map and a sidebar with tabs for overlays, drawing, and a chat client for discussion. Figure 5 shows some of the major components of the user interface of the Big Board system. The Big Board can easily be coupled with standard teleconferencing systems to provide audio and video capabilities during remote collaborations.

Figure 5
figure 5

The Big Board system in action. A control panel on left provides access to standard drawing tools and options to share information.

Full size image

Figure 6 shows an example of a raster map overlay that shows sky cover information (light to dark: sunny, partly cloudy, and mostly cloudy). The data for this overlay were obtained from NWS’s National Digital Forecast Database (NDFD) data feed.

Figure 6
figure 6

Sky cover overlay on the Big Board. The control panel shown on the left provides buttons to share/unshare individual overlays and options to change layer opacity and to select different time steps.

Full size image

When users log into a conference room the system detects their location via the HTML5 location API (available on all modern browsers), and displays their locations on a geographic map associated with the conference room. In addition to this main view of the conference room, users can post and retrieve specialized information over GPS enabled mobile phones using mobile-web forms which are made available by role and can be bookmarked as “apps” by users.

Users are presented with a number of buttons to control and display Open Geospatial Consortium WMS feeds over the map in Users are presented with a number of buttons to control and display Open Geospatial Consortium WMS feeds over the map in the main view. These feeds give the Big Board a unique ability to provide context for content creation, and to add to the ability of a user to generate situational awareness from complex data not available in the default map view, and created by users not participating directly in the conference. Unlike similar works such as CIVIL (Wu et al. 2009), customization of the Big Board’s functionality for creating, inspecting, and sharing content on the map is extensively influenced by the user and room’s assigned role(s). Which feeds each user has the option of overlaying are controlled by a system administrator, who ties feeds to roles, and assigns one or more roles to each user. In this way, the system can have hundreds or thousands of pre-programmed overlays without overwhelming the user—a firefighter can see a different set of job-role targeted overlays than a school superintendent, and so on.

Overlays in users’ views can be shared among users. Users have a choice of whether or not to view the overlay themselves, to augment their own view, or to share the overlay with the conference, showing everybody the same view. Our system allows each overlay to be defined for multiple dates and times, which can be selected in a calendar view by the user dynamically. Any conference member can add and share overlays. Other overlay controls include being able to select specific time steps and elevations for feeds where these parameters are relevant, and being able to control the opacity of an overlayed layer.

Our system provides some tools to draw on overlays and to query data added to the map. The drawing tools include options to measure distance and area, draw vector shapes such as points, lines, and polygons, deleting features, inspect feature information, and add on-map labels and detailed text content to the map. Additionally, role and situation-based icon sets can be configured by the administrator to allow a participant to mark the map up in a graphical way. For instance, one might have an icon for icy road conditions, for flooded out roads, and other hazards.

We provide support for simple analytics via WMSGetFeatureInfo, a protocol that is part of the OGC’s WMS standard. Any overlayed layer that supports WMSFeatureInfo can be queried and feature information is showed in the Feature Information panel. A user’s role in the system can also allow them access to controls for performing more detailed analytics relevant to the role. For example, a school superintendent has access to a control that brings up National Weather Service’s point-wise hourly weather graphs on point-and-click. Also, overlays may have pre-programmed analytics applied to them based on role, such as for the overlays used in our case study on winter weather.

Collaborative activities are supported by yet other user interface elements. For example, a discussion tab provides simple instant messaging functionality among logged in users. It contains a participant list, a discussion log, and an entry field for adding one’s own messages to the dialog. Participants are highlighted on the map when they enter a message, or when a user clicks on a participant’s name. Additionally, a button labelled “Center everyone here” takes the participants viewpoint and zoom level and centers every other participant in the room on the same viewpoint. This does not lock the other participants into the view, but it does immediately shift their focus temporarily towards something deemed important. However, we have observed that this feature can be disruptive if no one person is in command of a conference room. Convertino et al. (2011) have suggested a shared-awareness paradigm that is based on a two-view solution to deal with the challenge of managing private and group view of information in shared information spaces. Such a solution is not currently available in Big Board but can be implemented by exploiting our architecture’s capability to easily replicate conference rooms; Two views of a conference room that correspond to a personal view and shared, team view can be created by modifying permissions to manipulate data and views for each conference room. Finally, to augment asynchronous collaboration we maintain a log of all user actions and events in the conference room, so it is possible to take a closed conference room and “replay” the entire conference or query its content for specific items. We are currently working on a visual interface for this task.

5 Case studies

The Big Board has been in use in several counties in North Carolina as a tool for “situational awareness and understanding” building during an emergency. Situational awareness and understanding in this context refers to the ability of an emergency manager to, as fast as the situation evolves, incorporate data about ground conditions at an emergency site and synthesize knowledge and decisions that affect the emergency (Brunner et al. 2009; PTI/GITA 2009).

5.1 Analysis of winter weather scenario

Our first large scale deployment of the Big Board was for managing an extreme winter weather scenario. Our focus was to facilitate gathering and exchange of information that schools use to decide if and when to operate schools during inclement weather. A school’s decision to stay opened or closed can have repercussions on safety of transportation staff and teen drivers and on socio-economic costs involved in operating the school.

Figure 7 shows the general procedure followed by schools to decide whether to close the school or delay opening during an adverse winter weather event. Many personnel at schools who make the decision routinely use NWS or TV station products such as radar, text forecasts, and maybe a graphical summary hourly weather graph. A challenge with these existing products is that they may not be easy to interpret for a non-meteorologist and they do not always provide the information school representatives need to make their decision. Schools also currently collect their own real-time info on roads, but there are few tools that allow them to share the information with others in the county.

Figure 7
figure 7

A general procedure followed by school staff to respond to adverse winter weather conditions or an approaching storm. Often, the staff will ride roads to determine driving hazards.

Full size image

Winter weather scenario testing and results

We conducted a winter weather exercise with 13 representatives from the seven schools mentioned earlier. The representatives were in charge of making school-closing decisions in their respective schools and were all school superintendents or transportation department staff. The participants were led through an actual winter weather event scenario from 7pm February 28th, 2009 to March 2, 2009, which was simulated using the overlays on the BigBoard. The participants were shown the different overlays that were prepared before-hand and were asked to provide their feedback.

Training

The Big Board was introduced to school representatives for Wake, Orange, Forsyth, Catawba, Buncombe, Burke, and Caldwell counties in North Carolina. The school personnel were exposed to functionality and usage of the Big Board during presentations on the system; hands-on training on the Big Board was given to personnel from two counties (Wake and Buncombe) during initial testing of the Big Board.

The schools in our study were chosen on criteria such as their level of interaction with local NWS offices, their categorization as urban and rural counties, and their geographic distribution in North Carolina. Our goal in this case study was to use the Big Board to facilitate information exchange during a simulated storm event and to observe how participants incorporated the Big Board in their decision making process.

Simulation data and displays

We took archival weather forecast and observation data from a real-life extreme winter weather event from March 2, 2009, and loaded it into a conference room in the Big Board. We did not create a specialized role for this scenario because the participants (that is, school representative and transportation staff) were non-meteorologists and non-experts. We created custom data-derived overlays for the following weather-related parameters: dangerous windchills, freezing temperatures, sunniness, snowfall, liquid-equivalent precipitation (known as quantitative precipitation forecast (QPF)), and observed temperature and precipitation. These overlays contained time steps for every forecasted hour of the storm, and users could select any available time for display. Figure 8 shows two examples of overlays we used in this study.

Figure 8
figure 8

Overlays used in the Big Board for the case study: (left) windchill information and (right) sky cover data. Data used in the study were obtained from NWS’s National Digital Forecast Data (NDFD).

Full size image

To display information specific to winter weather, we added icons in the drawing tab for snow, ice, liquid precipitation, clear roads, and general hazards. We also created a web form for road conditions that could be used to add these icons to the map using mobile phones, or users could add them from the drawing tab of Big Board’s main display.

The overlays we created differ significantly from the forecast standard graphical forecasts generated by NWS. The NWS forecasts have to suffice for all conceivable situations, and are not tailored to what a particular user might be looking for. For example, an all-purpose national temperature map has to give data relevant to farmers concerned with freezing crops, aviators determining de-icing needs, departments of transportation, and others, so the NWS errs on the side of giving all the data at the expense of readability.

Evaluation procedure

We used a demonstration script to go over Big Board functionalities and specific tools. The script included a walkthrough of the user interface of Big Board and demonstration of user operations such as creating vector shapes (points, lines, and polygons) and annotations and creating different layers of information. We obtained feedback from 12 users from different focus groups. These focus groups represented 10 of the 15 standard roles and responsibilities specified by Federal Emergency Management Agency’s (FEMA) Emergency Support Functions (ESF) (FEMA, Accessed July 2011), including a county emergency manager, a school superintendent, a person from the local fire company, and transportation representatives. We guided the users in our focus groups through a hypothetical scenario from 5 days before an event to 2 days after an event. The input we got from these focus groups directed the kinds of functionality included in the Big Board.

Since we were aware of what our users are looking for by virtue of our focus groups, we were able to build overlays using criteria that made sense to people closing schools. Dangerous windchills were given in time-to-frostbite, using NWS standards on how to calculate this. Temperatures were categorized by “above freezing (36F+)”, “around freezing (28–36F)”, “frozen (10–28F)”, and “brine/road salt ineffective (<10F)” (below 10°, the amount of salt considered safe for the environment is not effective in keeping the roads from freezing). Snowfall, similarly, was colored based on values considered significant by these particular emergency managers: 0–0.125″, 0.125″–2″, and 2″ and above. Freezing liquid precipitation was banded by 0–0.125, 0.125–1, and more than 1 inch. Examples of some of our overlays are shown in Figure 8.

Feedback

We gathered feedback informally from the participants, but specifically asked about the functionality and tried to gauge the participants’ understanding of the functionality and overall feelings about its utility. Participants responded well to the overlay and annotation functionality and the ability to gather and share with other members of their community. They were less enthusiastic about the chat functionality, preferring to talk over the phone. They cited a specific need to be able to gather and share from mobile devices, which we incorporated into the tool.

We gathered feedback about the overlays using web-based surveys that were sent out to school representatives in three different counties and one emergency manager from another county. Participants evaluated three overlays, which were overnight lows, sun cover, and extreme wind chill. In each survey, participants were shown screen shots of different scenarios and were asked a number of questions for each visual. The questions pertained to usefulness of the overlay and interpretation of graphical encoding of the information displayed. We used results from these tests to refine the overlays for the winter weather exercise.

Most participants in our study thought that the Big Board would be a useful tool and a good way to view real-time weather information and share reports from those riding the roads with other departments (e.g., Department of Transportation (DOT)) in their county. Many participants liked that we could overlay data on their county and the ability to zoom out to see surrounding counties, which would give them situational awareness about the winter event.

The participants also gave useful feedback about other aspects of the Big Board. Some participants suggested extending the overlays to include other information such as hazardous road forecasts, school district zones and locations of schools, and information about areas with known problems. Another useful suggestion was to publish the information in the winter weather conference room so that parents and students could see specifically where problems in the county were and why school needed to be closed or delayed. One participant noted that the icons on specific conditions (for example, icy roads and precipitation type) were quite useful to get details about specific events. Some participants noted that the Big Board might not fit into their current practices because they themselves drive to collect information about roads and could not access a computer or share information safely.

5.2 User survey

We went back to several of these school districts: Wake, Forsyth, Alamance, and Orange, to conduct surveys of the participants to include as part of the study. The schools in this study were chosen from a subset of the schools in the winter weather scenario. Some of the questions required a quantitative response on a scale of 1–10 (10 being most favorable response) while other questions required a descriptive answer. These surveys queried the participants on: whether or not the Big Board will help them in their operations, how, limitations to implementing use of the software in the EM process, its potential use in scenarios other than winter weather, the utility of the “gather and share” paradigm, the utility of being able to add annotations and overlays, and of real-time chat. We obtained survey results from four school representatives. Of those surveyed, one provided only descriptive feedback; Even though the survey sample is limited, we obtained useful feedback regarding functionality of Big Board from potential users.

For each of the survey respondents, we read the script demonstrating the Big Board functionality using data from the historical winter weather scenario described in Section 5.1. Then the users were allowed to ask questions in a short question and answer session, and finally they were given the survey to complete. As mentioned before, only three of the four respondents provided complete response to the quantitative questions in our survey. Respondents gave the feature “gather all the information at one spot,” an average score of 8, with one respondent commenting that the feature would be useful in case of a fast moving storm or situation. Regarding intuitiveness of the layout two respondents gave a score of 7 while another gave a score of 10. Regarding usefulness of adding additional layers of information (e.g., precipitation, radar, temperature, and freezing point), all respondents gave a score of 10. Regarding usefulness of sharing views, respondents gave an average score of 9, with two participants commenting that some form of standardization might be needed to reduce or remove subjectivity from information extracted from the additional layers. Participants gave an average score of 8.6 to usefulness of drawing/annotating for communication and decision making. Finally, participants gave a relatively lower score, an average of 5.6, to the chat feature and ability to record dialog. One respondent commented that they did not completely understand the chat functionality in the given test scenario. Nevertheless, this prompts introspection about design and presentation of chat functionality. Some of the qualitative feedback we obtained was as follows. When asked “What is the primary way [the big board] will help,” users said things like “will help with monitoring weather hazards for bussing and communicate to drivers and schools potential changes in operations due to weather.” In reference to the how much the gather-and-share functionality will help, a user said “it will help most with urgent or fast moving storms / situations.” Overall, the results of these surveys suggest that the districts see great potential in the software. As a result of the interest expressed in our surveys we intend to roll out the Big Board as part of NC-First (NC-First 2012).

6 Discussion and future work

We will be testing the Big Board in depth in a tropical weather scenario with emergency managers from coastal and mountainous counties in North Carolina. In this scenario, we plan to include overlays including storm tracks, surge predictions, critical infrastructure, evacuation routes, and current relevant weather observations. These overlays will be developed using RENCI’s Geoanalytics system (Heard 2011) so they can be updated in real-time as situational conditions or user preferences change.

Additional features we plan to add include the ability to select available times for an overlay by mouse, freehand drawing, and to replace the text-only feature info with a Wiki, giving the ability to go in depth about a location and provide clickable hypertext links.

In addition, there are a number of limitations of the system we plan to address. Hypothetically, our system scales horizontally, that is it can support adding data (storage) and higher levels of access (CPUs); however we need scalability testing to verify this. Another limitation of the system is that if a user’s client goes off-line, that user sees his or her own changes, but the changes are not propagated to the server. We plan on addressing this with a client-side database such as Lawnchair (Leroux 2012) that can hold changes that haven’t yet been propagated until the user comes back online.

7 Conclusion

We have described an open-source tool we call the Big Board to facilitate distributed synchronous collaboration for emergency response management. The Big Board runs on all modern web browsers and uses open-source web standards. Our approach provides standard tools and operations that allow emergency managers to gather and share information in real time. In addition, the Big Board can integrate data generated by agencies such as National Weather Service, Census Bureau, USGS, and many other web services that generate geo-tagged information.

Based on a case study involving school closings during adverse weather, emergency managers found the Big Board a useful tool, which they plan to use in their operations. Their responses include that it will allow others in the community, such as Department of Transportation (DOT), State Highway Patrol, and even the NWS to see what data the schools are collecting and add data of their own. They said that this allows everyone who needs to know what the roads look like to gain situational understanding much more easily than what is going on now.