Last week I attended the 2025 edition of the CAP Implementation Workshop in Rome, Italy, a three day conference around the use of the CAP protocol for emergency warnings.

Common Alerting Protocol (CAP)

The Common Alerting Protocol (CAP) is an OASIS standard for exchanging emergency alerts between altering authorities (meteorological or hydrological institutes, civil protection authorities, etc.) and alert dissemination channels (mobile network operators, media broadcast, sirens, etc.).

As that’s very widely used all over the world, including for global aggregation of alerts (e.g. by Google or by us), there’s the yearly CAP Implementation Workshop as a forum for exchange between all those stakeholders. Besides alerting authorities and aggregators/distributors this also included NGOs helping with and pushing for setting up early warning systems for weather, climate or geophysical emergencies as well as equipment vendors and researchers.

Alert Aggregators

With the FOSS Public Alert Server we have implemented and operate a CAP alert aggregation service, which receives alerts from more than 200 sources.

This means we get to deal with alert feeds becoming temporarily unavailable, feeds changing their URL, different interpretations of the data formats and other interesting issues in the alert data. All of that needs continuous monitoring, investigating and working on resolving issues with the alert publishers or, when that’s not possible, implementing technical workarounds.

We aren’t facing this alone though, it’s the same for all aggregators. In order to at least avoid duplicated efforts there’s now plans to improve collaboration and establish a communication channel between the aggregators.

Perfectly timed we discovered a new issue during the conference which was triggering problems on our server as well, caused by an alert feed reusing identifiers that were meant to be permanently unique.

Talk

Our talk on Thurday afternoon mainly focused on our observations and experiences with data availability, data quality (particularly from an end-user perspective) and CAP standard ambiguities (slides).

Q&A after the talk

This includes:

• Alert feeds being inaccessible for automatic access due to captchas, geo-blocking, paywalls or outright denial of access.
• Alert feeds preventing redistribution with license or copyright restrictions.
• Alert feeds where the corresponding geocode geometry isn’t published.
• Excessively detailed geometry and confusion between affected and to be alerted areas.
• Different ways of implementing multi-lingual alerts.

The most important user-facing issue however is probably alerts stopping at borders while the corresponding emergencies or disasters don’t, and we weren’t the only ones pointing that out. That’s not a technical issue though, but a very political one.

Alert area for a toxic smoke cloud being clipped to state borders.

Alerting Authorities

The alerting authorities on the other hand have a very different view on this, being legally prohibited from alerting outside of their corresponding jurisdiction. This is also part of the reason for excessively detailed area geometries and additional technical complexity like device-based geofencing for more precise cell broadcast targeting, ie. things I’d even consider counter-productive in many cases.

It’s not like this problem isn’t recognized by some alerting authorities at least, there’s e.g. some promising collaboration for cross-border alerting between Belgium, Germany and the Netherlands.

There were other topics we were able to discuss with representatives from alert producers as well, such as:

• Obtaining access to feeds we currently don’t have, such as non-weather alerts in Belgium or volcano warnings in Iceland.
• Finally resolved an issue with wrong categories on non-weather alerts in Germany.
• Meteoalarm’s upcoming rollout of ETL category codes, avoiding us having to deal with custom CAP extensions.

Standards and common practices

I had so far underestimated how much the Common Policies and Practices document is relied upon to clarify room for interpretation and corner cases of the CAP standard, such as:

• Polygon winding order and thus how to deal with geometry crossing the anti-meridian.
• 0-radius circles.
• Alert content licensing.
• Category and ETL event code translations.

Those are things we had encountered as well, so this helps. However, since those are merely common practices and not requirements of the standard, we can’t rely on this and thus it’s not a viable solution for the anti-meridian crossing geometry problem at least, as that remains ambiguous.

The other aspect that still needs a proper solution (which is in the works) is the ETL versioning issue, that I at least only realized to the full extent while discussing this at the conference: There’s a draft version with completely different meanings of the event codes and which due to a misunderstanding appears to have the higher version number.

To make matters worse, the key for those values is the same (OET:v1.0), so they aren’t distinguishable at all, which practically means we can’t distinguish whether a warning is about a dust storm or a drug supply issue, nor whether it’s about the fall of snow or space debris, for example. That currently renders all existing ETL codes practically useless unfortunately.

Outlook

It’s always good to meet everyone involved in person, and this helped a lot with getting a better understanding of the views and priorities of different stakeholders as well as with clarifying a number of details of CAP usage. Let’s see what we can get going in terms of closer collaborations with other aggregators here.