ogcapi-features
ogcapi-features copied to clipboard
opengeospatial
Fast access to feature count of a collection
There are some clients which could be made much faster if the return of the /collections/{collectionname} endpoint included the feature count, probably as an optional element. Like QGIS currently using the OGR WFS3 driver, and QGIS displays the list of all collections with their feature count, which causes currently at least an extra ?resultType=hits request to be issued.
Agreed, this is helpful for clients. Implementations are free to add this information and it is a good idea to do so, if it is easy for them to determine this information - even if it is not specified in the core conformance class.
Earlier on it was decided to keep resultType=hits (or a similar capability) outside of the core and to add this in a separate conformance class. See #22 and also #253. The requested capability would probably belong to the same extension.
What's the status of the 'simplified extension template' we discussed on STAC/WFS call? This seems like a good one to run through that process, so we can have something other than a ticket to point to.
What's the status of the 'simplified extension template' we discussed on STAC/WFS call?
@cmheazel presented a proposal for the template and the associated process in the SWG meeting yesterday (https://github.com/opengeospatial/ogcapi-features/tree/Proposals/proposals). It is clear that this needs an update as it currently is written with OpenAPI extensions in mind and it does not cover all kinds of OGC API extensions. We will test it for two proposals (filter/query based on CQL and simple transactions) and improve process and template based on the experience. Please feel free to have a go, too.
Awesome! If I find time I'll give it a go on something small like this. Thanks!
Notice this is implemented in MapServer with both numberMatched & numberReturned - https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/countries/items?f=html
Regarding the original request to add feature count information to the Collection resource:
In ldproxy we have added an itemCount property to the Collection resource. Example: https://demo.ldproxy.net/daraa/collections?f=json.
Have others added something similar? Would it be useful to add an optional property in a future version 1.1?
I think a Collection property would belong to Core and a new parameter (resultType=hits or hitsOnly=true) should be in an extension.
I've used HEAD /collections/{collectionId/items (including any filtering you throw at it) to trigger the "resultType=hits" code path returning numberMatched in OGC-NumberMatched header. The header and numberMatched are omitted when GETting the response as it's somewhat expensive to calculate and not necessary / useful for pagination (the default setting for pagination in the implementation is token based with sorting, not offset based). The logic is that when client uses HEAD they really want the metadata of the response (including the feature count) and not the data.
And ldproxy supports numberMatched as well :-). But pygeoapi and Crunchy Data pg_featureserv do not.
The most useful IMHO is knowing the feature count in an items request, preferably resultType=hits or even numberMatched with like limit=1 and only one properties. Total number in Collection is then automatically also available. The reason why a feature count in a query is useful is for all kinds of clients. Most notably clients like Leaflet and OpenLayers that may do a form of 'Marker Clustering' when zoomed out to e.g. show a number in bboxes. And maybe even QGIS who seems to be struggling as well with the OGC API Features client (at least in 3.26.3-BA when interacting with pg_featureserv).