Search/Queries (cross-swg): `joinCollections` common OGC API building block

[jerstlouis]

As suggested in T18-SWIM (Section 7.2.4) (though there it was called collections), it would be great to support a join capability that would work with the existing /items end-point.

This would make queryables from another collection available for filter, sortby, properties (allowing to derive new fields and also easily handling the simple OGC API - Joins use case).

Compared to the current main Search proposal, with this request there is a primary collection (akin to the left table in a SQL LEFT JOIN) for which all matching items will be returned and there is a clear featureId associated with each item returned, while the items / data (could be non-features for features/coverage data integration) from the joined collections will be matched where applicable, providing additional queryables available for CQL2 properties in filter, sortby and properties (These are also defined in Processes - Part 3: Workflows and Chaining "Input/Output field modifiers").

The collection could be local or remote if that is supported e.g.:

GET /collections/flightRoutes/items?
   joinCollections=https://weather.com/ogcapi/collections/winds&
   filter=winds.speed > 100 and s_intersects(geometry, winds.geometry) and departingAirport in (JFK, EWR, LGA)&
   sortby=-winds.speed,departingAirport&
   limit=1000

This could also work for /coverage and /map requests:

GET /collections/dem/map?joinCollections=countries&filter=Elevation > 1000 and countries.name = 'Canada'

In this case, a DEM map of Canada is returned for elevation above 1000.

GET /collections/countries/map?joinCollections=dem&filter=dem.Elevation > 1000 and name = 'Canada'

Similar request but in this case, a country map (might be simple solid fill / stroke) of Canada is returned for elevation above 1000.

NOTE: joinCollections avoids confusion with the Tiles / Maps collections parameter which selects the content to render on the map.