Fields for schema #173

jerstlouis · 2023-09-06T15:02:27Z

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

The text was updated successfully, but these errors were encountered:

jerstlouis · 2024-02-13T14:09:09Z

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 · 2024-02-13T14:47:47Z

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 · 2024-03-13T15:49:13Z

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 · 2024-08-27T17:08:12Z

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 · 2024-08-27T17:17:44Z

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

- The main change relates to the ability to describe meaning of enum values related to opengeospatial/ogcapi-coverages#173 (comment) using a combination of `anyOf` with `const` + `title` as described in https://stackoverflow.com/questions/64233370/in-json-schema-how-to-define-an-enum-with-description-of-each-elements-in-the-e - Other changes are gramamr fixes and minor clarifications - Changing indirect dependency to QUDT in general as opposed to QUDT units since QUDT can also used for semantic definitions (not only QUDT units) - Clarified that JSON Schema keywords can also include additional keywords in section below

- The main change relates to the ability to describe meaning of enum values related to opengeospatial/ogcapi-coverages#173 (comment) using a combination of `anyOf` with `const` + `title` as described in https://stackoverflow.com/questions/64233370/in-json-schema-how-to-define-an-enum-with-description-of-each-elements-in-the-e - Changes also introduce a new `x-ogc-nilValues` keyword for identifying nil values - Other changes are gramamr fixes and minor clarifications - Changing indirect dependency to QUDT in general as opposed to QUDT units since QUDT can also used for semantic definitions (not only QUDT units) - Clarified that JSON Schema keywords can also include additional keywords in section below

joanma747 · 2024-10-01T08:43:02Z


