Extension of functionalities to all other modes #248

Activity

1. shollendEODC commented on Aug 25, 2026

   

   shollendEODC

   on Aug 25, 2026

   CollaboratorAuthor

   More actions

   @emmanuelmathot @d-v-b
   would appreciate feedback/alignment on how to tackle it
2. emmanuelmathot

   assigned

   shollendEODC

   on Sep 28, 2026
3. emmanuelmathot

   added

   enhancementNew feature or requestNew feature or request

   sentinel-1Sentinel-1 products (GRD, SLC, OCN, GRD RTC)Sentinel-1 products (GRD, SLC, OCN, GRD RTC)

   sentinel-3Sentinel-3 products (OLCI, SLSTR)Sentinel-3 products (OLCI, SLSTR)

   sample-serviceRoadmap with EODC for the EOPF Sentinel Zarr Samples Service (#277)Roadmap with EODC for the EOPF Sentinel Zarr Samples Service (#277)

   on Sep 28, 2026
4. emmanuelmathot commented on Sep 28, 2026

   

   emmanuelmathot

   on Sep 28, 2026

   Last edited by emmanuelmathot

   Contributor

   More actions

   Thanks @shollendEODC for the test matrix, and sorry for the late answer. The plan that @claxn proposed in #277 answers most of this, so I suggest we use this issue to track the product coverage, with one PR per product into main, as agreed there.

   Where we are after #277 (0.12.0)

   Product	Status on main	Next step	Owner
   S2 MSI L1C / L2A	✅ optimized pipeline, CPM driver routing	encoding switch in #287	@emmanuelmathot / @lhoupert
   S3 OLCI EFR / ERR	✅ optimized pipeline (native swath or --output-grid)	check multiscales generation	@shollendEODC
   S3 SLSTR RBT / LST	❌ / ✅ in your tests (generic path)	SLSTR support after the generic chunking and sharding utilities	@shollendEODC
   S1 GRDH / GRDM (IW, EW; SDV, SSH)	❌ in your tests	first find why they fail (see below), then an S1 submodule	@shollendEODC
   S1 SLC IW	❌	after the generic parts are in place	@shollendEODC
   S1 OCN	❌	after the generic parts are in place	@shollendEODC
   S1 GRD RTC (S1Tiling / OTB COGs)	✅ standalone ingest-s1 commands (#216)	—	@emmanuelmathot / @lhoupert

   Sentinel-1 GRD failures. On main, S1 GRD goes through the generic pipeline with ground control points (groups=["measurements"], gcp_group="conditions/gcp"). Our tests cover this, but only with our fixtures. Could you share the errors (or a log) for the failing GRD products, and whether you ran them through the CPM driver with CPM 3.0.0? That tells us whether it is a CPM 3.0.0 product-structure change or a bug in the generic path.

   Order of work, following #277:

   1. Generic chunking and sharding utilities (Discussion: output chunk-layout policy for optimized GeoZarr (single-chunk policy, sharding, inner-tile size) #222, Keep input chunking pattern instead of overwriting #243), which all products need.
   2. Classification pyramids for S2 (Make classification layers (SCL, cloud masks) a full multiscale pyramid #274, with GeoZarr specification dissimilarities #245 and fix(s2): write geo metadata for conditions/mask groups so SCL is readable #262).
   3. Sentinel-1: fix GRD, then SLC and OCN, as their own submodule.
   4. Sentinel-3: all OLCI and SLSTR products.
   5. The optional "overviews" multiscale utility, and removing the reprojection under measurements for S1 GRD.

   For each product PR, please include:

   • the product in the CPM routing (cpm/routing.py, by product:type), so eopf convert-geozarr picks it up
   • tests with a fixture of the product in the current test suite. Your approval-testing proposal is welcome as its own PR, as discussed in feat!: reintegrate cpm-geozarr into main #277.
   • a line in the supported-products table of the docs (docs: present eopf-geozarr as the GeoZarr driver for EOPF CPM #289 adds it to the README and to the docs home page)