-
Notifications
You must be signed in to change notification settings - Fork 84
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
Global queryables conflict with STAC Item Search #830
Comments
Can we clarify the issue first? Part 3 defines the Queryables resource in general (there is no fixed path) and specify the Queryables at The proposed Search Part is expected to define (among other resources and operations) a Search resource at How is that different from the organization of the queryables in STAC? I also looked at STAC Item Search and it currently does not mention queryables? Note that there is a difference and that is the POST payload of |
Sure, thanks @cportele .
That's what STAC does, indeed. The global queryables endpoint is defined in the Filter extension, not in Item Search:
Aha, the proposal is for /search. Good, I think I misunderstood this. Anyway, the issue that I'm facing right now is that we also implement CQL-based search for /collections. I thought that's also captured here, but may it's not or I did not find it. For /collections we also need a separate list of queryables. I don't think the collection search issue is exclusive to STAC; Records also seem to have somethin similar under (I think) the term "local resource catalog" or so. If the answer is "yes" for both questions, I think we can quickly close here :-) |
Can't /collections/queryables be used for the list of collection search queryables ? This does not create a conflict with /queryables, nor with /collections/{id}/queryables. Our implementation at emc.spacebel.be is using this URL which can be found via the rel=".../queryables" as well in the /collections response. |
It may conflict with a potential collection route, so I'd not recommend that by default, but individual implementations could go for that if we leave the path open. A better recommendation might be |
As far as I am concerned: Yes.
I think I would agree with a flexible path since there is no "natural" path. |
Thanks, that works for me! |
This discussion sounds like the Local Resources Catalogue conformance class is OGC API Records. That conformance class specifies how to extend existing endpoints like OGC API Records indicates that the queryables endpoint for local resources endpoints (like As an aside (and this is not part of any specification, its just something I'm experimenting with), my implementation of OGC APIs provides a top-level
At any endpoint in this tree you get back a JSON-schema that lists the queryables for searching the corresponding endpoint in the OGC API resource tree.
An empty response means that you can't search the corresponding endpoint in the OGC API resource tree. The link to queryables in the various links section simply point to these endpoints. So, the link in the Anyway, just something I've been playing with in relations to queryables. |
I like the idea of making all queryables resources (also) available under |
@cportele yeah, that is what I am experimenting with ... that is making all queryables available under the About queryables across all collections, I was thinking about that too and yes, I think we would put those under The basic idea what I have been toying with is that whatever the path is for the searchable resource, if you want the queryables, you just put a Not sure that notion completely works yet but that is what I have been playing with. |
Yes, this originates from the Local Resources Catalogue, which we used as a baseline for STAC Collection Search. The proposal makes sense to me and avoids potential conflicts. Is this meant to be a guideline/recommdation or a requirement? I would prefer it as recommendation, I think. You need to put links anyway, so it doesn't really matter where the endpoints actually are. In STAC we currently use This structure would also be applied to something like /sortables, right? |
@m-mohr yes, |
Features Part 3 will use that path ( The approach with The same resource would then be available at |
Meeting 2024-08-26: The SWG members will review this again and discuss in the next meeting(s). There are also the queryables for the local resources catalog that we need to consider in this context. |
STAC has global Item search at /search. The Filter/CQL support for global Item search requires a /queryables endpoint.
Unfortunately, the link may conflict with https://github.com/opengeospatial/ogcapi-features/blob/master/proposals/search/global-list-of-queryables.adoc which also exposes a /queryables endpoint for /collections.
If I try to implement queryables for /search and /collections via links, I can't distinguish which link applies to /search and which applies to /collections and the endpoint names conflict as well. I assume that both links would be part of the landing page right now.
How can we solve this conflict? Can we enforce that queryables in the landing page applies to /search, queryables in /collections is for /collections? That would solve the link conflict. And then we may just need to be more flexible with the endpoint names and allow more than just /queryables?
cc @philvarner @ycespb
The text was updated successfully, but these errors were encountered: