Remove GeoZarr V0 grid_mapping and spatial_ref from the output #352

Breaking change for readers that use grid_mapping or spatial_ref.

Problem

Each resolution group gives the CRS in up to five places: proj:code, the spatial_ref array (crs_wkt, spatial_ref attribute, CF parameters), the grid_mapping attribute on the group and on each array, and other_metadata. The grid_mapping/spatial_ref part comes from GeoZarr V0. It uses WKT1 (PROJCS[), and grid_mapping on a group has no meaning in CF. One product has 32 spatial_ref arrays.

Proposal

Do not write grid_mapping, the spatial_ref arrays, crs_wkt or the spatial_ref attribute, in all modes and for all missions:

• S2 and the shared path: write_dataset_geo_metadata (conversion/utils.py:413-420, rio.write_crs and write_grid_mapping).
• OLCI: s3_olci_optimization/olci_reproject.py:209-213, olci_converter.py:310.
• S1: conversion/s1_ingest.py (CF grid mapping near line 492).

proj:* and spatial:* stay the only georeferencing.

Impact

• titiler-eopf: no change. It copies proj:*/spatial:* from the group to the array (titiler/eopf/reader.py:1018-1053). rioxarray then reads the CRS with its ZarrConvention reader (read_crs_auto).
• Generic users of xarray + rioxarray: an array opened alone has no CRS, because proj:code is on the group. Put this in the release notes.
• GDAL Zarr driver: check whether it reads proj:code/spatial:transform. If it does not, put that in the release notes.

Changes

• Validator: data_api/geozarr/validation.py:262 (_grid_mapping_container_names) and data_api/geozarr/common.py:268 (check_grid_mapping).
• Tests:
  • tests/test_titiler_integration.py:239,278;
  • tests/test_integration_sentinel1.py:268-305;
  • the S1 ingest assertions in tests/test_s1_rtc_ingest.py.
• Snapshots: S2 (optimized_geozarr_examples) and OLCI (optimized_olci_examples).
• Docs: mark grid_mapping as obsolete in docs/ and in the CHANGELOG.