Fix xarray-compatible Zarr generation for DegreeDays indicators

[j08lue]

What this PR accomplishes

• Address The xarray-compatible zarr output only contains last item #141 - at least for DegreeDays indicators, I did not test whether the issue exists for other indicators as well
• Harmonize *_map generation with other indicators, as discussed in Can we move _map output out of the main Zarr tree? #142
• Validate that output can be read with the bespoke OSC Hazard Zarr reader https://gist.github.com/j08lue/ff9634d1221dd00f0707064710ce90f5

How to test it

Run the following command:

CEDA_USERNAME=<username> CEDA_PASSWORD=<password> os_climate_hazard degree_days_indicator --store ./uk_60km_dd_28 --source_dataset UKCP18 --source_dataset_kwargs "{'resolution':'60km','domain':'uk'}" --gcm_list "[ukcp18]" --scenario_list "[rcp85]" --threshold_list "[]" --threshold_temperature 28 --central_year_list "[2030,2040,2050,2060,2070,2080,2090]" --central_year_historical 2005 --window_years 20 --write_xarray_compatible_zarr true --dask_cluster_kwargs "{'n_workers': 1, 'threads_per_worker': 1}"

and verify that the output folder structure in uk_60km_dd_28 is

/chronic_heat/osc/v2/
├── longitude
│   └── 0.0.0.0
├── latitude
│   └── 0.0.0.0
├── mean_degree_days_v2_above_28c_ukcp18_rcp85_2030
│   └── 0.0.0.0
├── mean_degree_days_v2_above_28c_ukcp18_rcp85_2040
│   └── 0.0.0.0
...
├── mean_degree_days_v2_above_28c_ukcp18_rcp85_2090
│   └── 0.0.0.0
└── spatial_ref

[j08lue]

NB: Regarding the overall goal to produce data cube and xarray friendly Zarr output,

• Discussion : writing xarray-compatible zarr stores #66

this solution falls short.

You cannot open individual arrays - this fails:

xr.open_dataset("uk_60km_dd_28/chronic_heat/osc/v2/mean_degree_days_v2_above_28c_ukcp18_rcp85_2030", engine="zarr", consolidated=False)

but you can open the group with

xr.open_dataset("uk_60km_dd_28/chronic_heat/osc/v2", engine="zarr", consolidated=False)

and get a Dataset where all the arrays are variables.

<xarray.Dataset>
Dimensions:                                          (latitude: 18,
                                                      longitude: 26, index: 1)
Coordinates:
  * latitude                                         (latitude) float64 60.86...
  * longitude                                        (longitude) float64 -13....
    spatial_ref                                      int64 ...
Dimensions without coordinates: index
Data variables:
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2030  (index, latitude, longitude) float32 ...
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2040  (index, latitude, longitude) float32 ...
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2050  (index, latitude, longitude) float32 ...
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2060  (index, latitude, longitude) float32 ...
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2070  (index, latitude, longitude) float32 ...
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2080  (index, latitude, longitude) float32 ...
    mean_degree_days_v2_above_28c_ukcp18_rcp85_2090  (index, latitude, longitude) float32 ...

Cool enough (although data cube would be nicer), but how would we describe this in STAC?

Variables with these long parameter chains as names seem to be the wrong way to describe the dimensionality of this dataset.

However, since the maintainers' intention is to maintain backwards compatibility of the Zarr output, this may be the only way.

[j08lue]

This notebook shows that the output produced with this branch here can be read with both OscZarr and Xarray: https://gist.github.com/j08lue/ff9634d1221dd00f0707064710ce90f5