opengeospatial
Dynamically fetching features from multiple collections in a single request.
One thing that came up recently was a question about how to dynamically fetch features from multiple feature types in a single request similar to the capability supported by WFS 2.X. A WFS 3.0 provider can, of course, organize their collections any way they like but cannot typically anticipate which combinations of feature type a client might want. My thinking was to define a /collection/items path (or a /items path might be better to avoid name collisions) that has all the usual parameters and a "collectionIds" parameter to accept a list of collection ids to query. Of course the filtering would need to be carefully handled. Only properties (if any) common to all feature types could be filtered. This could also be handled in a "complex query" extension but this is not really a complex query. It is more of an aggregation query ... a convenience I guess to reduce the number of calls a client needs to make to the server. Comments?
From the two options I would prefer /items over /collections/items.
One problem with /items is that you do not have any metadata like the CRSs or the spatial extent that you can query. Would a predefined "virtual" collection (we would need to reserve the name in the Core) work? Something like /collections/all/items. I have not really thought this through, just an idea.
I prefer /collection/items for exactly the reason you give (i.e. the metadata). However, a reserved collection name such as "all" might be a better approach.
I definitely would prefer virtual collections that require some description of what they can handle to an endpoint that takes collectionIds parameter.
I do think an /all endpoint could make sense to add a collectionIds parameter.
But in general lots of links are good, that describe things in different ways. So enable more endpoints that can aggregate other collections. And then describe in each the capabilities in each.
So I can like have /collections/spatiotemporal/ or /collections/satellite-imagery/ - and each could report the collectionIds that it queries, as well as the fields / schema validation of the items it contains.
Perhaps we get to a set of recommendations on how to make a 'grouping'. I could see /collections/landsat8 also linking to the 2 collections above to indicate that it is a member of those more widely defined types.
In general I think that WFS 3.0 already supports the idea of statically predefined aggregates of collections. There are no restrictions on how collections are organized. So a WFS can offer collection A, collection B and collection C where collection C is actually an aggregate of A & B. The only deficiency is that there is no formal mechanism to explicitly advertise the fact that C is actually an aggregate of A & B. A provider would need to indicate that information in one of the descriptive text fields (e.g. description) in the metadata for collection C.
It's the dynamic, on-the-fly case that is not covered and so /collections/all with a collectionIds parameter satisfies that use case.
Cool. I think it'd be a nice little construct for how to advertise the collectionId's that a certain collection may represent. That is not just 'description', but is actually a list of those collectionId's. And then 'all' would use that same mechanism, but would list every collection id that is available.
We are thinking this would be an extension, yeah? I think it'd be a burden for many to offer full cross collection search.
I am not sure what the others think but I would not be opposed to adding a formal mechanism to the collection metadata in the core for advertising a list of aggregated collections should a service want to offer statically aggregated collections. Dynamic aggregation is, in my opinion, definitely an extension.
20-MAY-2019 Conference call: This is something for the hackathon to see the perspective of others.
Decision that this is a capability that will be specified in an extension.
In discussions with OAF and STAC participants during the sprint in Arlington we agreed that /search makes most sense for us as /items would conflict with other use cases.
Here's the PR for STAC to rename /stac/search to /search as a first attempt to align with efforts of OAF: https://github.com/radiantearth/stac-spec/pull/632
