Antenor Blog 5 min read
Weather Nowcasting with Public Data: What We Learned
Lessons from building a convective nowcasting system on SINARAME radar and GOES-19 satellite data: pipelines, baselines, verification, and honest skill claims.
Weather nowcasting means predicting the next zero to six hours, the window where storms develop faster than global numerical models can react. Public data is now good enough to build serious systems: weather radar networks and geostationary satellites like GOES-19 are open and near real time. Our main lessons from building a convective nowcasting system on Argentina’s SINARAME radar network and GOES-19 imagery: data engineering consumes most of the effort, simple extrapolation baselines are humbling, and verification methodology decides whether your skill claims mean anything.
Nowcasting sits in a gap. Numerical weather prediction models are excellent from about six hours outward, but they assimilate observations in cycles and cannot keep up with a thunderstorm that forms, drops hail, and dissipates inside ninety minutes. For logistics, agriculture, insurance, energy, and public safety, that ninety minutes is exactly the window that matters. We built a convective nowcasting system for that window as an internal research project, working entirely from public data, and published the approach as a preprint. These are the transferable lessons.
The public data stack is better than most engineers assume
You do not need a proprietary data contract to do real nowcasting work. Our system runs on two public sources:
- Ground weather radar. In Argentina, the SINARAME network of national weather radars provides reflectivity volumes: the most direct observation of precipitation intensity and structure available. Most countries with a radar network publish comparable products (NEXRAD in the United States, OPERA in Europe).
- Geostationary satellite. GOES-19 covers the Americas with multispectral imagery every few minutes. Satellite sees where radar does not reach, observes cloud-top evolution before precipitation forms, and is indispensable for coverage gaps.
Radar gives you precision where it exists; satellite gives you coverage and earlier signal. The combination is stronger than either source alone, and both are free.
Lesson 1: the pipeline is the project
On paper the ML problem is clean: given recent frames, predict future radar fields. In practice, the majority of engineering went into everything before the model:
- Ingestion resilience. Public feeds have outages, late files, and format quirks. A nowcasting system that assumes clean, on-time data will spend half its life in a failed state.
- Georeferencing and regridding. Radar volumes in polar coordinates and satellite imagery in a geostationary projection must land on a common grid, correctly, every few minutes. Subtle projection errors look exactly like model errors downstream.
- Quality control. Ground clutter, beam blockage, and anomalous propagation contaminate radar data. Garbage in the training archive quietly caps model skill.
- Archive building. Training needs months of aligned multi-source history. Building that archive, and validating its alignment, was a project in itself.
If you are budgeting a nowcasting effort, put most of the budget here. This matches our broader experience with production ML: the model is the small, replaceable part.
Lesson 2: respect the baselines
The standard baselines in nowcasting are persistence (the future equals the present) and advection-based extrapolation: estimate the motion field from recent frames and move the current precipitation along it, as in optical-flow methods of the Lagrangian persistence family. These baselines are embarrassingly strong in the first tens of minutes. Any learned model must be judged as skill over extrapolation, not skill over nothing. Where ML earns its place is in what extrapolation cannot do by construction: growth and decay. Storm initiation, intensification, and dissipation are precisely the events with operational value, and precisely where pure motion extrapolation fails.
Lesson 3: verification methodology is the credibility test
Nowcasting has mature verification practice, and skipping it produces impressive-looking nonsense.
| Verification element | Why it matters |
|---|---|
| Categorical scores (POD, FAR, CSI) at defined reflectivity or rain-rate thresholds | Operational users care about event detection, not pixel averages |
| Neighborhood methods such as FSS | Penalizing a correct storm displaced by two kilometers as a total miss misrepresents useful skill |
| Skill stratified by lead time | Every method degrades with lead time; a single averaged number hides where the model is actually useful |
| Comparison against extrapolation, not persistence only | Extrapolation is the real incumbent; beating persistence alone is not a claim |
| Case studies of high-impact events | Aggregate scores can hide failure on exactly the severe cases that justify the system |
A subtle trap we learned to respect: pixel-wise losses push models toward blurry predictions, because smoothing hedges against displacement error. Blurry fields score deceptively well on some metrics while being operationally useless for severe convection. Metric choice is not a reporting detail; it shapes what the model learns.
Lesson 4: define the product, not just the prediction
“Predicted reflectivity fields” is a model output. “Will this storm cell reach this depot in the next hour, with what intensity” is a product. The step between them, from gridded fields to per-location, per-lead-time answers with calibrated uncertainty, determines whether anyone can act on the system. We treat that layer as a first-class deliverable, designed with the decision it serves.
The full system, data sources, and evaluation are described in our weather nowcasting case study, and this class of work belongs to our predictive models practice.
Frequently asked questions
Can nowcasting work in regions without radar coverage?
Yes, with reduced precision. Satellite-only nowcasting from geostationary imagery detects convective initiation and tracks cloud-top evolution, which supports useful warnings where radar does not reach. Skill for quantitative precipitation is lower than radar-based systems, so the product design should emphasize event alerts over rain-rate estimates.
Why not just use a commercial weather API?
Commercial APIs are the right answer for coarse, generic needs. They become the wrong answer when your decisions are hyperlocal and minutes-sensitive, when you need calibrated probabilities for a specific operational threshold, or when API pricing at your query volume exceeds the cost of running your own pipeline on public data. That crossover is a calculation worth doing, not an assumption.
How far ahead can nowcasting see?
Usefully, up to a few hours, with skill decaying steadily by lead time and by phenomenon. Motion-dominated stratiform rain extrapolates well for longer; rapidly evolving convection is harder and the honest window is shorter. Any vendor quoting a single flat accuracy number across lead times should be pressed on their stratified verification.