Discussions around describing the grid model of underlying data

[jerstlouis]

SWG 2025-01-15:

We discussed today how to describe the grid model of underlying data in a flexible model, inspired in part by the NetCDF climate conventions ( https://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries ).

What we are currently missing from the grid description model in common ( https://github.com/opengeospatial/ogcapi-common/blob/master/collections/openapi/schemas/common-geodata/extent-uad.yaml#L50 ) is the ability to describe bounds (or the area of validity / relevance of the data).

For irregular grids, we agreed to:

• add a boundsCoordinates properties consisting of an array 2n values, where 2(n-1) + 0 is the lower bound, and 2(n-1) + 1 is the upper bound, for cells 1..n, in absolute coordinates
• if this property is not included, the default bounds of the cells are assumed to lie in the middle of the two values specified in coordinates, and for the two extremes, the lower (for first cell) and upper bounds (for last cell) are assumed to be at the same distance from the specified coordinate as to their immediate neighbor

For regular grids:

• add a property relativeBounds consisting of an array of 2 values, the first being the relative distance between the firstCoordinate (and each subsequent coordinate at firstCoordinate + (n-1) * resolution) and the lower bound of the cells, and the second being the relative distance between the firstCoordinate (and subsequent) and the upper bound of the cells.
• if this property is not included, the default relative bounds of the cells are assumed to be [-resolution/2, resolution/2]

In both cases, this allows for gaps and overlaps, and bounds not centered on the coordinates.
We will be slightly stricter in specifying that the coordinates need to fall on or within the bounds (this is only a recommendation in CF conventions).

We are also recognizing that this grid model description is mostly informational, and entirely optional for the server to provide (the coverage function might source inputs from a non-gridded data source), and that OGC API - Coverages clients do not really need to rely on this information.

The particular data format negotiated should self-describe the data being returned, included grid information if returned in a gridded data format, and the specific details of this grid will depend on the different parameters of the request such as the resolution of interest (e.g., scale-factor / scale-size parameter) as well as the subsetting parameters.

[pebau]

SWG 2025-01-15:

We discussed today how to describe the grid model of underlying data in a flexible model, inspired in part by the NetCDF climate conventions ( https://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries ).

...and just for the records: such an approach was first proposed by the rasdaman team, see the Coverages.SWG email thread.

[jerstlouis]

SWG 2025-02-05:

The description of the grids is mostly relevant for OGC API - Common - Part 2 (See UML model) as well as for data formats (e.g., GeoTIFF 2.0).

For retrieving data with OGC API - Coverages, the clear DE9IM currently in the draft can still apply and will depend on that definition of what constitutes the geometry of the cells (if the data is gridded, which is not necessarily the case).

We should probably clarify all mentions of "cells" in the draft, since there are only cells when the data is gridded.

[chris-little]

@jerstlouis A point cloud implies cells from the Voronoi tesselation, the dual of the .Delaunay Triangulation. Not a grid.

[jerstlouis]

@chris-little Good point that there are non-grid types of cells.
I believe AT 6 only talks about "grid" cells though.

However, I'm not sure a point cloud implies these cells (though they certainly exist if you choose to think of them!).

[chris-little]

@jerstlouis The latest update to ISO19123 is reduced compared to the original definitions in the previous version, and @pebau has committed to pursue the extension to discrete coverages in ISO. If the grid definitions that you are pursuing are separating 'pixel as centre' and pixel is data (what CF-NetCDF calls "cell method") concepts, cell methods are equally applicable to Voronoi tessellations, and the original ISO19123 does mention Voronoi cells, but calls them Thiessen Polygons.