Context
The EOPF Explorer project developed a custom GeoZarr reader in titiler-eopf that handles multi-scale selection, CF and Zarr conventions decoding, and optimized Zarr dataset access. With GeoZarr now supported by rioxarray and community traction growing, there's a clear path to generalize this reader and move it upstream into rio-tiler / titiler-xarray, making GeoZarr a first-class citizen in the TiTiler ecosystem, not just an EOPF-specific feature.
This activity focuses on two tracks: performance improvements and upstream integration groundwork.
Scope
1. Dataset opening latency reduction
Current dataset opening adds significant overhead to tile serving. Experimental work in [titiler-eopf#88](EOPF-Explorer/titiler-eopf#88) shows promising results. This task will:
- Profile and optimize the Zarr store opening path (metadata fetching, consolidation lookup, xarray engine initialization)
- Evaluate obstore vs fsspec performance for initial metadata access
- Reduce redundant reads during multi-scale level selection
- Target: bring dataset open time closer to COG-level latency for cached metadata scenarios
2. Full rioxarray integration & CF extension support
The current reader relies on custom EOPF-specific logic for CRS resolution, dimension mapping, and scale/offset decoding. With rioxarray 0.22+ now natively supporting GeoZarr conventions, we can:
- Replace custom CRS/grid_mapping handling with rioxarray's native GeoZarr path
- Roll out full CF conventions support
- Validate that the automatic multi-scale selection logic (currently EOPF-specific) can be expressed generically for any GeoZarr-compliant dataset
- Document the remaining gaps between the current custom reader and what
rio-tiler / titiler-xarray would need to support GeoZarr natively
Outcome
A leaner, faster GeoZarr reader in titiler-eopf with reduced custom code, clear documentation of what needs to move upstream, and a concrete path for @vincentsarago to integrate GeoZarr support directly into TiTiler's core stack. This directly benefits the EOEPCA platform (eoapi-k8s deployments) and any TiTiler user wanting Zarr visualization.
Context
The EOPF Explorer project developed a custom GeoZarr reader in
titiler-eopfthat handles multi-scale selection, CF and Zarr conventions decoding, and optimized Zarr dataset access. With GeoZarr now supported by rioxarray and community traction growing, there's a clear path to generalize this reader and move it upstream intorio-tiler/titiler-xarray, making GeoZarr a first-class citizen in the TiTiler ecosystem, not just an EOPF-specific feature.This activity focuses on two tracks: performance improvements and upstream integration groundwork.
Scope
1. Dataset opening latency reduction
Current dataset opening adds significant overhead to tile serving. Experimental work in [titiler-eopf#88](EOPF-Explorer/titiler-eopf#88) shows promising results. This task will:
2. Full rioxarray integration & CF extension support
The current reader relies on custom EOPF-specific logic for CRS resolution, dimension mapping, and scale/offset decoding. With rioxarray 0.22+ now natively supporting GeoZarr conventions, we can:
rio-tiler/titiler-xarraywould need to support GeoZarr nativelyOutcome
A leaner, faster GeoZarr reader in
titiler-eopfwith reduced custom code, clear documentation of what needs to move upstream, and a concrete path for @vincentsarago to integrate GeoZarr support directly into TiTiler's core stack. This directly benefits the EOEPCA platform (eoapi-k8s deployments) and any TiTiler user wanting Zarr visualization.