Dynamically fetching features from more than one collection at a time

[pvretano]

This issues was raised in the OGC Vector Tiles pilot (VTPILOT).
Right now, WFS 3.0 only allows queries on a single feature collection at a time and does not provide a mechanism for fetching features from multiple collections in a single request (like the previous version of WFS allowed). Thus, in the context of the VTPILOT, one cannot request a Mapbox vector tile into which features of multiple types have been rendered.
One approach that has been mentioned ... since WFS 3.0 is schema-less, a server can offer a collection that is the aggregate of any number of feature types. The example given in the context of the VTPILOT was that a server could offer a "daraa" collection that is the combination of the collections currently offered individually (TRANSGROUNDCRV, AGRICULTURESRF, HYDROGRAPHYCRV, MLITARYSRF, etc.). The problem with this approach is that it is not dynamic. There is no way for a provider to anticipate which features types a user might want to fetch simultaneously.
Some work was done in the TB14 next gen thread to investigate this issues.

Approach 1:
Have a /items path that is the virtual aggregate of all the other collections that the server offers and then have a "collectionIds" parameter to allow the user to select which features types should be included in the response (e.g. .../items?f=json&collectionIds=TRANSGROUNDPNT,TRANSGROUNDCRV,TRANSGROUNDSRF&...)

Approach 2:
Support the POST method on the /collections path to allow new collections to be created by aggregating existing collections. So, using the VTPILOT collections as an example, one could do the following:

POST /collections
{
"name": "daraa",
"title": "Daraa Transportation Infrastructure",
"description": "An aggregate collection of the transportation features in the Daraa data set.",
"links": [
{ "href": "http://data.example.org/collections/daraa/items",
"rel": "item", "type": "application/geo+json",
"title": "Daraa Transporation Infrastructure" },
{ "href": "http://data.example.org/collections/daraa/items",
"rel": "item", "type": "application/gml+xml; version=3.2; profile=http://www.opengis.net/def/profile/ogc/2.0/gml-sf0",
"title": "Daraa Transportation Infrastucture" }
],
"collections": [TRANSGROUNDPNT,TRANSGROUNDCRV,TRANSGROUNDSRF]
}

The POST body is basically the same as the schema for the metadata about a feature collection with the addition of the "collections" array which lists existing collection names to be "aggregated" under this new collection. Once created, the new "daraa" collection can be queried like any other collection. DELETE can be used to drop it. The OPTIONS method can be used to figure out if the POST and DELETE methods are supported on the /collection resource.
Hmm, I wonder if this can be considered a dynamic "hierarchy" or "theme" mechanism? ... since I suppose I could create a another collection named "Syria" that aggregates all the Syrian data, etc.

[cholmes]

I'd favor option 1, the second seems a bit too complicated. Though would be great to see both tried in implementations.

Is there a lightweight way to specify extensions? Like it'd be cool to see OpenAPI fragments for both of these options, and encourage implementations. I worry a bit about the /extensions/ folder being a bit too 'official', as well as discussion like this in the 'main' issue tracker contributing to that. Has there been any thought about making a separate repository for WFS community / extensions, where people can explore ideas like these. It'd be good to encourage more of a space where people can try out ideas like these, including actual implementations. Or an alternative would be to have a way to specify extension maturity, so the repo can welcome lots of extensions, but have a way to communicate that they aren't 'official'. That's what we just did in STAC, see https://github.com/radiantearth/stac-spec/tree/dev/extensions#extension-maturity

Note that in STAC (https://github.com/radiantearth/stac-spec/) having this functionality could eliminate the need for our /search/ endpoint - the main reason we needed it instead of just using WFS3 was that WFS3 doesn't have cross-collection search. Option 2 could be quite compatible with STAC, as we could just say that collection/stac is an aggregate collection of every collection that complies with SpatioTemporal Item schema.

Also, the previous thought from the WFS3 group I think was that a /search/ endpoint is where one would do queries like this, am curious if that is still an option.

[pvretano]

@cholmes I don't think there is a problem tracking enhancements/extensions here as long as issues are properly tagged.

As for the approaches I have described, I have an implementation of approach 1 and will be describing it in the TB14 ER (with OpenAPI fragments). If time permits, I will do approach 2 as well.
Query endpoints like /search are meant for more complicated queries -- @cportele has done some work on that in TB14.

For this specific issue, I think the requirement is for something a bit more light-weight than a query endpoint like /search. I guess that tends to support approach 1. Here is an examples for approach 1 (ignore the parentheses - bug): http://www.pvretano.com/cubewerx/cubeserv/default/wfs/3.0.0/foundation/collections/items?f=json&collectionIds=(aerofacp_1m),(inwatera_1m)&bbox=41.199844,-83.859060,41.618364,-82.619314