Use API-EDR query patterns for some subsetting requirements

[chris-little]

Assuming a GeoDataCube has similar attributes/properties to the W3C DataCube/QB vocabulary, slicing and trimming along various dimensions should be straightforward, using the Coverage approach, but for big GeoDataCubes, it may not be enough data reduction, especially to support multiple users scalably with reasonable response times, especially where the GeoDatCube cannot be easily, or even feasibly, replicated.

In such cases, the Point, Radius, Area, Cube, Trajectory and Corridor queries should be very useful. These queries also have vertical and temporal extents as well, and dimensions are not restricted to (x, y, z, t).

[jerstlouis]

@chris-little With OGC API - Coverages - Part 2: Filtering, deriving and aggregating fields, most or all of the EDR queries could be expressed by a simple filter= extension using CQL2 e.g.,

filter=S_INTERSECTS(rec.cells, POLYGON((-109 64.39894807, -61.25 64.39894807,-61.25 76.7652818, -109 76.7652818, -109 64.39894807)))

See also the ER in section 5.1.2.6. Future work: geometry intersections, spatial joins, aggregation and convolution.

(related to #6 ).

It also of course still be possible for a GeoDataCube API implementation to also decide to additionally conform to OGC API - EDR as an additional data access mechanism.

[chris-little]

@jerstlouis So what would a query such as filter=S_INTERSECTS(rec.cells, POLYGON((-109 64.39894807, -61.25 64.39894807,-61.25 76.7652818, -109 76.7652818, -109 64.39894807))) look like when requesting also specific vertical and temporal restrictions?