propertieswith the approach that you have described and also
skipGeometry=trueto drop the geometry. sample request
Q: in short: how to best enforce (Geo)JSON-only responses from OAFeat endpoint services compliant with standard?
?f=json (I hope for) or HTTP
Accept: ... (Content Negotiation)?
Expanded: Working on GeoHealthCheck OAFeat Probe (using OWSLib
oafeat client). Interesting results from multiple OAFeat implementations on demo.geohealthcheck.org: naively thought Content Negotiation using
Accept: application/json would do, but as in metadata some service requests require other content-types like
pygeoapi happily accepts
application/json, but other implementations return 406, as e.g. for
items or OpenAPI Doc.
/searchendpoint, which is where we use POST of JSON for querying - https://stacspec.org/STAC-ext-api.html#operation/postSearchSTAC
Collection"A list of coordinate reference systems (CRS) in which geometries may be returned by the server: the first CRS is the default coordinate reference system (in the Core, the default is always WGS 84 with axis order longitude/latitude);"
crsarray but I'm not sure if that's the actual intent. Also I don't think the default CRS should even be changeable by any extension.
OGC-CRSand the ability to explicitly state the axis-order was removed and we moved to using
conneg-by-crshave we reached a consensus on using a fixed axis-order (e.g. longitude-latitude) or is CRS defined order expected?