Subsetting by geometry

[jyucsiro]

For geoscience use cases, we may want to subset a coverage by a defined feature/geometry. For example, subsetting a defined region from a continental-scale evapotranspiration coverage dataset.

Could this be offered in the coverages api? e.g.

GET /collections/{coverageid}/coverage/rangeset?subset=hasGeometry(<geometry_url>)

where Geometry URL could be either cached/known to the server or retrieved in real-time. Suggest hasGeometry aligning with the GeoSPARQL property. An example of this is a Watershed/Drainage basin called "Darling river" in Australia. The URL for this could be: http://gds.loci.cat/geometry/geofabric2_1_1_awradrainagedivision/9400206

In the case that it is known/cached on the server, then the coverage api implementation will go ahead and perform subsetting and return the result (rangeset data for input geometry).

Where the geometry would need to be retrieved, the server could resolve the URL and via content negotiation (say HTTP Accept: application/json), the server could retrieve the geometry and go from there...

Alternatively, a client might drop in the geometry as WKT.

GET /collections/{coverageid}/coverage/rangeset?subset=hasGeometryAsWKT(<geometry as WKT>)

Lastly, the client might want to specify whether to return contained or overlapping cells as a separate parameters, e.g.

GET /collections/{coverageid}/coverage/rangeset?subset=hasGeometry(<geometry_URL>)&subset=geoTopology('<topology>')

... where topology could be from Section 7. Topology Vocabulary Extension (relation_family) in the GeoSPARQL spec, such as, 'sfContains'.

[pebau]

interesting indeed! 2 comments:

• this is subsetting the coverage so it should not address the rangeset component only, rather: GET /collections/{coverageid}/coverage?subset=...
• what would the result of using a topology operator when applied to a coverage? This coming from features seems not applicable to coverages, but maybe I am missing something.

[jyucsiro]

this is subsetting the coverage so it should not address the rangeset component only, rather: GET /collections/{coverageid}/coverage?subset=...

@pebau ah ok - so you're saying it would apply to both /rangeset and /coverage

what would the result of using a topology operator when applied to a coverage? This coming from features seems not applicable to coverages, but maybe I am missing something.

On this, when the geometry is used to subset the coverage, the cell in the coverage can overlap, intersect, touch etc. - so the topology parameter could be specified to include/exclude certain parts of the coverage as the user requests. the default could just be sfContains.

[pebau]

@jyucsiro, so what would that mean in, say, a TIFF image -how would you technically exclude pixels from the image?

[bilts]

We are interested in this sort of feature as well. In our case, we've always thought of it in terms of allowing users to provide a geometry in some standard shape file format (GeoJSON, ESRI Shapefile, KML, GeoRSS, etc) and we subset to that geometry. A concern I'd have about the URL-based approach is that it may become an impediment to users who have a shapefile that is not hosted anywhere.

[nmtoken]

some standard shape file format, assuming you mean vector format here. Note though that KML isn't a vector only format it does raster too.

[cmheazel]

@pebau Some coverage formats are organized into cells. The cell is the smallest addressable unit.

[cmheazel]

This seems like a bit much to ask of a Coverage API. It has to recognize a wide body of Feature formats, know how to extract the geometry from each, convert that geometry into a common form, then execute the subsetting logic.

What if we coupled an API-Processing with the API-Coverage? We could host one or more "Extract Geometry" processes which would extract and return the geometry in a form that API-Coverages would understand. We could then pass that result as an input parameter to the subsetting operation.

Use simple building blocks to build complex functionality?

[pebau]

@cmheazel: now that is an interesting idea as well. I wonder, though, how could that all go into one request?

[nmtoken]

it would be like a WCPS request I guess

[pebau]

right, that is possible thanks to the agreement found at the Bethesda meeting using
http://www.acme.com/oapi/collections?wcps=my_WCPS_request

[bilts]

@pebau could you elaborate on that agreement or point to docs? It sounds useful. What would that request do?

[pebau]

@bilts: there was no written document as outcome of the coverages sprint, but a summary slide deck: https://docs.google.com/presentation/d/1gMpGKc6JnsCHUATH21E1VWC-80ItvxMW8Wdkdhy4n-g/edit#slide=id.g6d47947f6b_2_5
Slide 67 contains the relevant WCPS part. The request takes an OGC WCPS query string as input and delivers a set of coverages as result of the server-side processing (which can be pretty much anything: extraction, reprojection, deriving new coverages, analytics, fusion, etc.). The relevant slide contains examples.
On github, there is a pending pull request giving the definition, see https://github.com/opengeospatial/ogc_api_coverages/tree/extensions/extensions

[jerstlouis]

Isn't subsetting a coverage by a defined feature/geometry exactly what the EDR API is all about?

[pebau]

Isn't subsetting a coverage by a defined feature/geometry exactly what the EDR API is all about?

it fits naturally with coverages; MetOcean-WCS has defined a variety of such polygon/raster clipping functionality, and in our extension to WCPS such functionalit is available, too - see this demo: https://standards.rasdaman.com/demo_clipping.html

[Schpidi]

Coverages SWG call: We'll try to coordinate with EDR starting at next month's sprint.

[jerstlouis]

Subsetting by geometry will be possible with a CQL2 filter= containing an S_INTERSECTS() function call with a geometry argument (as proposed as a Part extension in #164).
It should then be possible to have equivalent Coverages requests to most or all EDR queries.