Author Topic: How to properly identify unique NWS Weathet Alerts  (Read 330 times)

0 Members and 1 Guest are viewing this topic.

Offline daneast

  • Member
  • *
  • Posts: 48
How to properly identify unique NWS Weathet Alerts
« on: February 16, 2019, 10:57:44 AM »
A problem I worked around several years ago is coming back to bite me.  When the NWS issues a weather alert it contains an identifier (as seen in the CAP XML data).  This ID is very large - for example:
Code: [Select]
NOAA-NWS-ALERTS-VA125CE6A94674.SpecialWeatherStatement.125CE6A98300VA.RNKSPSRNK.83a31346d0c2d7baf95c3d3609b985ff
My system notifies our users of weather alerts.  I cannot use that full ID to uniquely identify a given alert because it may change.  If a change is made to the alert (such as fixing a typo, or changing a time) then that ID changes.  However, it is the same alert, just slightly modified.  Thus if I used that entire ID I would be considering any change as a totally new alert, and send out broadcast notifications to all my followers.  I do not want that behavior, and all the other weather apps and sources of alerts I've seen do not do that either - somehow they filter these changes to an existing alert and know they are not entirely new alerts.

What I noticed is that the final element in that identifier after the period does not change when an alert is modified. In the example above I am using 83a31346d0c2d7baf95c3d3609b985ff as the identifier within my system.  That mostly works...

Here's the problem. Some weather offices seem to recycle old alerts.  So that final piece of the identifier may be reused over the course of several years for totally different kinds of alerts.  This only happens for some offices.  For others there is zero reuse.  So I have to use an imprecise workaround that for IDs I already have I check how old it is.  If it is more than 48 hours old I consider it to be a totally different alert (and thus I also potentially rebroadcast long-running alerts every 48 hours too).  I append a timestamp onto the alert so it has a new unique ID to my system.

What is the proper way to handle this?  I will contact the NWS about this, but I wondered if anyone here has the same issue and how do you handle it.  I will reply with any information the NWS provides about this.

(Oh, as to how it has come back to bite me: I had a DB issue on one system that failed to store the weather alerts I already processed. Since I have code that can re-use an existing ID by adding a timestamp and making a new unique ID, it allowed the alert to be rebroadcast many times).

Thanks!

Offline Jasiu

  • Forecaster
  • *****
  • Posts: 951
    • LexMAWeather
Re: How to properly identify unique NWS Weathet Alerts
« Reply #1 on: February 16, 2019, 11:50:42 AM »
What I've seen is that when something is issued with a new ID, it is because the "expired" time for the previous one is passing / has passed. The expired time for the alert is often before the actual event happens.

For example, on 2/11 (Monday) at 7:21am we had a Winter Storm Watch issued for a storm that wasn't coming until noonish on Tuesday.  That Watch alert had an expiration time of 3:30pm Monday.  At 3:33pm, another iteration of the Watch was issued with very minor text changes but a different ID. The apps I have (ping4alerts and StormRadar off the top of my head) gave me alerts for both of these.

I don't know if that's what you are trying to avoid, but I've observed the NWS keeps a short window on the lifespan of an alert, probably on purpose.
https://lexmaweather.info
On Mastodon: @LexMAWeather@toot.community