Review of Emergency Management Information Standards
The following is a non-exhaustive list of EM languages used for system-2-system interoperability.
Common Alerting Protocol (CAP)
|Summary||CAP allows a consistent warning message format to be disseminated simultaneously over many different warning delivery systems for exchanging all-hazard emergency alerts and public warnings.|
|Type/Scope||Warning Language, All-hazards|
|Responsible||OASIS Emergency Management Technical Committee|
|Specification||CAP 1.1 Standard|
To learn about the Community-based Last-Mile Hazard Warning System (LM-HWS) research findings and all other knowledge pertaining to this implementation that uses CAP as a standard for communicating hazard information to local communities, please search using the key words: Disaster, CAP, Last-Mile, HazInfo, Hazards, Community-based Warning, and Emergency Communication, in the search field of the LIRNEasia website. As part of the standard operational procedures a set of guidelines including a CAP Profile for Sri Lanka was established to test interoperability issues in the LM-HWS.
Two HazInfo project solutions that used CAP v1.1 as a standard for issuing alerts to the last-mile --
1) Disaster and Emergency Warning Network (DEWN), a GSM based solution is described in Challenges of Optimizing CAP for SMS based GSM Devices in LM-HWS in Sri Lanka provides complete details of the implementation, engineering, and the shortcoming as well as recommendations for using CAP as a standard.
2) Addressable Radios for Emergency Alerts (AREA) is a satellite technology, discussed in LM-HWS in Sri Lanka: Performance of the WorldSpace AREA, which is capable of communicating all the elements of a CAP message.Challenges of using CAP; especially the use of multiple
blocks to carry the multilingual messages and use of <urgency>, <severity>, and <certainty> tags to determine the priority of a message is describe in this paper. HazInfo research results show the need for a CAP broker to integrate the emergency communication entities and most importantly to reduce the messaging latencies.
For additional information or discussions you may contact the HazInfo Researcher/Project-Manager: Nuwan Waidyanatha.
CAP Canadian Profile (CAPCP) began as a proposal submitted by the Province of New Brunswick Emergency Measures Organization, working in collaboration with Doug Allport of the Allport Group. The Public Alert Message Protocol Requirements stresses -- The CAP Canadian Profile (CAPCP) limits the use of multiple
blocks to language translations of the original
block, and makes <language>, <geocode>, and <eventCode> required elements. These additional requirements ensure: 1. Sufficient content to translate key alert elements into at least both official Canadian languages; 2. There is at least a geopolitical reference in each alert which can be identified on most maps, 3. Alerts may be validated to recognized rights of alert originators, which is required to satisfy the demands of some private alert distributors. Ex. Only a few</div></span></div></span>
police officers in each Province have the authority to issue an Amber Alert. | |}
Review of e-Commerce Interchange Standards
The following are a list of standards and frameworks that may be relevant to emergency management as they are being used for business-as-usual within organisations or government. A number of these are being promoted and adopted by government agencies as a consistent data model for inter-agency data interoperability.
Customer Information Quality (CIQ)
GeoRSS describes a number of ways to encode location in RSS and Atom feeds. As RSS and Atom become more prevalent as a way to publish and share information, it becomes increasingly important that location is described in an interoperable manner so that applications can request, aggregate, share and map geographically tagged feeds.
Geography Markup Language (GML)
The Geography Markup Language (GML) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. Note that the concept of feature in GML is a very general one and includes not only conventional "vector" or discrete objects, but also coverages (see also GMLJP2) and in limited cases for sensor data. GML is content model neutral and communications protocol agnostic.
Web Feature Service (WFS)
The Web Feature Service Interface Standard (WFS) provides an interface allowing requests for geographical features across the web using platform-independent calls. One can think of geographical features as the "source code" behind a map, whereas the WMS interface or online mapping portals like Google Maps return only an image, which end-users cannot edit or spatially analyze. The XML-based GML furnishes the default payload-encoding for transporting the geographic features, but other formats like shapefiles can also serve for transport. In early 2006, the OGC members approved the OpenGIS GML Simple Features Profile . This profile is designed to both increase interoperability between WFS servers and to improve the ease of implementation of the WFS standard.
Web Mapping Service (WMS)
The Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information. This international standard defines a "map" to be a portrayal of geographic information as a digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM) formats. This is in contrast to a Web Feature Service (WFS), which returns actual vector data, and a Web Coverage Service (WCS), which returns actual raster data.
Sensor Observation Service (SOS)
A Sensor Observation Service (SOS) provides an API for managing deployed sensors and retrieving sensor data and specifically “observation” data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today.
SensorML is a standard markup language (using XML schema) for providing descriptions of sensor systems. By design it supports a wide range of sensors, including both dynamic and stationary platforms and both in-situ and remote sensors. SensorML provides standard models and an XML encoding for describing any process, including the process of measurement by sensors and instructions for deriving higher-level information from observations. Processes described in SensorML are discoverable and executable. All processes define their inputs, outputs, parameters, and method, as well as provide relevant metadata. SensorML models detectors and sensors as processes that convert real phenomena to data.
Sensor Planning Service (SPS)
The Sensor Planning Service (SPS) defines an interface to task any form of sensor or model. Using SPS, sensors can be reprogrammed or calibrated, sensor missions can be started or changed, simulation models executed and controlled. The feasibility of a tasking request can be checked and alternatives may be provided. SPS implementations cover a wide range of application scenarios. SPS is currently used to control assets such as simple web cams as well as satellite missions.
ISO 8601:2004 Representation of dates and times
ISO 8601:2004 is applicable whenever representation of dates in the Gregorian calendar, times in the 24-hour timekeeping system, time intervals and recurring time intervals or of the formats of these representations are included in information interchanges.
The National Information Exchange Model (NIEM),
NIEM: A Framework for Nationwide Information Exchange The National Information Exchange Model (NIEM), a partnership of the U.S. Department of Justice and the U.S. Department of Homeland Security, is designed to develop, disseminate, and support enterprise-wide information exchange standards and processes that can enable jurisdictions to effectively share critical information in emergency situations. NIEM also supports the day-to-day operations of agencies throughout the nation.
NEIM is a set of standards surrounding information exchanges among and between governmental entities that allows disparate systems to share, exchange, accept, and translate information.