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

Minimum value for "limit" too restrictive (0 should be allowed) #251

Closed
ycespb opened this issue Jul 31, 2019 · 4 comments · Fixed by #254
Closed

Minimum value for "limit" too restrictive (0 should be allowed) #251

ycespb opened this issue Jul 31, 2019 · 4 comments · Fixed by #254
Labels
OGC API: Features Issue related to feature resources (see #190) Part 1: Core Issue related to Part 1 - Core

Comments

@ycespb
Copy link

ycespb commented Jul 31, 2019

The requirement (20) /req/core/fc-limit-definition combined with permission 5 in OGC 17-069r2 do not allow to make queries with "limit=0" to allow a client to count results without actually retrieving results (This is currently used by clients/servers implementing EO OpenSearch in a distributed context and related CEOS Best Practices). It requires that at least one result is requested/returned. Propose to relax this and either allow 0 or state in permission 5 that the value for "minimum" is also an example.

@cportele cportele added Part 1: Core Issue related to Part 1 - Core OGC API: Features Issue related to feature resources (see #190) labels Jul 31, 2019
@cportele
Copy link
Member

I see, you are using limit=0 to mimic the resultType=hits behavior from WFS 2.0. Originally this was part of the Core, but we moved it out (#22) early in the process.

Allowing limit=0 to achieve this could be an option. It wouldn't make it a requirement to support such a capability (it would be up to the implementing software) and at the same time we wouldn't need an extension to support the capability.

@cportele cportele added this to the Part 1, Version 1.0.0 milestone Jul 31, 2019
@pvretano
Copy link
Contributor

This bring up an interesting point related to HEAD. What about defining a set of OGC headers that return information similar to what we used to be able to get with resultType=hits?
The idea is, someone does a HEAD request and gets back something like an OGC-NumberMatched header or something like that... I would prefer this to limit=0. In my mind, limit=0 simply returns an empty container whose content is dependent on the output format and may or may not contain information similar to resultType=hits.

@cportele
Copy link
Member

Yes, using HEAD would be cleaner, but it clearly would be an extension. limit=0 is somewhat of a hack, but not a bad one.

Maybe one way to do it would be to just allow that servers can state other "minimum" values for limit than 1 (including values>1, maybe someone has such a requirement, too), but do not mention/discuss limit=0. And for the proper approach work on a HEAD extension?

@cportele
Copy link
Member

SWG call 2019-08-12: Clemens to create a pull request (see previous comment). Close this issue and open a new one to work on a HEAD extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OGC API: Features Issue related to feature resources (see #190) Part 1: Core Issue related to Part 1 - Core
Projects
Development

Successfully merging a pull request may close this issue.

3 participants