Two LIRNEasia projects feed to World Meteorological Organization on Common Alerting Protocol

Posted on December 11, 2008  /  4 Comments

The design of the Real-Time Biosurveillance Program pilot (termed as the m-Health project) and findings from the Last-Mile Hazard Information Dissemination pilot (termed as the HazInfo projects) involvoing the Common Alerting Protocol (CAP) were presented, yesterday, at the CAP Implementers Workshop organized by the World Meteorological Organization (WMO).

First Talk – The m-Health RTBP will be evaluating CAP or EDXL (Emergency Data Exchange Language) as means for disseminating health risk information to local health officials and community health care workers. Currently, the National Epidemiology Unit, in Sri Lanka, publishes a “Weekly Epidemiological Report” on the world wide web, a pdf file that can only be viewed on a personal computer. Paper copies of the same are delivered via postal mail to the relevant health officials. The latency in gathering the epidemiological data, analyzing, publishing, and disseminating is delayed as much as up to 3 weeks. The m-Health RTBP will adopt mobile phones with a manifold penetration over costly DSL or UMTS with bulky PCs for gathering field level health data and receiving health reports. The project has already designed a way to use CAP elements to carry information both for sharing weekly epidemiological data relevant to recipient’s area and issuing instant alert in the event of an urgent priority health crisis. The presentation titled: “Use of CAP for disease notification” explains the process of adopting CAP for serving both purposes.Some of the possible problems the project may face is – making the health officials or stakeholders understand the beauty of CAP, HCI aspects of designing effective CAP messages to fit Mobile2.0@BOP affordable handsets, and uncertainties of users accepting CAP messages.

Second Talk – The HazInfo project field tested five wireless technologies for the purpose of serving the last-mile communities in receiving risk information; especially those natural hazards, such as tsunamis, that give very little time to respond to. The HazInfo project ran for just over two years ending in March 2008; experimented with CAP as a standard for issuing alerts to the last-mile communities. CAP having emerged in 2005 with the more stable version 1.1 being released in 2006 had several drawbacks when tested in a non English speaking environment over non internet and personal computer based technologies like mobile phones, fixed phones, and satellite radios in Sri Lanka.

Given, ninety nine percent of the people in Sri Lanka are literate in Sinhala and Tamil languages and less than forty percent of the population are competent in English, alerts received in the English language in last-mile rural communities were of no use. The community members insisted that messages be delivered to them in the local language or not delivered at all. The dilemma at the Hazard Information Hub (HIH), situated at the Sarvodaya headquarters in Moratuwa, were presented with the difficult task of translating the English script global alerts, from organizations such as USGS or IOTWS bulletins, in to the two main local languages. Moreover, the challenge was in fitting the email bulletins in to CAP compliant format. Extracting the elements to describe the <urgency>, <severity>, and <certainty> to encode the priority of the alert was cumbersome. The HazInfo project had established a benchmark of completing the HIH tasks of translating, formatting, and disseminating the CAP messages in less than ten percent of the time of the crisis window to get the message across to the last-mile communities giving them ample time to execute their emergency response plans.

Inability of terminal devices to receive complete CAP messages in local languages resulted in the last-mile community first responders misinterpreting the message and executing the wrong emergency response actions. In several occasions during simulated drills in the communities, when they were presented with a “category 4 cyclone” alert they responded to a “tsunami warning” with rapid evacuations to higher grounds instead of securing the homes for cyclone weather and seeking shelter.

The lessons learned from the HazInfo project has given reasons for the need and design aspects for a “CAP Broker”, which was addressed to WMO through the presentation titled: “P2P Multilanguage CAP Broker“. The idea is to build the CAP Broker as a Free and Open Source Software in to the Sahana Messaging Module, which already contains a CAP Template/Message generator developed by Lanka Software Foundation at the request of the HazInfo project, GPRS/SMS Messaging engine developed by Respere at the request of LIRNEasia to be made available free for the Gov of Sri Lanka to adopt. The Universiti Teknologi Malaysia (UTM) is the process of developing a Chat and CAP over High Frequency (HF) Radio module in to Sahana suite of messaging engines with the use of Pactor modem and a HF gateway. These are few of the many elements that are in place. There are other elements that make the CAP Broker whole, such as a Natural Language Translation engines for speedy translations and audio-to-text and text-to-audio transformers. It is my quest to locate funding to materialize the research to develop the remaining CAP Broker elements to provide a comprehensive solution for the world use.

CAP, an OASIS initiative now adopted by ITU, was the theme at the World Meteorological Organization (WMO) organized CAP Implementers Workshop 08 – 10, December 2009. Participants from several international organizations and countries presented their cases to the audience. Due to reasons, I was unable to attend the workshop but was given the opportunity to make my two presentations remotely over the phone. Given the caliber of the delegates and material presented on the relevant subject I wish I had the capacity to attend in person.


  1. hi there
    How does one get the raingauge to transmit into a CAP server ? and Do you have any flood alerts ?

    1. Q: How does one get the raingauge to transmit into a CAP server ?

      A: If I am understanding you right, you have a rain-gauge and want to share the data through a CAP message. Simplest is the use the CAP element found in the block to share the rain level information. Example, how the XML will look like –

      I am assuming your rain-gauge is feeding the data either at every time-interval or every-level. When it reaches a certain threshold you want the rain-gauge server to create a CAP message then transmit it to a CAP Aggregator or CAP Broker of some kind. Best is to create a CAP template with all pre-populated static values such as the CAP qualifying elements (or CAP mandatory elements) etc. For each instance, reuse the template to simply populate the values and transmit to the CAP broker. You may use webservices, RSS/Atom feed, FTP, Email protocol, or any interchanging mechanism to share the CAP message generated in the rain-gauge server to transmit to the CAP broker server.

      Q: Do you have any flood alerts ?

      A: Are you asking whether we (LIRNEasia) publish flood alerts or whether CAP can accommodate flood alerts? If it’s the first no, LIRNEasia is a think tank not a Met Dept. If it’s the latter, then yes you can customize CAP to publish flood alerts.

      1. Hi

        This is helpful, Do you know what hardware I can use.. Currently we only have the raingauge that can transmit with logger using GPRS to say a database. IT does this by using FTP transmission.

        Should the conversion occur in my logger or at the cetralize location (CAP SErver) which then uses the XML to convert my rain gauge alerts into CAP messages ?

  2. This is my understanding of your present system

    rain-gauge-sensor —> logger — [FTP / GPRS] —> Server — [Script] — DB

    It doesn’t have to happen at the logger but on the database (DB) Server in the Script. If you are already accumulating the rain-gauge data in a DB, you can use the same Intel/AMD/* HW to install the CAP file generation software. I’m assuming the FTP over GPRS is staging the data in some file and then an interface is parsing and writing that data in to the DB. You could use insert some code in to that same interface script to trigger a procedure to generate a CAP file when the most recent rain-gauge value reaches a threshold.