We hit a silent failure during rslearn dataset materialize for a raster layer backed by the tile store.
What happened:
- We prepared USA field windows in UTM.
- Our ERA5 layer config (
ERA5LandMonthlyMeans) accidentally used UK lon/lat bounds.
- Ingest succeeded and the tile store contained valid nonzero ERA5 rasters for the UK.
- Materialization also logged success, for example:
Materializing 6 item groups in layer era5 from tile store
- But every materialized window GeoTIFF was all zeros.
Why this happens:
- In
rslearn.data_sources.climate_data_store.ERA5LandMonthlyMeans.ingest, the configured bounds are used directly for the CDS API request.
- Later, during raster materialization,
read_raster_window_from_tiles computes the intersection between the source tile bounds and the target window bounds.
- If there is no overlap, it just
continues.
- The destination raster remains filled with the default initialized nodata/fill value, so materialization completes without any warning or error.
In our case:
- Tile store raster bounds were over the UK.
- Window bounds were over the USA.
- There was zero spatial overlap, so every output raster stayed zero-filled.
Why this is dangerous:
- The logs look healthy.
- The layer is marked completed.
- Downstream analysis sees valid-looking GeoTIFFs that are actually empty.
- This can silently corrupt experiments.
Suggested behavior:
- During raster materialization, if an item group has matching bands in the tile store but zero spatial intersection with the target window, rslearn should raise an error or at least emit a strong warning.
- Ideally this should happen before writing/marking the layer completed.
- Even better: include source bounds and window bounds in the error message.
Possible implementation points:
rslearn/dataset/materialize.py
read_raster_window_from_tiles(...)
- or the raster materializer after attempting to build the composite
A useful error might be:
Layer era5 item era5land_monthlyaveraged_2023_7 has no spatial overlap with window xxx. Source bounds=..., window bounds=...
Optional enhancement:
- Add a strict mode that fails if the final materialized raster is entirely nodata/fill after processing a non-empty item group.
We hit a silent failure during
rslearn dataset materializefor a raster layer backed by the tile store.What happened:
ERA5LandMonthlyMeans) accidentally used UK lon/latbounds.Materializing 6 item groups in layer era5 from tile storeWhy this happens:
rslearn.data_sources.climate_data_store.ERA5LandMonthlyMeans.ingest, the configuredboundsare used directly for the CDS API request.read_raster_window_from_tilescomputes the intersection between the source tile bounds and the target window bounds.continues.In our case:
Why this is dangerous:
Suggested behavior:
Possible implementation points:
rslearn/dataset/materialize.pyread_raster_window_from_tiles(...)A useful error might be:
Layer era5 item era5land_monthlyaveraged_2023_7 has no spatial overlap with window xxx. Source bounds=..., window bounds=...Optional enhancement: