Part 3 - Cross-collection queries
Opened this issue · 5 comments
The Part 3 draft spec section Cross-collection queries states
A server that implements this extension and also supports queries across multiple collections SHALL only allow properties from the global list of queryables to be referenced in a filter expression.
This is followed by an example cross-collection query
http://www.someserver.com/ogcapi/search?
collections=collection1,collection3&
filter-lang=cql-text&
filter=prop1=10 AND prop2>45
The definition of the global list of queryables states the list "SHALL be valid for all collections", which I interpret to mean the common property set that exists across all collections in the implementation. Cross-collection filtering is potentially a very useful feature but I believe the spec is overly restrictive.
In an implementation with two or more collections there could be zero common properties, and one might assume that as an implementation supports more collections the number of common properties could tend towards zero, meaning that this feature's value might be inversely proportional to the number of collections.
I would like to propose that instead of only supporting global queryables in a cross-collection filter the spec instead permits any queryables that exist in all collections identified in the request. An API client can query each collection's queryables individually and use this information to build a list of properties common to those collections. The API implementation can return a 400 response if provided queryables are not common across the identified collections, rather than returning 400 if the provided queryables are not global.
I tend to agree. While the constraint simplifies implementation, it prohibits some meaningful cross-collection queries.
At a minimum we shouldn't add such a hard constraint already in Part 3 where no cross-collection queries are specified. Cross-collection queries will be supported by https://github.com/opengeospatial/ogcapi-features/tree/master/proposals/search and we should specify the cross-collections requirements there.
Another possibility is to allow a collections parameter on /queryables such that you could call it with /queryables?colections=collection1,collection3 and it would return the intersection of having called /collections/collection1/queryables and /collections/collection3/queryables. When collections does not exist as a parameter, the semantics would be the same as if it were called with all the collections specified.
This would be really useful. I can imagine this call could take a while to build a response the first time (depending on how many collections you have) but caching would take care of that.
Meeting 2021-06-07: This will be moved to the future Search/Query part as a result of #544.
My proposal is #801 is a joinCollections= query parameter that makes properties (and geometries) from multiple collections (including potentially mixed feature collections / coverages). joinCollections instead of collections to distinguish between collections included in the response (as in the Maps and Tiles collections query parameter defining what is to be rendered on the map or included in the vector tiles) vs. collections making queryables available for the query.