EPAD: Interoperability for Emergency Response Powered By Interoperable Geospatial Technology
Borderless Information Sharing for Emergency Response
COMCARE follows its own advice. Not only does it promote the importance of interoperability and the standards that enable it, but it uses those same standards in its own offerings.
COMCARE is a national advocacy group representing more than 100 member organizations involved in emergency response. COMCARE's goal is to advance emergency communications to create an environment of borderless, geographically targeted information sharing. COMCARE recognizes that despite the best of intentions, emergency information does not always get to the right respondents at the right time. For example, during an anthrax threat in the U.S. capitol area, one agency only heard of the issues after responding to a similar effort. Many first responders in Toronto first heard about the SARS situation via newscasts. With more than 100,000 independent emergency response agencies in the U.S., the challenge of communicating effectively and in a timely manner is paramount.
COMCARE's E-Safety Network provides a framework for a Web services architecture to knit together all of the key players' different data and communications systems. Building interoperability into that framework allows the participating public and private emergency response players "to select and use systems that best meet their needs," according to COMCARE. Standards from areas including authentication and authorization, security and diagnostics, and directory services underlie COMCARE's recommended solutions.
One specific service offering that's part of the architecture is called the Emergency Provider Access Directory or EPAD. Intended to be used as a common, shared utility, it enables cooperative and geographically targeted emergency information sharing. The idea is simple: create a directory to allow emergency response organizations (not individuals, Figure 1) to "sign up" to receive alerts for situations to which they can bring expertise, while not disturbing them with unwanted or irrelevant information. Passing on just the sort of situations that a single organization can support saves time and avoids wasted efforts.
Different service providers are equipped to handle different types of situations, so the type of emergency of interest is one of the sets of check boxes members choose when they register. Some providers are only on call during certain times of day or certain times of the year. That's another set of check boxes. Geographic location is a third criterion for filtering alerts.
Figure 1: Some of the types of organizations EPAD connects to emergencies.
EPAD is built on a services oriented architecture using components and Web service interfaces. One component is the GIS module. It's there that registrants identify for which areas, times and types of events they want to receive alerts. An organization might, for example, want to respond to fire events on the north side of the county, but flooding events in the south. Those registering graphically identify the boundaries of their areas of interest. When an event occurs, it's the GIS module that compares the location of an event to those defined areas and other attributes to determine which registrants receive the alert. To do that, all of the information, including the geographic information, must be understood by the different participating systems, including those of the organization posting the alert and those receiving it.
The EPAD team chose to use the Open Geospatial Consortium's Well Known Text standard (part of the OpenGIS Simple Features Specification) for the representation of geographic primitives (points, lines, and polygons). The system also uses Simple Features SQL to query against the directory. The decision to use those standards meant that the developers of EPAD could select from a number of products on the market that support these standards. For some of the technology, the team went outside the commercial market to one of the existing open source software offerings which support the standards.
Figure 2: The pieces of EPAD's communications system.
Figure 3: Detail of a spatial query.
Open source MapServer does the map rendering and provides map images to the EPAD administration interface via the Web Map Service Specification (WMS). While not in the current design, the team is also exploring open source GeoServer, which supports Web Feature Service Specification (WFS). Other open source technologies in the mix include Linux, Apache, Tomcat, JBoss, and Open LDAP. MoxiMedia (an OGC Member) provides proprietary code for the GIS client application. The MoxiMedia Internet Mapping Framework (IMF) is a proprietary application that provides a rapid application development environment for the Web.
The workflow runs like this. A first responder organization sends a (SOAP) message containing a location in Well Known Text to EPAD. EPAD parses the message and generates a Simple Feature SQL query to send to the database. EPAD adds a buffer to the query to handle horizontal error in the TIGER boundary data as well as locational error (so far as it can be determined) in the incoming message. The query is then run against all data layers (all the different geographic and attribute combinations input by registrants, stored in Well Known Binary format, Figure 2) simultaneously, and returns matching agencies. The list is passed to the messaging system which sends out alerts to the appropriate agencies. (Figure 3)
Judith Woodhall, Managing Director of COMCARE, explains the importance of standards in the EPAD project. "OpenGIS Specifications enable us to easily share geographic data among different technologies. This is especially important for EPAD because routing queries based on geography will come from a wide array of software systems. In addition, OpenGIS Specifications have given us both platform and database independence, thus allowing for vendor neutrality, one of our core requirements. While the next version is just being developed, we already experience these benefits in the many demonstrations we conduct using our EPAD prototype. As we grow and deploy EPAD into production, we're hoping that the OpenGIS specifications will also enable us to scale at a much lower cost. This again is important because we plan to run EPAD as a non-profit, shared utility for all emergency responders to use."
How Open Standards Make a Difference
COMCARE understands that location matters when it comes to emergency response. It also understands that breaking down barriers to information sharing demands the use of standards. Those who register their organization in the EPAD directory probably do not realize all of the underlying standards that enable the system to work. And, they don't need to know about them.
But those developing and maintaining the system do. They know that standards that describe how spatial information is documented (Simple Features) and how map data is shared (Web Map Service) allow COMCARE's vision to be achieved. Further, these standards, and others, allow each organization to select the software solution appropriate for its work and be confident the system can "plug into" this crucial network of first responders.
Acknowledgements
Graphics courtesy COMCARE. From a presentation by Ben Lewis, Senior GIS Analyst, Advanced Technology Solutions, Inc. and Judith Woodhall, Managing Director, COMCARE, at the Location Technology and Business Intelligence Conference, May 3, 2005, Philadelphia, PA.
Recent comments
3 years 2 weeks ago
3 years 19 weeks ago