Include numberMatched & numberReturned at Items level

[KoalaGeo]

Is your feature request related to a problem? Please describe. It really useful to know how many features are in a collection to be able to write efficient queries against the data.

Describe the solution you'd like Addition of numberMatched & numberReturned in the items response.

This would be matching the implementation already found in both MapServer & GeoServer

[justb4]

Although this feature is optional in the standard, most applications, also including LDProxy, support it, see also this long-running issue https://github.com/opengeospatial/ogcapi-features/issues/261. Could become a sort of defacto interworking feature until something, hopefully mandatory, is decided in the standard, as there are multiple alternatives, including HTTP Header response fields.

[tomkralidis]

I think this is already supported? https://demo.pygeoapi.io/master/collections/obs/items?f=json

@KoalaGeo can you provide some steps to reproduce?

[KoalaGeo]

@tomkralidis is it provider dependant?

Not present in https://ogcapi.bgs.ac.uk/collections/scanned-maps-500k/items?f=json

[justb4]

Yes it is ( provider dep.).

[tomkralidis]

Thanks @justb4. So the PostgreSQL provider needs the additional properties assuming they can be derived.

[KoalaGeo]

https://ogcapi.bgs.ac.uk/collections/scanned-maps-1m/items?resulttype=hits&f=json works so "just" need to add to the items response

[justb4]

Thanks @justb4. So the PostgreSQL provider needs the additional properties assuming they can be derived.

Think there are more, like OGR Provider, though it supports resultType=hits, making it easy to also support at items level. We need to go through all Providers, make a list and fix one-by-one. It is even a (PSC) question if pygeoapi still should support resultype=hits as it is not anymore in the standard and not supported by all Providers (e.g. not by Elastic).

[tomkralidis]

Note that resulttype=hits is supported by the ES provider. A full matrix of feature provider support specifics can be found at https://docs.pygeoapi.io/en/latest/data-publishing/ogcapi-features.html

@KoalaGeo can you add these properties to #964 (for just the PG provider for now), or better in another PR?

[justb4]

Note that resulttype=hits is supported by the ES provider. A full matrix of feature provider support specifics can be found at https://docs.pygeoapi.io/en/latest/data-publishing/ogcapi-features.html

Good to notice, did not know about this figure. But like I stated above resultType=hits, though very useful, IMHO is now a proprietary extension (since it was removed from the standard). Ok, gives pygeoapi some edge. But my focus, and hopefully for the good of community adoption, is on generic (OAPIF) clients. So far the closest is to support numberMatched, not ideal, but we can converge/agree among the various implementations until the standard is stable. Just like we did back-then for WMS with GetFeatureInfo (at least support GML), and (think I remember) three different kinds of SRS/CRS-encodings, using EPSG:code, even depending axis-orientation on that specific encoding, all for the sake of interworking like between GeoServer and OpenLayers.

My proposal: let's extend the matrix showing per-Provider support for numberMatched and numberReturned as it is even an optional feature in the standard. And PR to add these in Providers where missing.

[github-actions[bot]]

As per RFC4, this Issue has been inactive for 90 days. In order to manage maintenance burden, it will be automatically closed in 7 days.

[github-actions[bot]]

As per RFC4, this Issue has been closed due to there being no activity for more than 90 days.