ESA Antarctica Datacube

The ESA Antarctica Datacube makes Antarctic scientific data easier to access and analyse by combining selected datasets into analysis-ready Zarr stores. The data are collected and combined by theme for:

• Antarctic Land Ice:

For land ice data, the datasets were combined and reprojected to a common 100x100m grid in EPSG:3031.

• Antarctic Sea Ice:

For sea ice data, the datasets were combined and reprojected to a common 12.5km grid in EPSG:6932.

Putting datasets on a common projection, resolution, and coordinate system reduces the amount of preprocessing needed before analysis. Instead of repeatedly handling reprojection, spatial joins, resampling, and file-format differences, you can focus on comparing variables across the same x and y grid.

Content¶

The notebooks in this folder introduce the ESA Antarctica Datacube workflow from two angles: using prebuilt remote cubes, and understanding how multiple datasets can be aligned into a shared analysis grid to produce ARD.

1. 1_remote_cube_access.ipynb opens the remote GeoZarr stores lazily with xarray, selects a small region of interest, and plots example layers without downloading the full cube.

2. 1_remote_sea_cube_access.ipynb opens the remote GeoZarr store for the sea-ice cube data.

3. 2_build_single_cube_demo.ipynb demonstrates the construction pattern on a compact ROI by combining gridded, vector, and raster inputs onto one EPSG:3031 grid.

4. 3_large_area_processing.ipynb shows how to work with larger cube regions using Dask.

Additionally there are notebooks that show how one can access external datasets and combine it with the cube data under ./accessing_external_datasets

Visualization¶

You can see a visualisation of the data in eodash:

https://esa-earthcode.github.io/polar-science-cluster-dashboard/

Land Ice Data Collections Overview¶

• All spatial layers are aligned to one projected EPSG:3031 x/y grid. Full-resolution level 0 uses 100 m cells, with x from -2867900 to 2867900 and y from -2457900 to 2457900, giving 57,358 columns by 49,158 rows.

• Each published land-ice store is a multiscale GeoZarr with levels 0 through 4.

• The same x, y position refers to the same place across every variable.

• Some datasets already closely match the target grid. Others had to to be reprojected, shifted, resampled and interpolated. The default interpolation method is nearest neighbour.

• Vector datasets are converted into raster variables by burning their geometries onto the target grid.

• If a dataset contains extra dimensions, such as time, depth, height, band, or category, the spatial transformation was applied across the horizontal grid while preserving those dimensions. All datasets are then combined in several stores according tot heir common dimensions

Table of Datasets¶

Current Assumptions and Future Refinements¶

The current approach and any other approach to upsampling or downsampling the original data will invite distortions. In some cases the data then becomes unusable for some scientific analysis. This is why we also transform and keep the original data in a cloud-friendly format (see 1_Datasets) to enable other scientific workflows that do not require a whole integrated data layer.

Sea Ice Data Collections Overview¶

• All gridded variables use the EPSG:6932 EASE-Grid 2.0 South projection with 12.5 km cells. Level 0 contains 712 × 712 cells over an extent of -4,450,000 to 4,450,000 metres.

• The same x, y position represents the same location across every gridded variable.

• Source data were aggregated to monthly timesteps where required and spatially interpolated using method nearest onto the common grid.

• The GeoZarr includes multiscale summaries at 25 km and 50 km resolution.

• ALBATROS remains a point-based GeoParquet dataset. It can be aggregated and combined with the cube grid as demonstrated in 1_Datasets/albatros/access.ipynb and plot 3 at 2_Datacube/1_remote_sea_cube_access.ipynb

Table of Datasets¶

Current Assumptions and Future Refinements¶

Monthly aggregation could invite distortion to some datasets or render them useless (as for example ALBATROS’s specific time tidal prediction data). These should be handled as auxiliary data or aggregated with care. Geozarr conventions evolve and the cube conventions need to follow these.