Add OGC Features API at /catalogs/{catalogId}/collections/{collectionId}/features

[recalcitrantsupplant]

This PR implements the OGC Features API as a subapi within Prez. It has been implemented at: "/catalogs/{catalogId}/collections/{recordsCollectionId}"

The material changes are:

• Add profiles/endpoints definitions specific to OGC Features under prez/reference_data/profiles|endpoints
• Add OGC Features Sub Application (similar to adding a Router)
• Add time and bbox as query parameters for filtering generally, reusing code from CQL implementation where possible.
• Add /prefixes endpoint
• Add dependency on rdf2geojson library to support returning geojson mediatype
• A breaking change to rename the "per_page" query parameter generally to "limit" for conformance with OGC Features and to prevent having two differently named query parameters for one function.

Most of the other changes are renaming things to prevent conflicts, and the addition of a set of CQL queries for testing.

NB the implementation is done as a mount of a separate FastAPI application NOT a FastAPI router. This is so that the Features API can be a "pure" OGC Features API and automatically include docs at a sensible location i.e. /features/docs, and make catering to the specific requirements of OGC Features easier.

The main "data" endpoints are listed below for clarity. A full list of endpoints including management (prefixes, curies), search etc. has been added to the main Readme.

Prez Core Endpoints:

Endpoint	Default Profile	Default MT
/	N/A	text/anot+turtle
/docs	OGC API	text/html
/catalogs/{catalogId}	OGC API	text/anot+turtle
/catalogs/{catalogId}/collections	OGC API	text/anot+turtle
/catalogs/{catalogId}/collections/{recordsCollectionId}	OGC API	text/anot+turtle
/catalogs/{catalogId}/collections/{recordsCollectionId}/items	OGC API	text/anot+turtle
/catalogs/{catalogId}/collections/{recordsCollectionId}/items/{itemId}	OGC API	text/anot+turtle

OGC Features API Endpoints:

The OGC Features API Endpoints are based at the ROOT /catalogs/{catalogId}/collections/{recordsCollectionId}/

Endpoint	Default Profile	Default MT
{ROOT}/features	N/A	application/json
{ROOT}/features/docs	N/A	text/html
{ROOT}/features/conformance	N/A	application/json
{ROOT}/features/collections	OGC Features Minimal Profile	application/json
{ROOT}/features/collections/{collectionId}	OGC Features Minimal Profile	application/json
{ROOT}/features/collections/{collectionId}/items	OGC Features All Properties Profile	application/geo+json
{ROOT}/features/collections/{collectionId}/items/{featureId}	N/A (Query Specified)	application/geo+json

[ashleysommer]

I'm reviewing this now...

[lalewis1]

Note: need to pin the version in pyproject.toml to 3.12.4

I tried installing dependencies with 3.12.5 and cannot install scalene. tried install with 3.11.9 and scalene installs but spaceprez endpoint tests fail due to conflicts with rdflib version. under 3.12.4 everything works as expected.

Looking at the ogctest results I can see that only the crs tests and apidefinition tests fail.
the crs tests fail simply because the api does not declare that it conforms to the crs conformance class at /conformance. the apidefinition tests are failing because the test suite only supports openapi spec v3.0 and prez is using v3.1. (this is an issue with the ogc test suite and I have added a ticket there to add support for other openapi versions)

Issue

Browsing http://localhost:8000/catalogs/ex:DemoCatalog/collections/ex:GeoDataset/features/collections says that no collections are availalable. even though there should be a collection. This is using the ogc_features.ttl test data.

[lalewis1]

using the updated test data / profile, the collections are now listed and viewable but there is still an issue accessing the individual features.

i.e.

curl --silent localhost:8000/catalogs/ex:DemoCatalog/collections/ex:GeoDataset/features/collections/ex:FeatureCollection/items/ex:Feature1

yields {} but should show the details of the feature.

in addition, putting an invalid feature id like 1 yields a 500 response, expected a 404.

[recalcitrantsupplant]

Thanks I'll check the tests covers those

[lalewis1]

using the updated test data / profile, the collections are now listed and viewable but there is still an issue accessing the individual features.

i.e.

curl --silent localhost:8000/catalogs/ex:DemoCatalog/collections/ex:GeoDataset/features/collections/ex:FeatureCollection/items/ex:Feature1

yields {} but should show the details of the feature.

in addition, putting an invalid feature id like 1 yields a 500 response, expected a 404.

To give some direction for this.

When requesting the details of ex:Feature1, In the debugger I can see that the item_graph in the ogc_features_object_function only has one triple declaring that the type of ex:Feature1 is a geo:Feature. I feel like this should have more info, so perhaps there is an issue with the query generation. also, the convert function for converting to geojson reduces this single triple down to an empty {} object so there is something not right there too.

hope that helps.

[recalcitrantsupplant]

Note: need to pin the version in pyproject.toml to 3.12.4

I tried installing dependencies with 3.12.5 and cannot install scalene. tried install with 3.11.9 and scalene installs but spaceprez endpoint tests fail due to conflicts with rdflib version. under 3.12.4 everything works as expected.

Looking at the ogctest results I can see that only the crs tests and apidefinition tests fail. the crs tests fail simply because the api does not declare that it conforms to the crs conformance class at /conformance. the apidefinition tests are failing because the test suite only supports openapi spec v3.0 and prez is using v3.1. (this is an issue with the ogc test suite and I have added a ticket there to add support for other openapi versions)

Issue

Browsing http://localhost:8000/catalogs/ex:DemoCatalog/collections/ex:GeoDataset/features/collections says that no collections are availalable. even though there should be a collection. This is using the ogc_features.ttl test data.

With the CRS one I'll create a separate issue (#267). In short, and Prez will likely support by proxy whichever CRSs the triplestore GeoSPARQL implementation supports, so we probably just need a way to discover that (might be hard) and then expose this info in the various places in the OGC Features API. If this is too hard, we could just create a config option to allow manual specification of different CRSs. It's currently specifying WGS84 as a temporary solution. I'd prefer not to mark it compliant until we've gone through the separate spec in detail.

Not sure what is going on with the python versions. I'll remove scalene as a dev dependency.

[lalewis1]

awesome looks good to me. nice work.