0

Significant Weather Advisories Not Dropping Off

David Bonnette

February 13, 2020 20:39

Completed

Follow

Howdy!

 

I noticed that SigWxAdvisories (SPSs) show up fine shortly after they're issued, but they don't always drop off at the right time. This can leave the screen very cluttered since SPSs are one of the weird products that can't be edited or cancelled once they're issued or replaced by a SVR.

Here's an example of a screenshot I just took where the highlighted SPS expired but is still displayed after the placefile updated. The SPS expired at :30 after the hour, and the placefile was updated at :31. I know this particular case may be nit-picky, but they regularly hang around for 15+ minutes after expiration--It's still on there 9 minutes later.

• Facebook
• Twitter
• LinkedIn

4 comments

• 
  Ryan Hickman March 30, 2020 17:59 Official comment

  David,

  SPSs don't use a standard format for expirations. This means we can't accurately determine when they're supposed to expire.

  Unfortunately there isn't anything that can be done about this until we're able to accurately parse an expiration time. For instance, sometimes they use "EFFECTIVE UNTIL," sometimes "EFFECTIVE THROUGH" and sometimes just "UNTIL". If there was a standard format that the NWS used, this would be different.

  
  Edit: I've made a minor modification which may improve the accuracy of this determination. However again, this isn't fool-proof and it's due to SPSs not being entirely standardized like VTEC WWAs.

• 0
  
  David Bonnette March 31, 2020 03:47

  Thanks for the reply Ryan - Is it possible to use the product header time stamp? It’s included on every SPS that gives the expiration time.

• 0
  
  David Bonnette March 31, 2020 03:49

  I’d attach a picture of what I’m talking about, but it’s the part of the product that lists which zones are included then a date/time stamp.

  For example:
  IAZ070-071-081-281915-
  Or
  TXZ091-092-302115-

• 0
  
  Ryan Hickman April 10, 2020 23:11

   

  This has been handled in an update. I don't recall that being a part of the specification when I originally wrote the decoder.

  I'll close this as resolved.