Industries

Products

Developer

Blog

Blog

/

Educational

From banned words to global standards: The evolution of weather alerts

12.19.2024//Educational, API & Mapping

Blog post banner

Xander Stone

Software Engineer

Weather alerts save lives and protect assets - but managing them across different countries, languages, and systems has traditionally been a challenge. Xweather solves this problem for customers by delivering accurate, real-time alerts wherever they operate. 

How did we get here? 

Meteorological agencies issue hundreds of terabytes of information every day, and while much of that data is not directly consumed by the wider public, some types of data are so important and so actionable that they become topics of conversation on their own. Severe weather alerts, perhaps the prime example of this type of data, are considered a staple product of meteorological agencies. However, these alerts, which are key to saving untold numbers of lives, have not always been widely available. 

Early attempts to better understand and warn about severe weather events - particularly work in the 1880s by John Park Finley of the US Army Signal Corps to better predict and warn the public of tornadoes - was met with such pushback that the word “tornado” was banned from weather forecasts until the policy was reevaluated in 1938. We've come a long way from that - today, the US National Weather Service alone issues over one hundred types of severe weather alerts

Given the importance of these alerts today, it should come as no surprise that severe weather alerts were one of the first data products made available through the precursor to the Xweather  API. However, without a defined standard, the format and distribution of alerts was often unique to each issuing met agency, which made global coverage complicated to tackle. 

It should also come as no surprise that weather forecasting and alerting has changed significantly in the years since. As the existing systems began to show their age, and met agencies began the slow but inevitable move to a newer, standardized system, we worked to overhaul our alerts ingestion workflows. 

Enter CAP

In November 2000, the US National Science and Technology Council issued a report titled "Effective Disaster Warnings". The report identified two core needs: 

  1. The need for a standard that would collect and instantly relay hazard warnings to people across a range of scales (locally, regionally, nationally), and  

  2. The need for automated systems that were also programmed to respond to hazards 

A year later, over 130 emergency management, information technology, and telecommunications experts from around the world met to formalize the Common Alerting Protocol (CAP). While it wasn't a fast transition, today, almost every meteorological agency in the world issues severe weather alerts in CAP format, thanks in large part to an effort by the World Meteorological Organization (WMO). 

The CAP standard, an XML-based data format, provides a lot of benefits over the one-off approaches met agencies had before. The CAP specification: 

  • Defined a consistent data structure (through CAP-specific XML profiles) for ingestion, 

  • Defined a set of required elements for the most valuable information (such as urgency, severity, or certainty), and 

  • Provided a universal method of updating and replacing previous alerts as new information was gathered or as models change. 

Our ingest system for alerts predates the availability of CAP-format alerts, which meant that as we worked to expand alerts coverage to additional countries, we were left maintaining very different systems. This came with all the usual caveats: multiple distinct codebases for the same product, different methods of fetching or listening for incoming alerts, and trying to fit different source data into the same schema for our end users. With all the above in mind, it was time to overhaul our alerts ingest system to take us through the next decade.  

A tough nut to crack

For an organization monitoring people, property, or the environment across multiple countries, the CAP standard does not immediately solve the complex problems outlined earlier. In particular, alerts are still: 

  1. Issued across many different providers, sometimes even by multiple providers in each country; 

  2. Include locally-relevant naming conventions that, to an unfamiliar observer, obfuscate the underlying weather phenomenon; 

  3. Rely upon each met agency’s adherence to the CAP standard; 

  4. Frequently necessitate cross-checking with alternate data sources to determine the impacted geographic area of an alert; 

  5. Are dependent on the infrastructure of met agencies around the world; and 

  6. Are often issued in only the local languages of each country. 

 

Our solutions 

We’ve gone to significant lengths to solve the above difficulties: 

  1. We source alerts from multiple different government agencies, or even multiple providers of the same data, and are constantly deduplicating the data to ensure we provide the most accurate and timely data; 

  2. We’ve built a robust list of different alert phenomena, negating the need for users to familiarize themselves with local terminology while still being able to quickly understand the risks; 

  3. We gracefully handle non-adherence to the CAP spec; 

  4. Include geometry in every alert available through our API; 

  5. Have robust systems in place to ensure data is always up to date; and 

  6. As of a few months ago, we translate all non-English language alerts into English (beginning with Brazil and Mexico), so that our users can easily read and understand severe weather events across the globe. 

Alert type consolidation 

South Africa issues alerts for "Veld Fire Conditions" when conditions are favorable for the development of bush or wildfires. However, Europe and Brazil also issue alerts for similar weather phenomenon. To aid someone monitoring alerts across many territories, we categorize this under the "Fire Weather" alert type, assigning an AW.FW code and providing styling information such that it will appear the same on a map alongside similar fire weather alerts originating from Europe or Brazil. 

While we've come across a lot of interesting alert types, one of our favorites comes out of Australia. When conditions turn cold and rainy, especially when combined with wind, this can be dangerous for livestock, sheep in particular. "Sheep Grazier Warnings" will be issued so sheep grazers can make adjustments to protect their livestock.  

An example alert for a "Sheep Grazier Warning" issued by the Australia Bureau of Meteorology as retrieved from our Xweather API.

Sadly, my suggestion to expand our alert type codes to include emoji (AW.🐑.MD) was met with an assessment of "fun, but not a good idea." 

Expanding coverage 

Our new import system has helped us streamline how we process alerts and deliver them to customers. In 2024 alone, we added support for 6 new countries, with plans to continue adding more countries over time. 

Previous alerts coverage 
  • US 

  • Canada 

  • Europe (via Meteoalarm) 

Expanded coverage 

All previously supported countries, plus: 

  • Australia 

  • Brazil 

  • India 

  • Mexico 

  • South Africa 

  • South Korea  


Weather solutions

Xweather's advanced processing capabilities drive our expanded global weather alert coverage. With support for multiple languages, standardized alert types, and coverage across major regions, Xweather enables businesses and organizations to protect their people and assets, regardless of location. 

Ready to integrate global weather alerts into your applications? Log into your Xweather Developer Dashboard or get in touch with an expert to learn more about Xweather's data and software solutions.

Xander Stone

Software Engineer

Related Resources

Related
Resources

API & mapping

Real-time weather alerting with webhooks

Article

Tutorial: Setting up a webhook endpoint

Previous

America’s war with billion-dollar hurricanes

=

Next

Extreme weather and operational risk: How to safeguard your business?