Example Practices: CAP Elements Version 1.0
Committee Note 01
12 August 2013
Thomas Ferrentino (email@example.com), Individual
Anthony Mancuso (Google Inc.),
This document provides example practices for public dissemination of CAP alerts via web feeds.
This document was last revised or approved by the OASIS Emergency Management Adoption TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.
Technical Committee members should send comments on this document to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “” button on the Technical Committee’s web page at
When referencing this document the following citation format should be used:
Example Practices: CAP Elements Version 1.0. 12 August 2013. OASIS Committee Note 01..
Copyright © OASIS Open 2013. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This note provides example practices related to certain elements contained in CAP alerts. The need for this note came from Comment 6, Comments & Questions, Emergency Alerting Policy Workshop, made at the Emergency Alerting Policy Workshop, Montreal, Canada, 1-3 May, 2012. The comment expressed a “Need for international good/example practices used for alert generation.”
This note covers:
· CAP Element Usage
· Alerting Challenges that Impact CAP Alerts
[CAP-1.2] Common Alerting Protocol Version 1.2. 01 July 2010. OASIS Standard. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
[Environment Canada] Environment Canada is an agency that has adopted the CAP Canadian Profile, and which has also established its own CAP practices.
[Canadian Community] Canadian Community practices are used by NAADS (National Alert Aggregation & Dissemination System), and by many Canadian federal, provincial, and private agencies that have adopted the CAP Canadian Profile.
The Common Alerting Protocol provides flexibility in how most of the CAP data elements are completed. As a result, various implementations of CAP alert messages can look quite different. This section summarizes some example implementation practices pertaining to the use of certain CAP elements. (Note that an instance of a CAP message may be serialized in either XML or ASN.1 form; these principles apply equally in either case as well as in the case of internal data structures representing CAP messages within software applications.)
· Watch for false precision of coordinates in geometric shapes. Regardless of the alert area shape, the precision of any one coordinate value (number of decimal places) should reflect its true accuracy (distance accurate to meters, kilometers, etc.). For CAP alert areas, the precision, generally, should not be greater than one meter and, therefore, coordinates should have no more than five decimal places.
· If possible, simplify overly-complex polygons. Having too many coordinates in a polygon may interfere with the efficient processing of a CAP alert, and can result in an alert being dropped. This can happen when an alert area is defined by a reference source that gives an official boundary with hundreds of sides (for example, a polygon is automatically derived from mapping data for an irregular boundary such as a shoreline). To avoid an unreasonable number of points for a polygon alert area, it may be necessary to use a simplify function on the polygon. In most cases a polygon of less than 20 vertices can provide acceptable precision.
· Close polygons. For any polygon in CAP, the first point must be identical to the last point. This is a requirement of the CAP specification even though some mapping tools may not enforce this rule.
· A zero-radius circle implies a geometric point. In general, the radius should be comparable in scale to the precision implied by the circle's center coordinates. For instance, given a center point latitude with three decimal places (about 100 meters), the radius ought to be .1 kilometer rather than zero.
Note that zero-radius circles may reflect an intentional policy decision. For example, a zero-radius circle may be the only option for earthquakes, which usually are defined by a point and, since they occur quickly, may not have a warning area. Similarly, a zero-radius circle may be appropriate at the beginning phase of an emergency when the actual affected area may not be yet be determined but the location is at least known.
When the alerting area is the whole Earth
(e.g., certain space weather hazards), a "bounding box" polygon
(SW SE NE NW SW) should be used in the CAP area element:
<polygon>-90,-180 -90,180 90,180 90,-180, -90,-180</polygon>
· Example: NOAA (National Oceanic and Atmospheric Administration)
§ UGC geocodes and shapes are defined and updated on the NOAA website http://www.nws.noaa.gov/geodata/
§ Area descriptions vary from being a list of towns, to a name of a region, to a short phrase that describes an area (e.g., “Central Beaufort Sea Coast,” “Sierra Nevada from Yosemite to Kings Canyon,” “Columbia; Hempstead; Howard; Lafayette; Little River; Miller; Nevada; Sevier”).
· Example: Canadian Community
§ Polygons for the threat area are simplified (reduced number of vertices) and have exaggerated boundaries that extend beyond complicated boundaries
· The <description> and <instruction> elements allow for free-form text. The text should be relevant and useful for the audience in the alert area. Instruction text should be actionable and should focus on appropriate protective action to be taken by the public or the specified target audience of the alert. To enhance understanding and simplify processing by recipients, text in CAP alerts should use common phrases, drawn from a published source, if possible. Note for U.S. originators. Hazard-alerting guidance is available from the World Meteorological Organization/Public Weather Services.
· Example: NOAA (National Oceanic and Atmospheric Administration) descriptions are consistently high quality, and usually include information on the current weather event, predictions about the event, and its impact. Excellent alert creation guidance provided in WFO SEVERE WEATHER PRODUCTS SPECIFICATION.
· Example: Environment Canada practices provide alert information in multiple languages (English and French) to serve both official languages of Canada
· Separate alert <info> block for each language.
· Content is professionally translated.
· Different landing pages in <web> for each language.
· For maximum interoperability, a CAP alert message that is serialized as XML should be UTF-8 encoded. The source code of any programs that modify such XML files must be UTF-8 encoded as well. Care should be taken when inserting text by “cutting and pasting” from web pages or word-processors, as such insertions often include hidden and/or non-UTF-8 characters. CAP editing software that permits keyboard entry should, whenever possible, check for such characters.
· Distinct notion of an event (e.g., severe thunderstorm, freezing rain) versus an alert (e.g., severe thunderstorm advisory, freezing rain warning)
· Publicly accessible and regularly updated documentation of CAP element usage and maintenance is sometimes necessary.
· Example: Good Canadian CAP profile (CAP-CP) documentation available at http://capan.ca/index.php/en/cap-cp/.
Aggregators of CAP messages intended for public distribution (i.e., where the <scope> value is “Public”) cannot be relied on to evaluate the <restriction> element.
In a message validated against the CAP 1.2 schema the restriction element should only occur in a CAP message that also has a <scope> of “Restricted”. In prior CAP schemas, the <restriction> element can occur with any of the enumerated values of <scope> (“Public”, “Private” or “Restricted”), but only a "Restricted"<scope> is defined for such messages.
Hazards such as meteorological and geological events often cross city, town, province, state, and national boundaries. Poor coordination among alerting agencies can result in each agency issuing its own alert. Multiple alerts are generally acceptable to avoid gaps and provide corroboration. However, inconsistent alerts can cause confusion, and a large number of duplicative alerts can clog delivery channels and desensitize recipients.
· Agencies and alert issuing bodies in the same region should, where possible, leverage existing inter-jurisdictional processes and agreements to coordinate their warning efforts. If such existing frameworks are not considered adequate, the establishment of policies, procedures or regional warning centers should be considered.
· The CAP <area> element should be used to describe the area at risk from the subject threat or event. The area should not be constrained (“clipped”) to political or administrative boundaries unless the originator is certain that people in adjoining jurisdictions are receiving comparable alert information from other sources.
· If there are overlapping or duplicate alerts issued by different authorities, one way to help identify the duplication is through the use of a common identifier, such as the <incidents> sub-element, in the alerts.
Alert updating can be complex. The content of an alert needs to be updated to reflect changing and moving conditions, and the CAP element need to be structurally valid. The following process and technical tips can help improve the quality and accuracy of alert updates.
· Regularly update alerts. Alert creators/maintainers should establish protocols for obtaining current alert information for use in timely alert updates. At a minimum alerts should be updated before the previous version expires, unless it is the intention to allow the alert to expire.
· Issue CAP updates instead of new alerts to reflect changing circumstances or protection action recommendations. This helps ensure that CAP feed clients do not miss changes.
· Use <references> to point to earlier alerts. The alerting system needs to record the IDs of all previous alerts referring to the same event that haven't expired.
· Example: Environment Canada practices model the subject event for each alert as it moves across areas
· Expired area contains <responseType>AllClear</responseType>.
· Alert update contains a still active area and an expired area.
· Separate <info> blocks for each area.
· Still active area contains updated <effective> and <expires> time.
The <alert><info><expires> time is optional, and is defined in the CAP specification as "The expiry time of the information of the alert message." Determining the <expires> time of an alert information block during alert issuance can be challenging, yet having an <expires> time is extremely helpful for CAP feed clients and other downstream alert recipients. Unless an explicit <expires> time is specified, it will be up to the various disseminators, feeds and delivery systems to determine how long the alert information will remain visible to the public.
· One possibility is to set alert information expiration to a time slightly after the next expected update of the alert information. This helps avoids gaps for clients that poll more slowly.
o For example, if an agency issues measures flood gauges and issues updates every 30 minutes, the <expires> time can be 45 minutes or more after the <sent> time.
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Doug Allport Canada Multi-Agency
Situational Awareness Systems-
National Information Exchanges (MASAS-x)
Art Botterell Individual
Rex Brooks Network Centric
Elliot Christian Individual
Phil Coakley Google
Steve Hakusa Google
Gary Ham Individual
Elysa Jones Individual
Camille Osterloh Individual
Norm Paulsen Environment Canada
Greg Trott CAP-AU Custodian
for the Australian Government standard
for Common Alerting Protocol
Jacob Westfall Individual
1.0 wd 01
Initial Draft (copied CAP element content from prior CAP
feed and element doc developed by EMA-Collateral and Docs SC).
1.0 wd 02 - 11
Updated draft with additional content. Incorporated content and responded to comments from Art Botterell and Elliot Christian, Norm Paulsen.
Edited and added Jacob Westfall comments and responses for post-public review EMA-TC discussion.
OASIS EMA C&D SC
Resolved remaining comments received from Jacob Westfall