> {
>   "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 · 2024-10-01T08:46:35Z

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

jerstlouis · 2024-12-04T16:03:50Z

SWG 2024-12-04:

There is on-going discussion about how to add extra information about enum values, with 2 potential approach discussed in this Features - Part 5: Schemas PR: schemas: Changes to sync OGC API - Common review ogcapi-features#953 (comment).
We will discuss in Common setting up a wiki page listing the x-ogc-* fields (see also Part 5: Add table of x-ogc- properties ogcapi-features#945)
Regarding nodata, we had proposed x-ogc-nilValues that could support multiple null values -- also consider the possibility to use NaN as discussed in Testbed 20-GIMI
x-ogc-statistics should be defined
We should consider x-ogc-spatialResolution in relation to issue Different per-band spatial resolutions #142

Possibly needing further discussion:

Regarding encoding info e.g., significantBits, scale, offset, dataType, the challenge is this information might not be part of the logical schema but specific to a particular format (part of the physical encoding). Perhaps a response header accompanying the response could carry this information for formats such as PNG not carrying this information? (See OGC API - DGGS Requirement 26 for Values-Scale: and Values-Offset: response headers)./ Perhaps we can mention the use of JSON Schema type: number vs. integer, minimum / maximum and common format such as int32 and int64 for integer, and float and double for number (see https://swagger.io/specification/#data-types), which could be considered at the logical level to provide information ahead of time for the clients.
@joanma747 Looking at your link for "observation characteristics", this information seems to be data that varies with each observation i.e., each cell. Is there anything else which is metadata about the field itself that we are missing from this OMS model? OMS is significantly more complex / comprehensive as a model, where a lot of this extra metdata might not fit the "flattened" fields representation.

KathiSchleidt · 2024-12-04T17:30:29Z

@jerstlouis On the OMS ObservationCharacteristics, this element can be applied at all levels, e.g. individual Observation, Timeseries, Collection of Observations.

In the Coverage context, it could be used to provide additional metadata on the individual fields. I recently did an example in the context of the TSML update where I extended a CovJSON Timeseries with OMS concepts in the parameters

jerstlouis · 2024-12-04T17:59:40Z

@KathiSchleidt @joanma747 So which are the extended fields that we should define?

Tomorrow in Common we're planning to set up a wiki page to keep track of them (see opengeospatial/faster-directions#1 (comment) regarding how difficult this has become).

From your example we would have:

x-ogc-definition -- This has already be defined and I believe would correspond to observedProperty
x-ogc-unit and x-ogc-unitLang -- This has already been defined as corresponding to unit
x-ogc-observingProcedure
x-ogc-observer
x-ogc-featureOfInterest
x-ogc-host -- Could we somehow qualify or rename this -- host has a rather specific meaning on the web?

Would other things be relevant?

KathiSchleidt · 2024-12-04T22:26:48Z

@jerstlouis for OMS:host, how about we change this to sosa:Platform?

SOSA is the semantic twin of OMS under W3C, currently we're updating SOSA based on the recent OMS update.

jerstlouis · 2024-12-06T03:30:38Z

@KathiSchleidt I've created a Wiki page on the OGC API - Common repo to keep track of the x-ogc-* extension keywords until the Naming Authority sets up a register for them:

https://github.com/opengeospatial/ogcapi-common/wiki/Table-of-extensions-to-the-JSON-Schema-vocabulary

KathiSchleidt · 2024-12-09T16:16:11Z

@jerstlouis just updated the OMS links in the table. Many thanks for the overview!

Note on the UML Tool: the main browser URL just gets you to the main landing page. To link to an individual page, you have to copy the link to the diagram from the navigation on the left

This was referenced Sep 6, 2023

Different per-band spatial resolutions #142

Open

Additional x-ogc keywords for encoding-independent JSON schema opengeospatial/ogcapi-features#838

Closed

jerstlouis mentioned this issue Mar 13, 2024

Schemas: QUDT -- URI or id ? Add an example? opengeospatial/ogcapi-features#909

Closed

jerstlouis added this to OGC API - Coverages - Part 1: Core Aug 21, 2024

jerstlouis moved this to Next Discussions in OGC API - Coverages - Part 1: Core Aug 21, 2024

jerstlouis mentioned this issue Sep 24, 2024

schemas: Changes to sync OGC API - Common review opengeospatial/ogcapi-features#953

Open

fmigneault mentioned this issue Oct 24, 2024

The OGC API process is fast or slow? opengeospatial/faster-directions#1

Open

jerstlouis mentioned this issue Dec 11, 2024

Interpolation considerations #197

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fields for schema #173

Fields for schema #173

jerstlouis commented Sep 6, 2023 •

edited

Loading

jerstlouis commented Feb 13, 2024 •

edited

Loading

jerstlouis commented Feb 13, 2024

jerstlouis commented Mar 13, 2024 •

edited

Loading

joanma747 commented Aug 27, 2024 •

edited

Loading

jerstlouis commented Aug 27, 2024

joanma747 commented Oct 1, 2024 •

edited

Loading

joanma747 commented Oct 1, 2024

jerstlouis commented Dec 4, 2024 •

edited

Loading

KathiSchleidt commented Dec 4, 2024

jerstlouis commented Dec 4, 2024 •

edited

Loading

KathiSchleidt commented Dec 4, 2024

jerstlouis commented Dec 6, 2024

KathiSchleidt commented Dec 9, 2024

Fields for schema #173

Fields for schema #173

Comments

jerstlouis commented Sep 6, 2023 • edited Loading

jerstlouis commented Feb 13, 2024 • edited Loading

jerstlouis commented Feb 13, 2024

jerstlouis commented Mar 13, 2024 • edited Loading

joanma747 commented Aug 27, 2024 • edited Loading

jerstlouis commented Aug 27, 2024

joanma747 commented Oct 1, 2024 • edited Loading

joanma747 commented Oct 1, 2024

jerstlouis commented Dec 4, 2024 • edited Loading

KathiSchleidt commented Dec 4, 2024

jerstlouis commented Dec 4, 2024 • edited Loading

KathiSchleidt commented Dec 4, 2024

jerstlouis commented Dec 6, 2024

KathiSchleidt commented Dec 9, 2024

jerstlouis commented Sep 6, 2023 •

edited

Loading

jerstlouis commented Feb 13, 2024 •

edited

Loading

jerstlouis commented Mar 13, 2024 •

edited

Loading

joanma747 commented Aug 27, 2024 •

edited

Loading

joanma747 commented Oct 1, 2024 •

edited

Loading

jerstlouis commented Dec 4, 2024 •

edited

Loading

jerstlouis commented Dec 4, 2024 •

edited

Loading