2026-09-24 EOPF GeoZarr multiscales review meeting #294

Multiscales in a geospatial context

https://github.com/zarr-conventions/multiscales#geospatial-data
→ A multiscales group in a geospatial context has the same CRS, but is allowed to have varying transforms and shapes

Quicklooks or/and multiscales?

For georeferenced image data and carefully generated multiscale image pyramids the whole existing stack around multiscales makes sense: “datacube access, Dask-based analysis at reduced resolution, openEO resolution_merge and pyramid-aware sampling.“

But it does not make sense to provide and mix multiscaled data with native, non-georeferenced data due to the following reasons:

• all radiometric and geometric corrections are given as metadata arrays, which only refer to the original, native data sampling in sensor geometry
• mixing native with georeferenced data is not allowed according to the convention?
• only having a multiscale pyramid in sensor geometry might be a waste of storage given the limited amount of applications

However, one can use the multiscale convention for quicklooks provided in a completely separated folder, where the native data of the multiscale pyramid is just a reprojected and resampled version.

Status of GCP-resampled Sentinel-1 GRD product

The current GCP-resampled version in the code (tested before f19f423 which might have touched the S1 GRD production we validated) seems to replace the native data with a reprojected version (also for Sentinel-3 OLCI, if the parameter output_grid is set to anything else than native). This action leads to a decoupling of metadata and native data making it impossible to apply necessary radiometric or geometric corrections. Thus these data can be only used for visualisation.

→ Version 2 demonstration of Sentinel-1 GRD and Sentinel-3 OLCI EFR

Sentinel-1 GRD

root
└── S01SIWGRD_20240201T164915_0025_A299_750E_065517
  ├── conditions
  ├── measurements
  │   ├── azimuth_time
  │   ├── grd
  │   ├── ground_range
  │   ├── polarization
  │   └── spatial_ref
  ├── multiscales
  │   ├── r2
  │   │   ├── grd
  │   │   ├── polarization
  │   │   ├── spatial_ref
  │   │   ├── x
  │   │   └── y
  │   ├── r4
  │   │   └── …
  │   ├── r6
  │   │   └── …
  │   ├── r8
  │   │   └── ….
  │   └── r10
  │       └── …
  └── quality

How to proceed with the EOPF product structure?

• All georeferenced products will follow the GeoZarr format (current GeoZarr Mini Spec). All other products will be “only” Zarr v3 with the required chunking and sharding.
• We need an attribute for special cases like Sentinel-2 L1C (-> create public issue so that the community and data experts can comment on)
• We (eodc) will create quicklooks/overviews folder as shown above for data exploratory purposes (none of the existing clients needs to comply with this, even if it follows the multiscales, spatial, and proj convention).

How to proceed with (the next products in) eopf-geozarr?

• with or without refactoring?
  • Recently raised for discussion in feat!: reintegrate cpm-geozarr into main #277
  • if no, check consolidated metadata location and application of conventions (proj and spatial) for each product (-> separate PR for each product)
• FixedScaleOffsetCodec implementation: recently raised during discussion, where and how should it be covered?
• Cloud and snow mask for Sentinel-2 L2A: recently opened in Make classification layers (SCL, cloud masks) a full multiscale pyramid #274

How to proceed with STAC?

• change asset structure for Sentinel-2 (measurements/reflectance) → addressed and merged in adding single /measurement/refectance group to stac as requested during pr247 #267
• multiscales assets representation (who uses stac_discovery and what should be in there?): https://api.explorer.eopf.copernicus.eu/browser/stac/collections/sentinel-2-l2a-samples-zarr3/items/S2B_MSIL2A_20260920T112109_N0512_R037_T29SPB_20260920T151606?.asset=asset-reflectance
  • Addition of multiscale generated bands to stac_discovery/assets: "b02_10m": {"href": "/measurements/reflectance/r10m/b02", "title": "b02_10m"}