Public alerting has proven to be one of the most complex undertakings by societies. There are countless technical, social and business considerations that have and will continue to change with society.
This CAPAN webpage is dedicated to issues of a technical nature.
Table of contents:
A key element to resolving most public alerting technical issues is the adoption of a common electronic messaging format. This is the role of the Common Alerting Protocol (CAP), which is an international standard of the Organization for the Advancement of Structured Information Standards (OASIS).
In March 2005, at an Industry Canada hosted public alerting workshop, CAP was adopted for use in Canada.
It is important to note that CAP was developed for use throughout the world, mindful of the need for localized implementations. The Canadian Profile of CAP (CAP-CP) is one such localized implementation, and similar to CAP, the CAP-CP was developed for use throughout Canada, mindful of the need for further localization to meet specific requirements associated with a system or sub-group of alerting stakeholders.
The Canadian Profile is technically compliant with the Common Alerting Protocol (CAP), in that valid CAP-CP is also valid CAP. Localized Canadian implementations of CAP-CP are expected to be valid CAP-CP.
A primary benefit of CAP-CP is that it supports automated translation and distribution of alerts in many languages and formats. For more information on how this is done, please see Automated Message Composition on this page, and Common Look and Feel on our Social webpage.
The official CAP-CP documents can be found on the CAP-CP webpage.
Click here to validate CAP-CP files using a CAP-CP Validation Tool.
CAP-CP is being supported with a comprehensive informative reference for developers, the development of which was supported by the Centre for Security Science, Environment Canada, Healix Computing and CAPAN. This resource leverages use cases and CAP-CP examples to support developers in their development of CAP-CP complaint applications.
CAP-CP system developers are encouraged to review this guide in advance of implementing CAP-CP.
The Environment Canada CAP-CP weather feed has been identified as the national “reference implementation” by the CAP-CP Working Group. When in doubt, it can be referenced for best practices.
The reasons for choosing the Environment Canada CAP-CP weather feed include a regular stream of new alerts for stakeholder review. Further, weather messages are frequently updated for changes in location, urgency, severity and certainty, presenting numerous use cases for developer’s reference.
CAP was developed to support the identification of the area the alert pertains to.
We can expect to see a number of changes and additions in the next version of CAP related to location. As an example, CAP currently defines the alert area as the combination of polygons, circles and boundaries associated with geocodes. As proposed for CAP-CP Beta 0.4, we might expect CAP to recognize the alert area defined by the polygon and or circle to be the more accurate representation of the area. In this way, systems that support very accurate targeting using polygons and or circles can be used to more accurately deliver alert messages.
We can also expect the addition of data elements specific to an events location. Event location offers situational awareness value and context for alerts. It also provides a more accurate location for the placement of a symbol on a map that is associated with an alert. The CAPAN CAP Event Location Layer was defined as an interim solution for including event location references in CAP messages, and has demonstrated that seeing a CAP-CP alert on a map is a very compelling reason to adopt CAP.
Additionally, CAP-CP Location References will undergo some changes. Currently, the CAP-CP Location Reference document simply refers to Statistic Canada’s Standard Geographical Classification (SGC) location references, which are updated annually (Click here for the 2010 update to the 2006 Census). In due course, a CAP-CP Location Reference table of values will be created and maintained in partnership with the provinces and territories. When this happens, we can expect to see some of the SGC values dropped from the CAP-CP Location References. Ex. Unorganized areas, Census Divisions (CD) where not recognized by a province.
In due course, Canadian marine location references and boundary files will be added to a CAP-CP Location Reference list. They will be based on the work of Environment Canada, who has developed a list of geocodes and boundary files that are recognized by other maritime stakeholders. The Marine Location References published by CAPAN will give way to this new authoritative collection.
Early implementers of CAP-CP identified issues with the boundary files associated with Statistics Canada - Standard Geographical Classification (SGC) location references. Essentially, they are more accurate than necessary for alerting, and over tax GIS computing applications. A Generalized SGC Boundary File has been developed with Statistics Canada for use with CAP-CP. Click here to access the files: Province, Census Division, Census Sub-Division. File users are encouraged to identify any issues with the files to CAPAN, using the comments form link that follows below.
It is also important to note that the mandatory use of CAP-CP location references does not preclude the use of other location codes. As an example, Environment Canada includes location codes specific to their systems in their CAP-CP alerts, as well as CAP-CP location references. In another example, a city might include a location code for a city grid, or perhaps a postal code reference. CAP accommodates these additions.
CAP is a structured messaging protocol. That is, each data element of the alert can be easily identified, and therefore play a role in automated processing. Ex. Only show me the most severe flood alerts for this town.
For each of the many data elements of CAP and CAP-CP, there is a defined list of values, and in some cases, a documented statement to go with the value. Ex. CAP severity value “Moderate” = “Possible threat to life or property.”
Leveraging translation tables and message algorithms for different formats, short and long messages in any language and any format can be composed. Ex. A “flood” (CAP-CP value) alert has been issued by “provincial emergency management” (CAP sender) for “smalltown” (CAP-CP location name). There is a “significant threat to life or property” (CAP severity statement). “Responsive action should be taken immediately.” (CAP urgency statement).
It is important to note that the automated translation and or message composition can happen anywhere in the alert distribution channel. That is, CAP-CP messages can be translated and formatted by the issuer, the aggregator, the last mile distribution application, a hand held device, etc.
As noted above, CAP-CP messages are rich with metadata. That is, they include many fields which can be used in electronic decision making, such as issuer rights management. As an example, a specific issuer (CAP <sender>) might be limited to issuing alerts for a specific event type (CAP-CP <eventCode> value), for a specific geopolitical location (CAP-CP <geocode>), with nominal severity (CAP <severity>) and but one type of response (CAP <responseType>), during their working hours (CAP <effective>). Such preventative measures can reduce the likelihood of an alert issuing error.
In June 2010, and as a result of a GeoConnections funded project, a national Emergency Management Symbology set was published that CAPAN then associated with CAP-CP event references.
The CAPAN CAP-CP Symbology Reference Table/Service includes CAP-CP event codes, the associated symbol, and a Uniform Resource Identifier (URI). The URI’s have been used by some system developers within their applications, and for inclusion in GeoRSS feeds and Keyhole Mark-up Language (KML) files for other systems to reference. Please note that developers should not build dependencies on this experimental symbology service as it is not maintained to production requirements. A more robust service is to be built for the national Multi-Agency Situational Awareness Systems (MASAS) initiative.
A common practice of packaging CAP-CP in an Atom wrapper is emerging. CAPAN strongly supports the application program interface (API) practices defined for the national Multi-Agency Situational Awareness Systems (MASAS) initiative presented on the Intellectual Resources Canada MASAS website.
In due course, it is our understanding that the MASAS API will align with the Emergency Data Exchange Language - Distribution Element (EDXL-DE) efforts of OASIS. The next version of EDXL-DE is expected to support the practice of using the Distribution Element as a “label” rather than an “envelope”. Once EDXL-DE Version 2.0 is published, you can expect to its use as a label in the MASAS API.
The term “layer” is being used with CAP in Canada to refer to specifications associated with CAP and or CAP-CP that are specific to a system or subset of stakeholders. Essentially, they are a localized CAP profile that is not managed by the CAP-CP Working Group.
A layer is often supported with the use of one or more <parameter> elements within a CAP or CAP-CP file. As an example, the CAPAN CAP Event Location Layer specifies how to include event location data in a CAP or CAP-CP message using the <parameter> element.
In another example, Environment Canada has defined a layer that includes additional location codes specific to some of their systems. The layer defines the list of codes and the <valueList> value to be used with them, in a CAP message.
CAPAN is building a set of resource tables associated with alerting, many of which relate to CAP-CP. The resources include web links to sources from around the world.
The alerting resources are being categorized as follows:
Comments and suggestions are welcomed, with the understanding that you offer them freely, without any conditions, including any requirement for attribution. Click here to send your comments and suggestions to CAPAN.