You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 infilter
,sortby
andproperties
(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.:
This could also work for
/coverage
and/map
requests:In this case, a DEM map of Canada is returned for elevation above 1000.
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 / Mapscollections
parameter which selects the content to render on the map.The text was updated successfully, but these errors were encountered: