Integrate rioxarray 0.22.0 with Zarr conventions support

[emmanuelmathot]

Context

rioxarray 0.22.0 ships with full support for the Zarr spatial: and proj: conventions — both read and write (corteva/rioxarray#882). This is a direct outcome of our upstream contribution from the EOPF Explorer project.

Our GeoZarr data model already writes these conventions (proj:code, proj:wkt2, spatial:transform, spatial:dimensions, etc.) on every array. With rioxarray 0.22.0, we can now configure the convention framework so that CRS and transform resolution uses direct attribute access instead of the CF grid_mapping coordinate path.

Documentation: https://corteva.github.io/rioxarray/stable/getting_started/crs_management.html#How-Conventions-Work

Objectives

1. Upgrade rioxarray and configure Zarr conventions

• Pin rioxarray>=0.22.0 in titiler-eopf dependencies
• Set the Zarr convention as the default framework at application startup:

  from rioxarray import set_options
  from rioxarray.enum import Convention
  
  set_options(convention=Convention.Zarr)

• Verify that CRS and transform are correctly resolved from EOPF Explorer GeoZarr datasets through the full tile serving pipeline (TiTiler reader → rio-tiler → rioxarray → tile response)
• Confirm that the CF convention still works as fallback for datasets that don't carry Zarr conventions (backward compatibility)

2. Benchmark Zarr conventions vs CF conventions

The expected performance gain comes from the difference in how CRS and transform metadata are accessed:

	CF convention	Zarr convention
CRS	Requires opening the grid_mapping coordinate variable (separate data request)	Direct attribute read on the array (proj:code, proj:wkt2)
Transform	Requires grid_mapping coordinate → GeoTransform attribute	Direct attribute read (spatial:transform)

Benchmark approach:

• Use a representative EOPF Explorer Sentinel-2 L2A GeoZarr dataset
• Measure time-to-first-tile for the same tile request under both conventions
• Measure CRS + transform resolution time in isolation (rioxarray level)
• Run across multiple zoom levels (to exercise different pyramid scales)
• Report results as mean ± stddev over N iterations

Expected outcome: Measurable reduction in metadata resolution latency when using Zarr conventions, since the CF path requires an additional coordinate variable access that the Zarr path avoids entirely.

Acceptance criteria

• rioxarray>=0.22.0 pinned in requirements
• Convention.Zarr set as default in titiler-eopf configuration
• All existing tile serving tests pass (no regression)
• Benchmark report comparing CF vs Zarr convention performance (time-to-first-tile, metadata resolution)
• Results documented for inclusion in the project's performance assessment

References

• rioxarray conventions docs: https://corteva.github.io/rioxarray/stable/getting_started/crs_management.html
• Zarr spatial convention: https://github.com/zarr-conventions/spatial
• Zarr proj convention: https://github.com/zarr-conventions/geo-proj
• Original proposal: Proposal: Support Zarr Spatial and Geo-Projection Conventions in rioxarray corteva/rioxarray#882
• Implementation PR: ENH: Implement write support for Zarr conventions corteva/rioxarray#918

[vincentsarago]

Update: we can't use set_options(convention=Convention.Zarr) because in the code we use write_crs() and this will throw an error because rioxarray doesn't support writing for Zarr Convention

[emmanuelmathot]

corteva/rioxarray#918

[vincentsarago]

we don't need this anymore