From GFS Grids to Google Earth: Local Storm Forecasts You Can Actually See
We’re building a GFS-based storm forecast system that paints town/city/county-level risk on Google Earth. Starting with where I live in Porter County, Indiana, and its neighbors, the forecast is a 48-hour window, updated every six hours. The same pipeline ranks the worst storms across six U.S. regions, using MariaDB for run bookkeeping and ClickHouse for the heavy grids. Sign up for your own county via our Contact page; forecast data and Google Earth links follow once the automation is live.
Why Google Earth
Numbers and graphs are fine for a desk meteorologist. For everyone else, storms make more sense when you can spin the globe and see them land on your counties, preferably before the patio furniture becomes airborne. We’re building a forecast system that turns GFS (Global Forecast System) data into something you can drop straight into Google Earth: county-level overlays for your home county and its neighbors, plus a national “worst storms” view split into six regions. The first slice is personal: Porter County, Indiana, with Jasper, LaPorte, Starke, and Lake counties, on a 48-hour window that refreshes every six hours with each new GFS cycle (00, 06, 12, and 18 UTC).
Why Porter County, Indiana
We had a Derecho where I live in Porter County, Indiana, on August 11th, 2026. NIPSCO, our power provider had 300,000+ customers without power, its largest outage on record, including my home. That was about 70% of their electric base. A week later, 90% of us were back on the grid. My neighboring city of Portage had 80% of their tree canopy wiped out in minutes, much of it strewn across residential streets. My town of Valparaiso hauled away 1,800 tons of debris in the first 10 days. Traffic signals were down on many major roads, and businesses were closed for several miles along US Route 6, one of the longest routes in the US.
Why GFS, and what we’re actually watching
GFS is NOAA’s global numerical weather prediction model. It doesn’t “know” tornadoes the way a radar does; it gives you the ingredients. For severe weather we lean on a familiar set of parameters and derived fields:
Instability: CAPE and CIN (how much energy is available, and what’s capping it)
Shear: deep-layer and low-level wind shear that helps organize storms
Moisture: precipitable water and low-level dew points
Lift: fronts, outflow boundaries, and other forcing that can punch through the cap
Wind and precipitation: for derechos and flash-flood risk
Tropical signals: for hurricane tracks and intensity context when those systems are in play
Derechos show up as long-lived, progressive wind signatures. Tornado environments lean on the shear–CAPE–moisture combo. Hurricanes get their own treatment from the same GFS backbone, with regional worst-case picks feeding the national view. The point isn’t to replace NWS warnings, it’s to make the next two days of risk visible on a map you’d actually open. Radar is great at telling you what’s already angry. This is about what’s still loading the dice.
Local first, then six regions nationwide
Locally, each run clips the GFS grid to the five-county footprint, scores storm potential hour by hour out to 48 hours, and writes KML/KMZ layers Google Earth can paint as colored polygons, placemarks, or time-aware tracks. Zoom in on Valparaiso, pan to Gary or Michigan City, and the story stays geographic instead of becoming a spreadsheet.
Nationally, the same scoring rolls up into six regions; NorthWest, SouthWest, NorthCentral, SouthCentral, NorthEast, and SouthEast, so you can see where the ugliest storms are lining up without drowning in every grid cell in CONUS. Local detail where you live; regional triage for the rest of the country.
MariaDB and ClickHouse: different jobs, same pipeline
Two databases, two jobs:
MariaDB is the operational brain. Cycle status, county definitions, region membership, run metadata, retry state, and “did this 06Z forecast finish cleanly?” live here, the same kind of bookkeeping I use in the code with a GFS_Status-style table. Relational, transactional, easy to query from any programming language.
ClickHouse is where the heavy grids and storm scores land for analysis. Billions of parameter values across forecast hours are a poor fit for a traditional OLTP store; ClickHouse is built for that scan-and-aggregate work, regional rankings, county time series, and the queries that feed KML generation without melting the box.
Rough flow: download GFS → decode/subset → stage metadata in MariaDB → load fields and scores into ClickHouse → emit KML for Google Earth → rinse every six hours.
GFS cycle (every 6h)
- Wx download / decode
- MariaDB: status, counties, regions
- ClickHouse: grids + storm scores
- KML/KMZ → Google Earth (local 5-county + US 6-region)
Your county, coming soon
Porter County is the pilot, not the finish line. In the near future you’ll be able to sign up for your own county (and its neighbors) through our Contact page. Once the programs are ready and the automation is humming, we’ll send you the forecast data and Google Earth links for your area, no need to memorize GRIB jargon or babysit a download script.
Takeaway
Storms aren’t abstract. GFS supplies the physics, MariaDB keeps the pipeline honest, ClickHouse makes the big queries fast, and Google Earth is the display people already know how to use.
This is the architecture post. More to follow.
Stay tuned, and happy forecasting!