search

opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Fields for schema #173

Open jerstlouis opened 1 year ago

jerstlouis commented 1 year ago

See also https://github.com/opengeospatial/ogcapi-features/issues/838

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

For "axes" in the range (from https://github.com/opengeospatial/ogcapi-features/issues/838)

Coverages-specific

Encoding info

Statistics

jerstlouis commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

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:

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 commented 3 months ago

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 commented 3 months ago

@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 ;)

joanma747 commented 2 months ago 

> {
>   "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" },
> ...
>   ]
> }
>

Is there a possibility to link to external lists ? Can we have a URI for each "classification" value?

joanma747 commented 2 months ago

Look at "observation characteristics" properties that comes from OMS for other "things" to add. https://umltool.ogc.org/index.php?m=7&o=CCBF8590-E16B-4e08-B49A-8804CBF4B7A6