OGC API - Features queryables/returnables: Implement support for describing object attributes

[jerstlouis]

Problem description
It is not currently possible to describe feature properties which are objects in queryables.
There is also no support currently for returnables schemas (specification work for this still in progress).

Solution
One possibility would be to support the current proposal of /collections/{collectionId}/schemas/feature (rel: http://www.opengis.net/def/rel/ogc/0.0/schema-item) for feature item returnable schemas, where "type" : "object" can be used to describe object properties.

Queryables could also possibly support object types, though it is not clear what that would mean for CQL2 filter requests.

Additional context
This issue was raised in the context of Testbed 18 - Advanced SWIM filtering, interacting with the Skymantics Aviation service.
In https://aviationapi.skymantics.com/faa/collections/faa_flight_plans , several attributes present in the features are not described anywhere in the available schemas (because object properties are not supported) requiring client support to discover new properties on the fly.

These collections from ldproxy and GNOSIS Map Server demonstrate an implementation of the returnable schema capabilities:

https://t18.ldproxy.net/d100_fns/collections/notam
https://t18.ldproxy.net/d100_fns/collections/notam/schemas/feature?f=json

https://maps.gnosis.earth/ogcapi/collections/swim:d100_notam
https://maps.gnosis.earth/ogcapi/collections/swim:d100_notam/schemas/feature?f=json

[tomkralidis]

pygeoapi feature/record backend providers support a get_schema function, which does exactly this. However, there is no pygeoapi endpoint implemented to expose this (note that it is used by downstream applications).

What is the state of .../schemas/collection and .../schemas/feature from a specification maturity perspective? Happy to implement if the endpoints and link relations are relatively stable.

[jerstlouis]

Regarding the maturity of ../schemas/feature and ../schemas/collection, it would be defined by an extension for schemas, which seems to still be at a proposal stage:

https://github.com/opengeospatial/ogcapi-features/tree/master/proposals/schemas

and the text there dates from March 2021 and does not seem to mention the latest link relations and (recommended?) paths that were used in Testbed 17 and 18 tasks.

However, there are at least 2 consistent implementations (ldproxy and GNOSIS Map Server), CubeWERX/MariaDB might be another. pygeoapi would make it 3 or 4, which in itself could help moving this forward :)

There is an open question about whether the schema is specifically for GeoJSON vaidation (in which case it will have additional fields like the properties present in GeoJSON), vs. a generic schema that could be adapted to multiple encodings. From our client's perspective, we really only care about the latter. An implementation wishing to run a validator could always generate the validation schema automatically with the additional fields for validation targeting a particular encoding.

Regarding schemas, there is also the propertiesSchema in 2D Tile Matrix Set & Tileset Metadata which provides this mechanism (tileset metadata at e.g., ../tiles/{tileMatrixSetId}), and can be used to display properties of both coverage (the range type fields) and vector tiles.
In coverage we have a separate ../coverage/rangetype resource.
EDR includes these as parameter names directly in the collection response (that could easily be too much data, especially if it is required at the /collections level for multiple collections).
Ideally, it would be nice if we had a single consistent Common approach to describe the properties / range type fields / schemas across all OGC API Standards.

cc @cportele @pvretano in case they could please provide additional details on the maturity of the Schemas status.
cc @skyNacho

[github-actions]

As per RFC4, this Issue has been inactive for 90 days. In order to manage maintenance burden, it will be automatically closed in 7 days.

[github-actions]

As per RFC4, this Issue has been closed due to there being no activity for more than 90 days.