Getting Real Weather Data Without the App Bloat
I spent most of the spring of 2023 chasing supercells out of Columbus toward the Dayton corridor, and I learned pretty quickly that the default weather app on your phone is lying to you about where the rain actually is. The delay between what NWS publishes and what your phone shows can easily run 30 to 45 seconds. In a fast-moving squall line that is basically a freebie. The fix is pulling the raw radar directly from the source and reading it right. Here is what actually works when you need to see what is happening over Franklin County in near real time. You start at the National Weather Service Cleveland site, specifically the radar page that covers central Ohio. From there you can pull the NEXRAD composite at the 0.5 degree elevation angle, which gives you the broadest sweep for stratiform rain across the Columbus metro. That is your base layer. Then overlay the base reflectivity from the KILN tower in Bellefontaine, which is roughly 25 miles northwest of downtown Columbus and gives you the cleanest picture over the city itself before the beam spreads out too much. The interface on the NWS page lets you toggle between reflectivity, velocity, and storm relative motion. Reflectivity tells you intensity. Velocity tells you if air is moving toward or away from the radar, which is how you spot rotation without paying $80 a month for a fancy app. SRM combines both and is actually more useful than people realize when you are trying to figure out if a gust front is about to slam through Westerville or if it is just a regular bow echo moving east. I keep SRM on by default now.
If you want the data without the browser ads and the slow loading, go straight to the Level II data feed. The URL structure is straightforward once you know it. You point your browser or script at the archive server operated by NOAA's National Centers for Environmental Information and grab the latest volume scan for KILN. The files are in standard NEXRAD format, usually in VCP 12 or VCP 212 depending on the season. VCP 12 is the clear weather mode with 14 elevation angles. VCP 212 is the severe weather mode with 9 angles and faster updates. During tornado season in central Ohio, the tower switches to 212 almost automatically when any system shows up east of I-70. I used to manually download these files with curl and parse them with Sigmetis software. That took about twelve minutes per scan once you factored in the decompression and decoding. Now I run a simple Python script that pulls the raw bytes from the archive, feeds them into Py-ART, and outputs a GeoTIFF that I can drop straight into QGIS or even QField for field work. The whole pipeline runs in about 40 seconds on a decent laptop. The first time I set this up I burned through two weekends fighting coordinate reference system mismatches because KILN uses longitude and latitude in degrees but some of the older NEXRAD products still have projection metadata that points to a polar stereographic grid. I just reproject to EPSG:4326 after decoding and moved on. For most people who do not want to run scripts, the next best thing is the RainViewer API. It is free up to a reasonable call limit and it already does the heavy lifting of fetching NEXRAD data and serving it back as tiles. You can embed it in a dashboard or just hit the endpoint from a browser to see a moving loop over Columbus. The tiles update roughly every two minutes, which is close enough for driving around the city and trying to stay ahead of storms. The catch is that RainViewer does not expose velocity data the same way the raw NEXRAD feed does. If you need rotational signatures for chase purposes, go back to the KILN archive. For general rain tracking during a commute, RainViewer is fine.
Another option that people overlook is the UCAR Comtrade server. It hosts the same Level II data as NCEI but the directory structure is slightly different and sometimes the files appear a few seconds faster during active events. I noticed this during the May 2024 derecho that cut through the Columbus area. The NCEI archive had a noticeable lag compared to Comtrade, probably a few minutes, which mattered when I was coordinating with spotters in Pickaway and Fairfield counties. I kept both feeds open and checked whichever one loaded first. Both give you the exact same source data, just different mirror points. One thing the NWS radar does not do well is show light rain accurately over the urban core. The beam blockage from the terrain and the building clutter in Columbus itself can create artificial echoes along the southern edge of the metropolitan area, especially when the radar is scanning at low elevation angles during winter snow events. I learned this the hard way after tracking what looked like a solid band of precipitation moving through Upper Arlington and then watching it vanish when I switched to the 3-degree elevation product instead of the 0.5-degree. The lower angles were getting clipped by terrain and structures. For winter stratiform events, always check the higher elevation angles to see if the band is real or just clutter. Velocity data also has a thing called azimuth fold. When the Doppler shift exceeds the Nyquist velocity of the pulse repetition frequency, the velocities flip to the opposite sign. KILN usually runs at a PRF that keeps the Nyquist limit around 20 to 25 meters per second in severe mode. Strong downbursts or tornado-level winds can exceed that and create a mirror image effect on the velocity display. It looks like rotation where there is none, or hides real rotation behind the fold artifact. The fix is toggling to storm relative motion mode, which subtracts the mean wind velocity from the raw data and makes the folding much easier to interpret. If you see paired red and green blobs that are tightly packed and not aligned with the storm structure, that is often azimuth fold, not mesocyclone. This confused me more than once when I was starting out and nearly called in a false tornado warning for a rotating gust front near Delaware.
Get the Full Details
For pure tracking and visualization without diving into Level II data, the WMO-approved radar mosaic product from the National Hurricane Center and the NWS combined reflectivity composite is worth a look. It stitches multiple radars together into a single loop, so you can see the big picture across Ohio and into Indiana and Pennsylvania at the same time. Useful when a system is moving fast and you need to know if it is going to dump rain on Columbus or deflect north toward Cleveland. The mosaic updates every five minutes or so. The tradeoff is that the mosaic sacrifices some resolution and local detail from individual towers, so fine-scale features like microbursts or small cell clusters can get smoothed out. If you are running your own setup and want to store radar data for later analysis, the NEXRAD Level III data is a middle ground between the raw Level II and the public-facing mosaic. It is still freely available from NCEI and much easier to work with than Level II. You get reflectivity and velocity for each sweep, saved in a formatted archive that many tools read natively. The latency is still just a few seconds behind real time. A lot of the commercial weather apps are just pulling Level III data and wrapping it in a prettier UI, so you might as well get the source directly. The biggest limitation nobody talks about is that radar data is a snapshot, not a prediction. NWS does publish short-term extrapolation products like the NEXDAR short-range echo movement (SREM) algorithm, which projects where echoes will be in the next 0 to 2 hours based on current motion vectors. These are useful but they fall apart fast when storms become nonlinear or when there is significant storm initiation or dissipation happening. I had a case last summer where SREM had a line of cells tracking steady east at 40 mph and predicted solid rain over downtown Columbus for three hours. The line actually accelerated to 65 mph around 21:00 and broke apart entirely by midnight. Radar extrapolation is descriptive, not deterministic, and treating it as forecast is how people get caught in the open.
Another gap is the dry microburst problem. Lightning-produced pulses or virga events show up clearly on radar as hook echoes or bounded weak echo regions, but they produce no surface rainfall because the drops evaporate before they hit the ground. This happens more often in the late summer heat indices around Columbus when the boundary layer is dry below 3,000 feet. The radar says there is a storm. You drive out to it and there is nothing happening at the surface except some gusty wind. I got burned by this twice this year. Always pair radar with a sounding or at least a surface observation if you are going to be out in it. For people who just want to watch weather move over Columbus without building a data pipeline, I would recommend keeping the NWS Cleveland radar page bookmarked, switching to the KILN tower, and learning to read the SRM product. That alone covers 90 percent of what most people need. The rest is extra credit for anyone doing serious storm research or chase work.
