Effectively shaping warnings

Earlier this week, I wrote about the format and wording of severe weather warnings in order to most effectively communicate the necessary information to the public. In that post (and the excellent discussion that took place in the comments), I referred several times to the problems that can arise from the shape of warnings. Before I let loose on that, let’s set some historical context. From 1953-2005, the National Weather Service issued warnings on a by-county basis. This lead to over-warning unaffected areas.

In 2005, the NWS began a pilot program to issue warnings with a forecaster-defined polygon shape. In this way, the warnings could be issued such that they reflect actual threats and not political boundaries. All forecast offices began using these “storm-based warnings” in 2007, but the system still isn’t perfect.

Radar image showing two separate polygon warnings side-by-side

Sample polygon warning from WFO Indianapolis. Source: http://www.crh.noaa.gov/ind/?n=polywarn

Even though forecasters can issue warnings that are based on the atmosphere, they still must consider the political boundaries. Many warning dissemination systems (more on this in a future post) don’t support polygon warnings, so if a warning would normally clip a corner of a county, the forecaster must consider whether or not to cut a notch out of the warning. (I asked for clarification from a friend who is an NWS forecaster. He said there’s a setting that optionally excludes tiny slivers of counties. “We try to do our best to serve two masters between county based communication systems and scientifically based warnings. The main focus at all times, however, is getting information to people who are threatened as fast as possible and in as useful a manner as possible.”)

The problem is further compounded when a storm exists along the boundary between the County Warning Areas (CWAs) of two forecast offices. Current NWS practice does not allow a warning to extend outside an office’s CWA. Since CWAs edges are determined by the county borders, they are frequently uneven. A storm may clip a small portion of another office’s CWA, and the issuing forecaster must shape the polygon to avoid that portion. In order to include said portion, the other office must issue its own warning. While offices will often coordinate when storms are near a CWA boundary, I seriously doubt that any forecasters will take the time to make sure their polygons match precisely. The resulting discontinuity can be confusing to the public and makes absolutely no sense from a threat perspective. The storm does not respect political boundaries.

Radar image with severe thunderstorm warning polygons. The shape of the middle polygon is influenced by the boundary between county warning areas

A recent severe weather event in central Indiana. The warning in the middle of the image was issued by the NWS office in Northern Indiana. The southern extent of the warning is defined by the boundary between the Northern Indiana and Indianapolis county warning areas.

Removing the county-border issues from the polygon system still doesn’t lead to perfection. Polygons themselves suffer from some issues. Notably, they’re ripe for being over-large in order to improve verification scores, as Patrick Marsh posted earlier this week. The other key concern is that, as I mentioned above, some warning systems have no concept of polygons. NOAA All-Hazards Radio (also known as “weather radio”) is a prime example., as are outdoor warning sirens (some locations have the ability to sound sirens selectively, but it is by no means ubiquitous). Until these systems are modernized, even the best polygons will still lead to over-warning.

5 thoughts on “Effectively shaping warnings

  1. Doesn’t Indiana have zones in the counties now for warnings? So there can be sub-county sized political boundaries?

    That might offer an compromise between a science based zone and a political boundary zone.

    Of course, that all states have sub-county warning zones. Not that some of the sub-county zones are still bigger than some counties…

  2. As far as I’m aware, Indiana counties still exist as single zones for NWS products. Most often, you’ll see multiple zones per county in mountainous regions to differentiate areas based on elevation.

    Sub-county-sized political boundaries aren’t necessarily helpful, either, since they’re probably ambiguous to the general public. Townships might work, but I’d suspect that more people than we care to admit don’t know what township they’re in. Not to mention that large warnings will be very lengthy.

    I’ll offer my thoughts on disseminating location-based warnings in the next few days. 🙂

  3. In Indiana, all zones coincide with county boundaries. So basically, each forecast area has two designations, one based on the zone number and the second based on the county’s Federal Information Processing Standards (FIPS) code.

    Probably the best solution for warning locations is this type of wording: “the storm will be at Stockwell at 7:30, at Dayton at 7:40 and at Rossville at 7:50.” That’s the non-graphic cousin of a polygon, and is better in that it adds detailed time elements. It takes a computer to calculate, but no one needs a computer to understand it.

    If you don’t know where any of those towns are, it probably doesn’t threaten you (unless you’re just passing through). If it does, you can head to the basement, whip out your device, and call up the NWS radar with its polygons.

  4. I have no idea what our CWA’s are up here since the only place we get weather information in NW Minnesota is from Grand Forks. I have noticed there are some occasions of being quite accurate of a storm’s affected and other times of the affected area being quite broad despite the actual storm being a fraction of the size. I am a novice when it’s coming to understanding weather so this is honestly a bit over my head but it is a good chance for me to find out some info on this stuff.

  5. Pingback: Disseminating storm-based warnings « Blog Fiasco

Leave a Reply

Your email address will not be published. Required fields are marked *