Additional x-ogc keywords for encoding-independent JSON schema

[alexrobin]

I would like to discuss the possibility of defining additional keywords so we can use this type of logical schemas for observations in connected systems. I think at least some of these keywords would also be of interest for more general feature use cases.

A preliminary list of keywords is the following:

• uom: unit of measure for a numerical value, either as a UCUM code or as a URI
• codeSpace: URI providing a codespace for a string value
• definition: URI of semantic definition for the property represented by the JSON member
• referenceFrame: URI of reference frame or CRS that a vector or matrix is expressed relative to
• localFrame: URI of frame that a vector or matrix is providing the position of
• axisId: Name of axis along which the field is expressed (must be an axis of the referenceFrame)
• nilValues: Provides special values and associated reasons for a given field

[cportele]

Meeting 2023-06-19:

• When drafting part 5 we probably need to establish a register for property roles (managed by the OGC-NA?). It would be good to have a simple file mechanism that does not depend on the OGC Rainbow, where also the SWGs can prepare a PR to the register.
• Some values like definition could also be defined in Features. We can review the other proposal in due course.

[jerstlouis]

It would be great to harmonize this with Coverages as well where we have moved to use an [ogc-rel:coverage-schema] link to /collections/{collectionId}/schema.

See opengeospatial/ogcapi-coverages#173 issue about the x-ogc- semantic annotations we are considering there.

It should also be possible to offer both /items and /coverage for the same data collection, a classified point cloud being available both as LASZip at /coverage and as MultiPointFeature at /items and /items/{itemId} for example, with the same /schema making sense in both cases.

Technically the same encodings (e.g., Shapefile and LASZip) would make sense in this case at both /items and /coverage, but /items/{itemId} could filter on a specific class, where the itemId represents the point class like road, lowVegetation, building...).

[alexrobin]

@cportele was there a decision as to which properties will be included in features part 5 and which ones will have to be defined by extensions? (i.e. we can define some additional ones in connected systems if needed, and I suppose coverages can do the same).

IMHO I think definition definitely belongs in features. It's basically the same as what a JSON-LD context would typically provide.

[cportele]

@alexrobin - We discussed this at the OGC code sprint. We decided to add "x-ogc-definition" and I also added a comment on the use of "language" for units to address a comment from the Coverages code sprint. See #891.

We plan to review and merge this tomorrow. The goal is to move Parts 4 and 5 very soon to the OAB review.

[joanma747]

I recommend to reopen this issue.

In the current draft of Features part 5 I see the adoption of x-ogc-definition and x-ogc-unit but I do not see x-ogc-nilValues or equivalent to specify nodata values, what is essencial for grid coverages. I was not able to spot anything like this in the current draft of ogc api coverage.

[jerstlouis]

@joanma747 We have this related open issue in Coverages: opengeospatial/ogcapi-coverages#173 (comment)

Where we are suggesting x-ogc-encodingInfo as an object with sub-properties nodata, significantBits, scale, offset, dataType. This may be more relevant to gridded coverage encodings, and less so for Features.

[joanma747]

My apologies. I was actually convinced that I was writing this in the OGC API coverages issues.