WFS GetPropertyValue equivalent in OGC API Features

[maxcollombin]

Is there any plan to have an equivalent to the GetPropertyValue operation in the WFS standard? This could allow attributes to be selected at:

• https://[...]/collections/{collectId}/items/properties={property1},{property2}?f=json
• https://[...]/collections/{collectId}/items/properties={property1},{property2}/{featureId}?f=json

It would also be interesting to have the possibility to get a list of unique values of (maybe with exceptions or limits) these properties but maybe this is planned in Part 3?

[cportele]

Not exactly the same a GetPropertyValue from WFS, but selecting only a subset of the properties is planned with the part 'Property Selection', currently a proposal.

Example (GeoJSON, two properties, no geometry):

https://demo.ldproxy.net/strassen/collections/unfaelle/items?f=json&skipGeometry=true&properties=unfzeit,unfart

Same as CSV:

https://demo.ldproxy.net/strassen/collections/unfaelle/items?f=csv&skipGeometry=true&properties=unfzeit,unfart

If the API supports schemas, then the value range can be determined from the schema (but this will often be the allowed values, not necessarily the existing values).

Example:

https://demo.ldproxy.net/strassen/collections/unfaelle/schema

Note that this API implements the new Schema approach discussed in recent weeks (#740 (comment)).

Part 3 specifies the queryables and that schema should also declare the value range of the queryable properties:

https://demo.ldproxy.net/strassen/collections/unfaelle/queryables?f=json

Does this help?

[pvretano]

Actually I interpreted this question a little differently ... my server can, instead of items, request properties so I can do something like this:

https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/AgricultureSrf/properties/UFI

and get an array of values from each features in the collection for the requested property ... UFI in this case. I can also append a feature ID and get the value for the specific, requested feature:

https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/zaatari/collections/AgricultureSrf/properties/UFI/CWFID.AGRICULTURESRF.0.1

This is a little differnt then the property selection extension. The property selection extension generates a "feature" but only containing the requested properties. However, you still get a feature/ featureCollection in the response. What I implemented simply returns the request property values with as little infrastructure around them as possible. It's a subtle difference I guess.

[cportele]

I think you are correct. The properties={property1},{property2} looked like the Property Selection extension with a query parameter, but it is meant as a path parameter. This would be yet another extension - and I guess it would be reasonable to restrict it to a single property like in your examples.

That said, the Property Selection extension is not that much different (in particular in encodings like CSV) and would also support multiple properties.

[maxcollombin]

Thank you for your answers, which are both useful and relevant.
@pvretano's answer is actually closer to my question, which I had also imagined in relation with Part 3. For example, we could use an item's property of an {collectionId} as part of a CQL expression for Comparison or a Spatial predicates if the selected property is a geometry.

To illustrate this, we'd have something like:

https://data.example2.org/collections/{collectId}/items?filter=CROSSES(geometry,(https://data.example1.org/collections/{collectId}/items/properties=geometry/{featureId}?f=json))&f=json

However, I'm not sure this is relevant and for the CQL spatial predicate, the geometry of the data.example1.org server should be returned in WKT format.