-
Notifications
You must be signed in to change notification settings - Fork 87
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
Proposal: Remove 'resultType' from core and put in an extension #22
Comments
Yeah, I think I agree with this too. We could probably think about doing something with HEAD to get this kinds of metadata from a server. |
Yes, fully agree that the capability to determine the total number of hits is extremely useful - it was one of my favorite additions. Just want to be sure it's not required, and that it could easily be implemented in a microservice style architecture. I think there's potential for standardization of even more types of aggregations - like bucketing the stats to drive charts, or even spatial aggregations - return counts by regular geographies, for when a browser can't display all the data. But should be additional end points. |
There seems to be consensus on this one. I will create a pull request... |
From teleconference 12-FEB-2018:
|
(happy to create a PR for the spec changes of this and other issues I'll put in, but I've delayed on getting this feedback out, so figured I'd post now instead of continuing to wait).
Though being able to ask for 'hits' instead of actual results likely seems pretty trivial to implement, it is an additional overhead, and can be more of a pain with a backend like elasticsearch than a standard rdbms. Especially when you get to hundreds of millions of features. At Planet in our data API we have a dedicated 'stats' endpoint that returns the equivalent of 'hits' (see full api spec and search for stats). Ours also can return time bucketed data, which drives nice looking graphs. One could see an advanced 'stats' endpoint being used for crossfilter style interactive filtering.
So a good microservices architecture I believe would have 'hits' be its own endpoint that takes the same 'query' as the 'results' endpoint, so it could be backed by a cluster dedicated and optimized for aggregations. Hits as an extension would allow services to include it if it's easy to implement, but not require it for minimal implementations.
For the SpatioTemporal Asset Catalog spec we started with a draft WFS 3.0 swagger spec, but removed the result type stuff, see the swagger spec
The text was updated successfully, but these errors were encountered: