DGGS support

[m-mohr]

Tracking issue for DGGS support in openEO:

• stac-extensions/dggs (?): tbc
• stac-extensions/datacube: Add DGGS dimension type stac-extensions/datacube#38 - May depend on stac-extensions/dggs later. Describes how to describe a DGGS data cube dimension in STAC.
• openeo.org: Add DGGS dimension type stac-extensions/datacube#38 - General overview about terminology and how DGGS would be embedded into the openEO data cube concept.
• openeo-api: Added DGGS dimension type #597 (depends on stac-extensions/datacube) - The API updates, primarily adding the STAC data cube changes and proposing some default naming. Nothing major changes here.
• openeo-processes (depends on openeo-processes-lint)
  • Implementation Guide: Add DGGS proposal / implementation guide openeo-processes#562 - Describes the initial ways how DGGS datasets could be handled in openEO, via mapping to raster, via mapping to geometries, and natively (that's what we implement here).
  • Update existing and add new processes: Support for DGGS (new and existing processes) openeo-processes#571 - Describes changes to existing and additions of new processes. This is probably the most important part as it is user facing.
• openeo-processes-lint: Add DGGS support openeo-processes-lint#1 - Internal changes to get the openEO tooling updated.

Scheduled to be discussed in the openEO community and PSC meetings in June, potentially again in November.

[m-mohr]

Open question for all PRs regarding DGGS terminology: Do we prefer to use zone or cell? (Currently it's all "zone").

[danlooo]

According to ISO 19170:2021:

While the terms cell and zone are often used interchangeably, "zone" is the strictly preferred
term. Cell is entirely appropriate when specifically discussing a zone's geometry or topology.

Strictly speaking, a cell is just the boundary polygon geometry defining the zone region.

[m-mohr]

Thanks, appreciated. Then our current usage of zone seems preferrable and we can keep it as is.