search

opengeospatial / ogcapi-common

OGC API - Common provides those elements shared by most or all of the OGC API standards to ensure consistency across the family.
https://ogcapi.ogc.org/common
Other
48 stars 14 forks source link

"Simple Query" requirements class #314

Open cportele opened 2 years ago

cportele commented 2 years ago

The current draft of Common Part 2 is not consistent with my understanding of Common: a collection of reusable API building blocks that have been tested and proven in the context of an OGC API Standard and that are deemed reusable in other OGC API Standards.

The "Simple Query" requirements class adds new requirements that are not part of any approved OGC API standard (e.g., 'bbox' or 'limit' on /collections) and as such have not gone through the full consensus process.

The second part of Policy Directive 51 seems to agree and implies that new parts of Common should be created by extracting requirements from an approved OGC API standard.

I suggest to remove the requirements class from this release. It could be added in a future revision, after there is an approved OGC API Standard that includes the requirements.

jerstlouis commented 1 year ago

At the OGC API - Common 127th Members Meeting in Singapore this week I suggested that we rename this requirement class to "Filtered Collections", and that we define it based on the "Local resource catalog" concept as currently specified in OGC API - Records, targeted to the /collections and /collections/{collectionId} resources.

The Local resource catalog concept may be more of a requirement module / template / building block, than an actual full-fledged conforrmance class. As such it could be a building block that Common - Part 2 "Filtered Collections" applies to /collections, Coverages - Part 1 "Scenes" applies to /collections/{collectionId}/scenes, OGC API - Records "Records API" (and STAC API?) applies to /collections/{collectionId}/items, OGC API - Processes - Part 1 "Filtered Processes" applies to /processes, etc.

We recently removed the related content from OGC API - Coverages (which was there for the sole purpose of Policy Directive 51, but was really out of place, since it has nothing to do with coverages specifically), and the dependency on Part 2 would allow to automatically inherit this optional /collections capability from the Common - Part 2 standard, if it can have this "Filtered Collections" aka Simple Query, where it really belongs, since this is what defines the /collections resource path. Other specs like 3D GeoVolumes also had similar &bbox= filtering for /collections which would also be handled by this.

cc. @pvretano @joanma747

jerstlouis commented 8 months ago

There is an on-going discussion in https://github.com/opengeospatial/ogcapi-records/issues/300 about trying to figure out if the Local Resource Catalog deployment type of OGC API - Records could share a single Core requirement class with the other two deployment types (Crawlable Catalog and Searchable Catalog).

In general, we need to figure out whether / how we should reference Records from this "Searchable Collections" requirement class.

jerstlouis commented 2 months ago

We have a draft of the updated and renamed "Searchable Collections" requirement class at https://docs.ogc.org/DRAFTS/20-024.html#rc-searchable-collections .

The one thing remaining is to complete the requirement for the belowScaleDenominator parameter.

I am also realizing that perhaps the bulk of the sections on OGC API - Records compliance in "Searchable Collections", "Filterable Collections" and "Sortable Collections", could be moved to the Collections requirement class, since the Core Records conformance classes could still be conformed to without implementing any of those things.

cc. @joanma747

jerstlouis commented 3 weeks ago

We did add the below-sd parameter in a recent weekly telco.

At the member meeting, there was comment regarding whether there should also be a temporal resolution equivalent.