Closed m-mohr closed 9 months ago
Hmm ... the API for Records is the Features API with extensions (i.e. adding the q
, type
, externaIds
, etc. parameters). The intent is that in the /conformance
response, you would include all the conformance URIs from Features that the server implements and then also include the conformance URIs listed in Req 8 to indicate that the server also implements the extensions defined in Records. That is the intent anway ...
Thanks, a clarification would be helpful, I think.
06-JUL-2023: @pvretano will make sure that it is clear in the text of the specification that the /conformance
response should include all the conformance URIs from features that the server implements (i.e. core, filtering, cql2, etc.) plus any additional conformance classes from Records (i.e. core, searchable catalogue, etc.).
STAC API extends OGC API - Features in a way that
http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core
must also be provided as conformance class for example.In OGC API - Records, I also find a lot of references back to OGC API - Features. It says in a couple of places that it extends things from Features. This leaves the question, whether an Records implementation also has to provide the Features conformance classes, e.g.
http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core
? I assume not, but I think you want to clarify that.Req. 8 talks about it and references back to Features:
This could be read as if Features conformance classes should also be added. I think the difference here is schema vs. content. What you wanted to say in req. 8 is that it follows the schema of Features, but doesn't extend the actual required content (conformance classes) from Features. It just takes over the same schematical description of the /conformance endpoint without any of their actual conformance classes.