proposal: add filter_dggs process for spatial filtering on DGGS data cubes

[suriyahgit]

Summary

Adds a proposal for a new filter_dggs process that filters DGGS data cubes by spatial bounding box using grid-specific indexers (e.g. healpy.query_polygon for HEALPix grids).

This is complementary to the existing filter_bbox process: while filter_bbox covers DGGS via zone-centroid intersection semantics, filter_dggs enables back-ends to use native DGGS indexing for orders-of-magnitude faster cell selection on large grids.

Changes

• proposals/filter_dggs.json — New process specification with parameters:
  • data — DGGS data cube (dimension type dggs)
  • extent — Bounding box in EPSG:4326 (or custom CRS)
  • method — Optional grid-specific indexer hint (e.g. "healpix", or null for auto-detect)
• tests/filter_dggs.json5 — Test file (L3-DGGS level, experimental: true)
• CHANGELOG.md — Added filter_dggs to the list of new DGGS proposal processes
• filter_bbox.json — Added cross-reference to filter_dggs() for back-ends that support DGGS-native spatial indexing

Rationale

For full-grid HEALPix cubes (e.g. NSIDE=1024, ~12M cells), generic bounding box filtering requires scanning all lat/lon coordinate arrays. A DGGS-native implementation using healpy.query_polygon computes intersecting cell indices in O(log n) time with no coordinate I/O, staying fully lazy with Dask. The method parameter provides a clean extension point for other DGGS types (rHEALPix, ISEA3H, etc.).

[m-mohr]

I don't fully understand the difference (yet), which is likely due to my inexperience with DGGS. Why is this needed in contrast to filter_bbox? Doesn't it make more sense to use the faster methods in filter_bbox then? Generally, I think it makes sense to make the default processes efficient, we may not need the filter_bbox semantics as defined right now if there's a better way.

Generally, openEO processes should ideally be implementation agnostic. Specific mentions of software implementations can go into the implementation guideline, but should not be in the process description.

If it makes things faster, happy to hop on a quick call to discuss.

[suriyahgit]

You are spot on. You're right that "filter_dggs" currently resembles what "filter_bbox" could already do. The motivation behind introducing it isn't fully reflected in the current proposal.

In my mind, this process would eventually support DGGS-specific capabilities such as filtering by cell IDs, parent/child cells, neighbourhood relationships, resolution-aware operations, and configurable spatial predicates (e.g., centroid vs. intersects). The current proposal doesn't capture that vision yet. In the next iteration of the project, i ll start to guide myself in this direction.

For now, let's leave the PR as it is. I'll refine the idea further, and then we can have another discussion once the broader concept is clearer. Thanks for the quick feedback!

[suriyahgit]

I updated and squashed the proposal to better reflect this distinction and to remove implementation-specific details from the process contract.

The main change is that filter_dggs is no longer framed as “a faster filter_bbox”. I agree that basic bounding-box filtering should still be optimizable inside filter_bbox where possible.

The intended distinction is now more about DGGS-native selection semantics:

• filter_bbox remains the generic bounding-box filter. For DGGS data cubes, it can retain zones based on the bbox semantics currently described for DGGS, such as zone-centroid based selection.
• filter_dggs exposes selection concepts that are specific to DGGS data cubes and are not expressed by filter_bbox, such as:
  • selecting explicit DGGS zone identifiers through cells,
  • supporting string or numeric zone identifiers, for example HEALPix-style numeric cell IDs,
  • choosing the spatial predicate for extent-based filtering, currently centroid or intersects,
  • optionally expanding explicit cells by topological adjacency through k,
  • explicitly selecting the DGGS dimension through dimension.

So the motivation is not to prescribe a particular faster implementation strategy, but to expose DGGS concepts directly in the process API where users need them.

I also removed implementation-oriented details such as healpy, Dask/lazy execution, backend indexing strategies, and the previous method parameter.

Based on your previous response @m-mohr , i am also preparing a little notebook with a synthetic healpix dataset like the ones i encounter in the current DEDLCube project i am working on, so that i can showcase the real use-case value of this process and it's python based process implementation. I ll attach the notebook when i complete it with this thread.