[Paper] MetNet Global

[jacobbieker]

Arxiv/Blog/Paper Link

https://arxiv.org/pdf/2510.13050

Detailed Description

This is the global MetNet paper, using satellite imagery for 0.5km and 15 minutely precipitation forecasts globally, up to 12 hours.

There are a few interesting points in it. The main targets are CORRA precipitation from GPM, with auxiliary targets being precipitation radar outputs from Japan, Europe, and the US, as well as GPM IMERG Final precipitation estimates.

They use 7 geostationary satellites, the 3 EUMETSAT ones + GK-2A, Himawari9, GOES-19/GOES-18, and blend them into a single mosaic using satpy.

Similar to MetNet-2 on the lead time conditioning, as well as some other architectural tricks to save memory (cropping the feature maps for example as you go through the residual blocks)

[Sagarpillai]

Hi @jacobbieker

I’ve been reading the MetNet Global paper, and this issue sounds like an exciting direction for the project. The idea of combining global satellite data for nowcasting.

I’d love to help out however I can maybe with data preparation, testing out parts of the architecture, or just helping set up an initial framework.

Could you share what the next steps might be, or if there’s something small I could pick up to get started?

[jacobbieker]

Hi! Great to hear you are interested in helping out.

A good portion of the components of the model should already be in this repo, as they build a lot of MetNet-2 it seems. The data prep is a very large task, but help there would also be great. I don't think that would be a small starting point though.

The main things that come to mind are:

1. Implement the architecture in the paper
2. Combining of weather radar data
3. The mosaicing of the satellite data

Of those, one that might be a good starting point would be 3. the mosaicing. I've actually already been archiving geostationary satellite data in Icechunk format here, covering all of the satellites they use. The archives are very spotty and incomplete as of right now, but a good first step would be to try to generate the mosaic using those archives. A good time to choose would be 01-01-2018 or 01-01-2022, as my archives should be available for that date for all the satellites and bands. The archives have already been processed by Satpy, so are in the correct, calibrated units. So what would be needed is how to actually merge those images together. Would that interest you?

The other option for a small starting point would be the internal cropping between layers. Its probably the main missing component of the new architecture in this repo, the rest of the architecture could be put together from the components already in the repo I think, so adding support for that would be really interesting!

Happy to help guide for either of those, or anything else you would like to try!

Just to note, on the weather radar data, its difficult data to work with and might be hard to get, so I wouldn't choose that as a first step. I'm also working on a CORRA dataset now to try to make the same targets available in an easy to use format.

[Sagarpillai]

@jacobbieker

Thanks so much for the detailed context, that really helped me understand the bigger picture. From what I gather, this repo already contains many MetNet-2 components, and the missing parts mainly involve data handling and architectural details like mosaicing and internal cropping.

The mosaicing task sounds like a great place I can start with, especially since the Icechunk archives are already processed by Satpy. My understanding is that this step would involve combining imagery from multiple geostationary satellites (for a date like 01-01-2018 or 01-01-2022for example), aligning their spatial footprints and bands, and outputting a single, coherent mosaic for downstream model input.

Proposed approach:

1.	Explore the Icechunk satellite archives and inspect their metadata (bands, coverage, timestamps).
2.	Implement a script/module to align and merge the images spatially into one mosaic.
3.	Add a simple validation step (metadata or visual) to confirm correct alignment.

Does this sound like the right direction? If so, I’d love to take this up, please assign me. Looking forward to working together with you!!!

[Sagarpillai]

Hi @jacobbieker

I've made progress on the satellite mosaicing task! 🛰️

Current Status

Successfully implemented data access for the Icechunk archives:

• ✅ Loading data from GOES-East, GOES-West, Himawari
• ✅ Time-based queries for 2018-01-01 (as you suggested)
• ✅ Handling duplicate timestamps in satellite scans

Example output:

Loaded 2 satellites for 2018-01-01

GOES-East: GOES-16, 500m resolution, -75.0° center, 21696x21696 GOES-West: GOES-18, 500m resolution, -137.0° center, 21696x21696

Data confirmed to be pre-processed by Satpy with correct calibration

Questions Before Continuing

Before implementing the spatial mosaicing, could you advise on:

1. Target projection - Equirectangular, native geostationary, or other?
2. Overlap handling - Priority by satellite, blending, or quality-based?
3. Reprojection tool - pyresample or satpy.Scene.resample()?
4. Spectral bands - Start with visible only (C02/VI006) or all bands?

Code Ready

I have working implementation in /data directory:

• mosaic_builder.py - Core data access
• demo_mosaic_access.py - Demo script
• README.md - Documentation

Should I open a draft PR for review, or wait for guidance on the spatial processing approach?

Thanks in advance, excited to make this work!!!

[jacobbieker]

Great! Feel free to open a draft PR while you work on it. We want to match how they did the mosaics in the paper, so one for each of the bands they picked (18 total for all the bands). Starting with a visible band sounds good.

Most of the questions are answered in the paper, so I would recommend looking over that again.

2. The target projection is equirectangular, to match the other inputs.
3. Overlap is blending by the azimuth of the pixel view from the different satellites.
4. Satpy uses pyresample anyway, so either works. It might be hard to get the icechunk data back into a Satpy Scene, so pyresample might be easier. But I would look at how Satpy resample works to try to match that.
5. Visible might be easiest to debug by looking at the outputs, so sounds good there.

[Sagarpillai]

Hi @jacobbieker ,

I was able to figure out the Icechunk configuration and successfully merge two compatible bands from GK2A and GOES-East. I've opened PR #76 with a minimal proof-of-concept.

Please review when you have a chance. If this approach looks good, I can start working on the next steps. Thank you in advance!!!

[Sagarpillai]

Hey @jacobbieker ,

I’m thinking of working on replacing the current simple mean merge with a Gaussian center-weighted blend, similar to what the MetNet Global paper describes for mosaicing overlapping geostationary satellites.

From what I understand, the blended pixel value should be computed as:

merged = (w1A + w2B)/(w1 + w2)

where each weight is given by:

w=exp(-d^2/2σ^2)

and d is the angular distance between the pixel and the sub-satellite point of satellite i.

I’d start by implementing the math + weight computation using synthetic lat/lon grids (no real data or reprojection yet), and add a new method = "gaussian" option to merge_two_arrays, along with unit tests for weighted blending and missing data behavior.

Does that sound like a good direction to proceed?

[jacobbieker]

Yeah, that sounds like a great way to approach this!

[Sagarpillai]

Hey @jacobbieker
Would it be okay if work on adding the canonical global equirectangular grid (0.05°) used by Global MetNet and a lightweight pyresample-based reprojection utility to map the existing Satpy-processed (Icechunk) satellite DataArrays onto that grid?

This would just define the shared grid + reprojection helper, and should unblock the follow-up work to build visible-band geostationary mosaics that match the paper. Is this the right direction to proceed?