Conversation
| 2. **Geometry dimension**: Expose DGGS as a geometry dimension to the user. | ||
| - Each grid cell could be represented as a geometry (e.g. polygon or multi-polygon) with an associated DGGS cell ID. The datacube would be a **vector data cube**. | ||
| - Backends would need to keep track that the geometry dimension is based on a DGGS to efficiently apply operations that required knowledge of DGGS relationships such as adjacency and parent–child relation. Otherwise, this would need to be retrieved from the geometries itself, which is likely to be less efficient. | ||
| - Processes don't distinguish between "normal" geometry dimensions and DGGS-based geometry dimensions, which means that special DGGS processes that would require knowledge of DGGS can't be defined unambiguously. Users may pass in any geometry dimension accidentally. | ||
| - Raster-based such as `apply_kernel`, `aggregate_spatial`, or `resample_spatial` processes can't be applied. Operations based on DGGS cells can be applied, e.g. `apply_dimension` and `reduce_dimension` along the geometry dimension. |
There was a problem hiding this comment.
Just a note - using a geometry dimension would effectively mean you treat the DGGS as an unstructured grid (although with arbitrary cell shapes).
Conventions and client implementations for ugrids are
There was a problem hiding this comment.
Indeed, that's the weakness of this option.
| - It would allow the definition of new processes that directly operate on DGGS concepts, such as parent/child aggregation, k-ring neighborhood operations, or resolution changes without reprojection. It also allows that processes directly require the DGGS dimension type in process parameters and return values, which otherwise is impossible. | ||
| - Requires a new version of the openEO API and STAC datacube extension that adds the new dimension type. | ||
| - A set of new and adapted processes that explicitly support DGGS semantics must be specified. | ||
|
|
There was a problem hiding this comment.
| ## Key usage patterns to support | |
| 1. ... |
I think the evaluation of options could be guided by the key usage patterns - if we can identify them. Like:
- What are the most common tasks people perform with openEO? (Or GEE, for larger user base)?
- Do these tasks require to operate on the original data at maximum precision (e.g. for conservation of original properties such as relationship between spectral bands - thinking atmospheric correction etc.)?
- Do these tasks involve combining datasets (of different source projection)?
- What are common DGGS-specific operations? Would people miss these if the topology is hidden (mapping to raster grids)?
There was a problem hiding this comment.
Indeed, that's where I need input from the service providers. I only have a rough feeling as I don't have insight into the operational services.
|
DGGS are not unstructured, but I wonder whether unstructured grid conventions and client implementations can still be helpful to look at? 💭 |
|
|
||
| - An alternative process could be defined that allows to load the dataset with different dimension types. | ||
|
|
||
| Note that both `load_collection` and `load_dggs` would have to define cell inclusion rules, e.g. which cells to include and how to handle partial cells. |
There was a problem hiding this comment.
I don't see load_dggs mentioned anywhere else, did I miss it?
There was a problem hiding this comment.
I think I meant to write more about it, but forgot it. Pretty much meant to be a DGGS specific version of load_collection.
|
Discussed today in the openEO community and PSC meetings. There' generally support to specify version 3 - a new dimension type. More feedback to this topic is highly appreciated as none of us is really a DGGS expert. |
Good hint, I've checked and the |
3 participants
Description how DGGS could be implemented in openEO.
Feedback would be very welcome, especially from developers that have a good understanding of DGGS. (I'm pretty new to it.)