Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can a top-level search using the /search resource search for anything in the resource tree? #832

Open
pvretano opened this issue May 12, 2023 · 3 comments

Comments

@pvretano
Copy link
Contributor

The purpose of this issue is just to stimulate discussion on the possibility of the /search resource being used to search all OGC API resources not just collection items (e.g. features, records). So you could run a full text top-level search (i.e. q=) and get back matching records, features, collection objects, styles, etc...

Just thinking out loud in OGC API Records.

@cportele
Copy link
Member

In the current proposal, GET /search returns the list of stored queries and GET /search?q=foo could return the stored queries that match a keyword search for "foo".

Even if we change that: What would be the response media type and content? Records/features, collection objects, stylesheets are all different resource types with different media types. I guess, the idea is to simply return a list of links to the matching resources?

@m-mohr
Copy link
Contributor

m-mohr commented May 22, 2023

In STAC, /search returns a FeatureCollection. This means all search results must be GeoJSON Featues, which in STAC only applies to Items. If we want to not have conflicts between the OGC API and STAC specifications, we should check how we can solve this (e.g. via media types, which seems preferrable) or whether we can agree on a more general structure that is not based on GeoJSON FeatureCollections (would be breaking in STAC).

m-mohr added a commit to radiantearth/stac-browser that referenced this issue May 22, 2023
@cportele
Copy link
Member

Meeting 2023-05-22: Yes, we want to avoid incompatibility with STAC. This should be discussed in a separate issue, @pvretano will open one. Probably we should split /search into two resources, one for stored queries and one for the ad-hoc queries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

3 participants