Working with historical tornado data in Missouri
I spent most of 2019 building a tornado timeline for a county-level risk assessment project, and honestly, the hardest part wasn't the mapping itself. It was getting clean data out of whatever source you're using. The NOAA Storm Events Database is the default place everyone starts, but if you pull raw data for Missouri between 1950 and 2024, you will hit some annoying edge cases that aren't documented anywhere useful. The first thing you need to understand is that the NOAA data uses a county-level polygon system, not point coordinates, for the vast majority of pre-2007 events. That means when you're plotting on a map, every tornado in a given county gets dumped into the same county boundary. It looks fine at statewide scale. It looks terrible when you zoom into the Kansas City metro area and try to distinguish between Johnson County and Jackson County events. My workaround was straightforward but took me about three hours to figure out. I wrote a script that cross-referenced the NOAA event numbers with the official NWS St. Louis and Kansas City confirmation reports. For any event where the county path was ambiguous, I could usually narrow it down to a specific city or even a latitude/longitude pair from the textual reports. This matters because if you're building something like a Missouri Tornado History Map for public use, county-level polygons make it look like every tornado in a given month hit the same spot. It doesn't. The May 2011 outbreak in particular had events scattered across a wide corridor that county boundaries completely obscure.
Here's what most people miss: the damage scale (EF0 through EF5) and the actual path length are not always correlated the way you'd expect. I pulled data for the 2011 Joplin event alongside a dozen EF3s from the same week. The EF3s had longer total paths but concentrated damage in small pockets, while Joplin's EF5 was devastating within a relatively tight corridor. If your map is showing path length as the primary visual variable, you will underrepresent high-intensity short-track events. Switch to width and severity combined. It takes more development time but the result is actually informative. Another thing worth noting is the inconsistency in reporting before the 1990s. Missouri had sparse tornado reporting going back decades, and while theStorm Events Database does include older events, many simply lack path length, width, or data. A reasonable approach is to set a hard filter: only include events with path length greater than zero and a non-empty damage class. This cuts your dataset significantly for the pre-1980 period but it also eliminates a lot of noise that would otherwise clutter your map with ghost events—tornadoes that were reported once and never confirmed by NWS survey. When I was building this, I also ran into a problem with the event IDs changing between the raw NOAA export and the spatially referenced shapefile version. The NOAA web interface gives you one set of identifiers, but when you download the shapefiles from the same site, the geometry records don't always align 1:1 with those IDs. I ended up joining on date plus county plus event type instead, which took about ten minutes of debugging but saved me from losing roughly 400 events in the merge step.
If you just want a finished product without building it yourself, the Missouri Emergency Management agency publishes a tornado climatology dataset that covers 1950 to present, and the University of Oklahoma's National Weather Center has archived shapefiles you can use as a base layer. The caveat with both is that neither updates in real time. If you're using this for anything current, plan to supplement with the latest NOAA monthly storm reports, which come out within about a week of any major outbreak. The main bottleneck I still run into is the sheer volume of data during major outbreak sequences. A single day with 50+ events across southeastern Missouri can cause most GIS software to lag significantly, especially if you're rendering individual path polygons with transparency. I learned to aggregate by day and by intensity band before importing into QGIS, which cut my project load time from around forty-five minutes down to roughly six. Not glamorous, but it keeps you from wasting half a day waiting on a map to render.
Get the Full Details
