Describing features properties

[NuriaJulia]

I'm trying to implement a transactional OAPI features client. I need to know the properties of the feature (or collection) but in the new standard the DescribeFeature request has disappeared.
How can I get this information? Is this '.../collections/{collectionId}/schema' an standard request '?

[ghobona]

See example from @pvretano . You can also return JSON Schema instead of XSD.

[jeffharrison]

Many thanks to @NuriaJulia for this question and to @pvretano for the example.

@ghobona I believe we heard yesterday that this capability was not yet part of the spec. If that's correct, then most likely it should be...

Thanks and Regards,
Jeff

[ghobona]

Today (Sprint Day 2) we also discussed an approach whereby the schema for feature collections is included in the API Definition (in JSON or YAML). In this approach we would use JSON Schema to constrain the JSON keys representing feature properties.

The sprint participants acknowledged that the approach could work but also cautioned that it could lead to very large API Definition documents.

[cportele]

Features API SWG meeting 2020-10-12: Do we need to add a schema endpoint requirements class (requirement for a describedBy link relation for every feature collection) in Part 4? We also need to make sure that it works for schema-oriented implementations (Oracle/Postgresql/etc as backend) and schema-less implementations (MongoDB/etc as backend).

[cportele]

Note that this is to some extent related to #424 (comment)

[cportele]

Meeting 2021-01-18: This will be addressed as part of the proposed schema activity. @cportele will draft a proposal that would go into that new part, but could also (temporarily) be copied into part 4 (to make it complete) until the schema part is published. This is similar to the queryables schema from part 3.

[cportele]

Addressed in PR #504. Two items for discussion:

• Currently this references a schema resource (at /collections/{collectionId}/schema). There is a query parameter type as a qualifier about the type of schema to return. The default probably should be the response schema in case of a read-access to the feature (e.g., type=read) and for the create/replace/update operations, which all can have a somewhat different schema, it would be type=create, type=replace and type=update. For the queryables from part 3 we should then move this from /collections/{collectionId}/queryables to /collections/{collectionId}/schema?type=queryables.
• Currently every server would have to provide the schemas, but this is probably too strong? Alternatives are changing it into recommendations or another requirements class for schemas.

[cportele]

Meeting 2021-02-01: The general approach with the schema resource looks good. However, schema support should be optional; change to a recommendation and provide context (@cportele).