You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
openeo.org: Add DGGS documentation openeo.org#114 - 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).
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.
Activity
m-mohr commentedon Jun 18, 2026
Open question for all PRs regarding DGGS terminology: Do we prefer to use zone or cell? (Currently it's all "zone").
danlooo commentedon Jun 19, 2026
According to ISO 19170:2021:
Strictly speaking, a cell is just the boundary polygon geometry defining the zone region.
m-mohr commentedon Jun 19, 2026
Thanks, appreciated. Then our current usage of zone seems preferrable and we can keep it as is.