Host upstream catalog's schemas in a dedicated page

[LionelZoubritzky-IGN]

@mborne The schemas stored by gpf-schema-store and returned by the gpf_describe_type tool are currently missing the compulsory $id field. Should we add a new endpoint to the proxy to return these schemas, so we can include the URL of the proxy as the $id?

We currently have .../api/v1/proxy/... for the GeoJSON, so I would imagine something like .../api/v1/schemas/BDTOPO_V3/aerodrome.json for example. We could also obfuscate like we do for the GeoJSON but I don't see the point here.

[mborne]

Hello @LionelZoubritzky-IGN , not fan of this approach as the proxy has no official URL and is not supposed to live for a long time.

In order to define an "id" for the schema, I tkink that it would be better either to :

• Publish gpf-schema-store as a github pages (*) and define "id": "https://ignfab.github.io/gpf-schema-store/catalog/BDTOPO_V3/batiment.json"
• Use the futur URL (something like https://data.geopf.fr/ogcapi/features/collections/BDTOPO_V3:batiment/schema)

(*) might be the first step before : ignfab/gpf-schema-store#45

[esgn]

Quick note about this as I was reviewing this point :

• With the introduction of OGC API Features schemas as the default format of gpf-schema-store the LLM has lost the link between a schema and its collection id.
• The OGC API Features Schemas spec offers only one way to establish a link between a schema and a collection via $id where $id = {apiUri}/collections/{collectionId}/schema ... hypermedia here we go.
• What is odd is that the standard offers a x-ogc-collectionId but only to define the target collection of a property

[esgn]

opengeospatial/ogcapi-features#1061

[LionelZoubritzky-IGN]

Closed by ignfab/gpf-schema-store#78