Why your county gets warned for a storm that is nowhere near you

Someone in your office gets a severe thunderstorm warning on their phone. They walk to the window. The sky is blue. Radar shows the storm forty miles east, moving away from you.

Nothing is broken. Your alerting system is matching on counties, and the National Weather Service stopped warning counties for that product almost twenty years ago.

What changed in 2007

On October 1, 2007, the NWS introduced storm based warnings for tornadoes, severe thunderstorms, flash floods, and marine hazards. Before that, a warning covered whole counties. After that, the warning carried a polygon drawn around the actual threat.

The reasoning was simple. A county can be a thousand square miles. A supercell is not. Warning an entire county for a storm affecting the eastern third of it meant most of the people who got the message were never in danger.

Watches did not change. A watch is still issued by county and zone, because a watch means conditions are favorable across a broad area. Most winter weather products are still zone based for the same reason. Ice does not travel along a vector the way a thunderstorm does.

So the products arriving in your feed are not uniform. Some carry a polygon. Some never will. An alerting system has to handle both, and that is where most of them go wrong.

Why systems still match on counties

Because it is easy.

Every NWS product carries UGC codes identifying counties and zones. Converting those to FIPS or SAME codes is a lookup table. Match the code, notify everyone in the county, done. It works for every product, it never fails, and it needs no spatial database at all.

Polygon matching needs PostGIS or an equivalent, county boundary geometry, and a spatial index. It is real work to build. So plenty of tools skip it, and the tradeoff gets handed to you as alert fatigue.

Alert fatigue is not a minor annoyance. It is how warning systems die. People mute the notifications, and then one day the notification mattered.

The obvious fix, and why it overcorrects

The obvious answer is to stop matching on counties and start testing whether the warning polygon intersects your county. In PostGIS that is one function call.

I built it that way first. It was worse.

A bare intersection test has no area threshold. It returns true if the polygon touches your county by a single square meter. Warning polygons clip county corners constantly, because they are drawn around storms rather than around administrative boundaries. And if you have simplified your county geometry for rendering speed, which almost everyone has, your boundaries are now slightly wrong in exactly the way that manufactures intersections which should not exist.

So you trade “warned for a storm forty miles away” for “warned because a polygon grazed the corner of the county.” Different failure, same mute button.

What actually works

Here is the part that is not obvious, and it took me a while to see it.

The county list attached to a modern storm based warning is not a legacy artifact. The NWS derives that list from the polygon, and applies a real area threshold when doing it. A polygon that merely clips a county corner does not put that county on the list.

Which means the county list is better than your intersection test. They already did the spatial work, with a threshold, against authoritative boundaries instead of your simplified ones.

So the rule is this. When the product carries a county list, trust it. Fall back to raw polygon intersection only for geometry-only products that have no list to trust.

That is the whole design. It sounds like a step backward toward county matching and it is the opposite. You are using a county list computed from the polygon, instead of a county list that ignores the polygon entirely.

For facilities that need precision finer than a county, test the specific point. A water treatment plant, a stadium, a substation. Point in polygon against the warning geometry answers whether that site is in the path, which is a different and much better question than whether its county is.

The bug that taught me to check the geometry

One more thing, because it cost me an afternoon.

The polygon in a raw NWS product arrives as a LAT...LON block. Coordinates in hundredths of a degree, longitudes positive west, wrapped across lines by a format built for teletypes.

My first parser read coordinates until the first blank line. That works almost every time. Then a product came through with an oddly wrapped coordinate block that had a stray blank line in the middle, and the parser stopped early. It did not raise an error. It returned a perfectly valid polygon built from the first few points.

A tiny sliver where a county sized warning area should have been. Everything downstream then worked flawlessly on the wrong shape.

The fix was to read consecutive coordinate tokens across whitespace and newlines, stopping at the first token that is not a coordinate. The broader lesson is the one worth keeping. A geometry parser that fails loudly is fine. A geometry parser that fails quietly and hands back a smaller valid polygon will skip people who needed the warning, and nothing in your logs will tell you.

Check the area of whatever you parsed. If it is implausibly small, treat that as a parse failure rather than as a small storm.

What to ask a vendor

If you are evaluating an alerting tool, there is a short and useful question here.

Ask whether it matches storm based warnings on the polygon or on the county. If the answer is county, you now know what your Saturdays will look like.

If the answer is polygon, ask the follow up. What happens when the polygon clips a corner? The answer to that one tells you whether they have actually run this thing in weather.