Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/radiantearth/stac-api-spec/issues/182 below:

Dynamic queryables difficult for item-search · Issue #182 · radiantearth/stac-api-spec · GitHub

One feature we are really interested in is the ability to request from the server the possible queryables and their accepted values.

As defined, there are two routes:

• /queryables - The global intersect of all collection queryables
• `/collections/{collection_id}/queryables - Collection specific queryables

As noted in the documentation, this falls short in providing a useful interface where an API presents diverse content.

Issues ogcapi-582 ogcapi-576 go some way in addressing this by requesting wildcard schema definitions and /queryables?collections=collection1,collection2 but I feel this still leaves limitations. Some discussed in the issues themselves.

1. Wildcard definitions have issues because you lose the information about possible queryable properties and values. We are likely to end up with millions of items and 100s if not 1000s of collections. It is unreasonable to expect a user to search these to find some possible attributes they might wish to search on.
2. adding the ?collections parameter requires the client to know the collections they are interested in up-front. One of the benefits of item-search is cross-collection search.

I wonder whether a more useful approach would be to allow the same query parameters as /search on /queryables.
The implementation can then search for the list of results that match and provide the intersect of queryables to the user for further refinement.

e.g.

Return the list of items which match the filter expression
/search?filter=sentinel:data_coverage > 50 OR eo:cloud_cover < 10

Return the queryables available for the results which match the current filter expression
/queryables?filter=sentinel:data_coverage > 50 OR eo:cloud_cover < 10

The /queryables?collections=collection1,collection2 approach requires the API to return a list of relevant collections to be useful IMO. Perhaps allow the context extension to return an array of collections in the response which are relevant for the current search.

1. Accept the /search query parameters on the /queryables endpoint to dynamically build the intersect
2. Return collection ids in context response, this can then be used via proposed /queryables?collections=...,

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4