Archive for the ‘Uncategorized’ Category

Open Warning Distribution

Posted: January 19, 2015 in Uncategorized

As IPAWS and the Common Alerting Protocol continue to grow in terms of alert originator adoption, we are still a long way from the promise of a streamlined system that was once promised.  IPAWSArchitectureIn theory the IPAWS OPEN server should act as a message broker between all alert and warning products as well as distribution paths.  Many manufacturers has implemented the ability to format and produce a CAP compliant alert message to originate into the IPAWS OPEN server over the last several years.  Most of these manufacturers focus on the delivery of short text based messages for the Wireless Emergency Alert (WEA/CMAS) space.

Where the market continues to have a vacuum and the public ultimately continues to lack the alert recipient paths it could benefit from is in terms of unified message origination that focuses on all available distribution paths and the willingness of distribution channel partners to embrace the IPAWS OPEN platform. To provide some perspective to this issue let us look at two of the most commonly relied upon distribution channels for critical warnings; telephone notification services and NOAA Weather Radio. Note that these both have prominent roles in the IPAWS Architecture since its beginning.


Notice that Emergency Telephone Notification Systems are shown as a key design feature of IPAWS integration.  In theory, a properly developed warning message delivered into the IPAWS domain includes detailed written and verbal (text and audio) instructions as well as links for more information, short text, etc.  Political subdivisions spend great sums of money for the maintenance of these systems to be able to directly reach into someones home by telephone.  The only problem? At the time of this writing, there is not a single mass market Emergency Telephone Notification service that offers the ability to automatically deliver telephone based notifications based on an emergency message from IPAWS.  While several ETN services give the ability to originate IPAWS messages, they do not have the ability to ingest and deliver those messages.

Similarly and perhaps even more shocking is that the National Weather Service continues to require their own authorization and registration process for the distribution of Non-Weather Emergency Messages. This is important because as Emergency Managers have made the case for many years for business and households to invest in “NOAA All Hazards Radio” most emergency mangers still lack the ability to directly activate those devices when they issue warnings. Those jurisdictions that have signed up for IPAWS need to be aware that a separate registration process is required in order to be able to activate NOAA Weather Radio.


I have been working on a few projects lately that involve providing redundant processes, particularly related to communications circuits.  What I have been finding with a great deal of regularity is that in almost all cases the technology that has been implemented over the years has replaced technologies that are still practical and effective.  In most cases, radio systems for example, low-band VHF radio systems provided noisy coverage that didn’t work from portable radios but was very reliable.  These systems were replaced by modern trunked radio systems that are very robust, offer many talkpaths, perform well in buildings but depend on complex IP based infrastructure to function.  While the upgrade path to these systems was cost effective and generally makes sense, sending hundreds or thousands of those old radios to a landfill may not be the best idea the first time you have a glitch in the new system.


Each time these issues come up someone always will say – “If only we had kept….”. Let this be the warning to each individual responsible for system lifecycles, always keep the previous generation of your networks in place and operational the greatest extent possible. Having a redundant layer is ALWAYS advisable. 


Please take a moment to view the video in this awesome post by iRevolution on the use of Cwrodsourcing for data verification.


My TEDx talk on Digital Humanitarians presented at TEDxTraverseCity. I’ve automatically forwarded the above video to the section on Big (false) Data and the use of time-critical crowdsourcing to verify social media reports shared during disasters. The talk describes the rationale behind the Verily platform that my team and I at QCRI are developing with our partners at the Masdar Institute of Technology (MIT) in Dubai. The purpose of Verily is to accelerate the process of verification by crowdsourcing evidence collection and critical thinking. See my colleague ChaTo’s excellent slide deck on Verily for more information.


View original post

A word on IPAWS

Posted: May 27, 2013 in Uncategorized
Tags: , , , ,

I have had many conversations lately with both application developers as well as public safety alert originators regarding IPAWS. In nearly every conversation one misconception shines through.  Practitioners and developers alike are considering IPAWS to simply be a tool for launching Wireless Emergency Alerts (formally known as CMAS).  While IPAWS certainly does provide the sole point of entry for WEA, it is so much more than that and is very much being undersold.  

So, have you hesitated to implement IPAWS because you view it simply as a WEA tool and aren’t sure that you want to implement WEA yet? Here are some reasons to think otherwise:

  • IPAWS provides the sole entry path into the National Weather Service’s NOAA Weather Radio for the issuance of Non-Weather Emergency Messages.  While practitioners frequently push the value of these radios to the public for weather warnings, participating in IPAWS allows that agency’s emergency messages to also activate these tone alert radios.
  • IPAWS provides an internet based path to broadcasters providing a redundant interface into the legacy Emergency Alert System.  For some alert originators this connectivity could provide a more reliable and robust means of alerting than current practices however even those areas that have adopted robust and redundant systems such as Communications Laboratories’ EMnet system could benefit from the redundancy.
  • The key to IPAWS is that it is a message broker for structured data.  Many tools focus on creating messages to send to IPAWS however very few at this point  leverage data from IPAWS to activate other warning systems.  While nearly no one has has capitalized on this yet, it allows a single activation message to trigger multiple systems.  For example a siren manufacturer could implement an encoder that monitors the IPAWS server to activate based on specific event codes within the geographic area of the siren.  Similarly a telephone based emergency notification system could deliver an audio message attached to an IPAWS alert to the alert polygon defined within that IPAWS alert.

One thing is for sure about IPAWS, it still has a long way to go in terms of vendors realizing its capabilities and alerting authorities to require full compliance within their Alert & Notification System RFPs. Educating yourself on the full capability of IPAWS is something that both groups must do NOW. Image

Another great storm related GIS post.


I’m going to keep this short because everyone else is already covering this, but I needed to pass this on.  As you already know, a violent tornado tracked through Moore, OK earlier this afternoon (May 20, 2013).  When things calm down more, I’ll try to write up more on this event later, but the map below was created based on the radar data from the FAA TDWR radar site in Oklahoma City (TOKC).

The map has interactive bookmarks for some of the facilities impacted that being broadcast over the media (schools and other large facilities).

For more current information, please follow local media outlets and state and local officials.

View original post

Sharing this blog post by Kim Stephens about the amazing work being done by the new(ish) SMEM person at MEMA. Very proud of how you have developed things at MEMA Kasey!

idisaster 2.0

Post by: Kim Stephens

The Maryland Emergency Management Agency (@MDMEMA on Twitter)  has recently taken their social media communication’s strategy to new heights–even incorporating a module about the tools into their Public Information Officer training.

I had the opportunity to meet the MEMA  Social Media Coordinator, Kasey Parr, when we both served on a panel at the Social Media Week in Washington DC (a big thank you to Michael Clarke of International Media Solutions for organizing our session). I  asked Kasey in a written follow up for a little more detail about their social media plans and current processes. Below is the result of the Q&A with both Kasey and Ed McDonough,  the MEMA PIO.

Q1. What type of Social Media content is included in the PIO training?

A1: Kasey: The first training we conducted on “Social Media in the JIC” was right before Hurricane Sandy, forcing me to cut down on my…

View original post 612 more words

Google Public Alerts

Posted: January 24, 2013 in Uncategorized

Google Public Alerts is nothing new. has been working on the Public Alerts program for quite some time through this dedicated public alerts map that aggregated data from the USGS and NWS.  Over time Google began to incorporate this data into the results for Google searches so that searching for “Tornado” within an area covered by a Tornado Watch or Tornado Warning would provide a link to that warning. This was one step closer to bringing alert information into the main stream.

Google has recently taken another major step with their Public Alerts project by making Public Alerts part of the Google Now application that is included within Android 4.1 and 4.2. With this functionality any phone that supports Google Now can receive notification of Public Alerts in their area. In reality, much like the concept of many commercial applications, this provides a Location Based Service for public warning. The great part is that all is required of an alerting authority is to publish alerts in an acceptable format that contains geospatial information (ideally using the Common Alerting Protocol) and then working with to allow them to fetch this data. If you didn’t catch the big point here, there is no cost to the agency (or taxpayer). 

Here is a little taste of Google Public Alerts

In a follow-up to this post we will look at Google’s Crisis Map.