Fields for schema

[jerstlouis]

See also opengeospatial/ogcapi-features#838

https://schemas.opengis.net/ogcapi/tiles/part1/1.0/openapi/schemas/tms/propertiesSchema.yaml

• uom (same as uom in Additional x-ogc keywords for encoding-independent JSON schema ogcapi-features#838 ) ?
• uomURI (same as uom in Additional x-ogc keywords for encoding-independent JSON schema ogcapi-features#838 ) ?
• uomSymbol ?
• observedProperty
• observedPropertyURI (same as definition in Additional x-ogc keywords for encoding-independent JSON schema ogcapi-features#838 )

For "axes" in the range (from opengeospatial/ogcapi-features#838)

• referenceFrame
• localFrame
• axisId

Coverages-specific

• fieldIndex (integer starting at 0)
• spatialResolution (when differing per field e.g., panchromatic band, scene classification layer, see Different per-band spatial resolutions #142)

Encoding info

• nilValues / nodata (from Additional x-ogc keywords for encoding-independent JSON schema ogcapi-features#838)
• significantBits, scale, offset, data type (encoding specifc or not... see RangeType / SWE Common Confusion coverage-implementation-schema#1 (comment))

Statistics

• Min, Max (already covered by JSON Schema?), Average, StdDev...

[jerstlouis]

Do we need a distinct ogc-x field extension for categories, or can this achieved with a JSON schema construct? (e.g., having an integer enum, and associated desription?)

https://stackoverflow.com/questions/64233370/in-json-schema-how-to-define-an-enum-with-description-of-each-elements-in-the-e offers a potential solution with an anyOf and the const keyword:

https://json-schema.org/understanding-json-schema/reference/const

For example for sentinel-2 scene classification layer:

{
  "anyOf": [
    { "const": "0", "title": "No data" },
    { "const": "1", "title": "Defective" },
    { "const": "2", "title": "Dark Area Pixels" },
    { "const": "3", "title": "Cloud Shadows" },
    { "const": "4", "title": "Vegetation" },
    { "const": "5", "title": "Bare Soils" },
...
  ]
}

[jerstlouis]

For units of measures, Features - Part 5 already specifies x-ogc-unit which defaults to UCUM and x-ogc-unit-lang (to allow for alternatives such as QUDT).

We could raise the issue that this is more a vocabulary than a "language"? x-ogc-unit-vocab?
Should x-ogc-unit be x-ogc-uom?

Does this address the needs of uom, uomURI, and uomSymbol identified above?

Do we need additional fields for semantic lookup vs. for display to the user?

We should clarify how QUDT should be identified? A full URI , or only the identifier?

Topic for the sprint in a couple week!

[jerstlouis]

In Features - Part 5, it was clarified that UCUM for example really is a language rather than a vocabulary, since you can combine different codes together to create new units, and therefore language is the more general term. A note was added there to clarify that.

The decision to use unit rather than uom is because unit is readily understandable by the uninitiated.

So x-ogc-unit and x-ogc-unitLang should address all of the uom, uomURI and uomSymbol mentioned above.

There is also a new x-ogc-definition which was added to the generic Schemas in Features - Part 5 (currently requirement 8).

A - The keyword "x-ogc-definition" SHALL be used to identify the semantic definition for the property.
B - The value of the keyword "x-ogc-definition" SHALL be a URI.

so this addresses the semantic aspect (observedProperty and observedPropertyURI).

Regarding statistics, while the standard JSON Schema properties might define the minimum/maximum values, it would not necessarily indicate the statistics of the current dataset. It might therefore make sense to define custom fields here for these.

referenceFrame, localFrame, axisId might be more relevant to Connected Systems, but if these are defined there they could also be used if relevant for Coverages.

fieldIndex has been defined in Features - Part 5 as x-ogc-property-seq.

In addition to making sure the draft reflects all these decisions so far (x-ogc-unit, x-ogc-unitLang, x-ogc-definition, x-ogc-propertySeq), this would leave the following to define:

• x-ogc-statistics : { min, max, average, stddev }
• x-ogc-encodingInfo : { nodata, significantBits, scale, offset, dataType }
• x-ogc-spatialResolution (when differing per field e.g., panchromatic band, scene classification layer)

We also discussed at the Coveages Sprint that the x-ogc-definition and x-ogc-unit concepts would replace the CRS for non-spatial/non-temporal dimension, but in this case the field inside the collection description extent dimension would simply be called definition, unit, and unitLang.

[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.

Can we do something about it?

@jerstlouis reported:

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.

But I'm not able to spot this in the current version of OGC API coverages yet. Can we add it?

[jerstlouis]

@joanma747 We could, but we need to discuss it first! :) That's why you should make sure to join the meeting tomorrow 10:00 AM Eastern ;)