Static API Specification of OGC API Features

[situx]

I am the author of an RDF documentation script, which you can find here https://github.com/sparqlunicorn/sparqlunicornGoesGIS-ontdoc

The script takes an RDF file and creates HTML documentation, and a number of other data exports, to be hosted as linked open data on a webspace. The target audience is people who create linked open data but do not have the means to host their own SPARQL endpoints or other linked open data services.

For better accessibility, this script also creates so-called Static APIs, i.e., it mimics results from well-known APIs in the form of JSON files, which are saved in a particular folder structure.

This is where OGC API Features comes in:
For geodata, I created a static API implementation of OGC API Features, which allows me to load FeatureCollections using OGC API Features in, e.g., QGIS.
A complete description of the implementation with an example to test is here: https://github.com/sparqlunicorn/sparqlunicornGoesGIS-ontdoc/wiki/OGC-API-Features:-Static-API

Since it is a static API, it lacks the filter capabilities of CQL, and it lacks the possibility to limit the number of features that can be loaded (it will always load all features of a collection).
Apart from that, I think it is useful, at least to me and the people using my script.

My questions to you are:

• Is it interesting for your working group, maybe, to add as an OGC API Features specification "light" when users only have access to a static webspace?
• Do you maybe have suggestions/improvements/wishes concerning the work that I did?

If this has piqued your interest, I would be happy to write what I wrote in the Wiki entry in a more elaborate manner and contribute it as a pull request to wherever you deem fit in the specification.

Looking forward to hearing from you

[ilkkarinne]

Hi @situx, an interesting project!

I'm perhaps not an authoritative person to have a final word on this, but to me it would seem that 100% static feature collections without any query or limit capabilities do not comply with the OGC API Features Core specification. This is somewhat similar to the use cases people are trying to tackle with static STAC Catalogs and OGC API Records Requirements classes without the query capabilities.

However, the OGC API specifications were always intended as building blocks for people to implement their own APIs following the right level of common location data exchange patterns for their use cases. Nothing would prevent you from creating APIs that use a particular set requirements from the OGC API Features Core specification, perhaps even everything except the ones with requirements for querying and limiting capabilities, including at least:

• Requirement 21 /req/core/fc-limit-definition
• Requirement 22 /req/core/fc-limit-response-1
• Requirement 23 /req/core/fc-bbox-definition
• Requirement 24 /req/core/fc-bbox-response
• Requirement 25 /req/core/fc-time-definition

Since these are included in the Core Requirements class of the OGC API Features, you would have to declare your own "core" Requirements class somewhere with the declaration of the OGC API Requirements you choose to support, and stating conformance to this resource in conformance section of your API definition instead of http://www.opengis.net/spec/ogcapi-features-1/1.0/req/core. To do this correctly you would unfortunately also have to define you own versions of the HTML and GeoJSON Requirements classes too, as they depend on the Core in the OGC API Features spec.

I'll leave commenting regarding OGC API Features SWG plans to support something like this someone else, perhaps @cportele or @pvretano ?

[pvretano]

As far as I know there is no work item in the pipe to deal with a static API for features but as @ilkkarinne mentioned this is very close to what OGC API Records and STAC already do with catalog records and theoretically is would be very straight forward to implement.
The current OGC API Features core would need to be refactored a bit to allow this type of deployment. I'll raise the issue in the next SWG meeting and report back here. Another option to write up a small description and place it in the proposals folder. Just create a new directory called something like "Static Features API" and include the description there.

[cportele]

I see the use case and I think we discussed about it in the early days of the discussions between WFS 3.0 (which was the name at the time) and STAC (which has Item, Collection, etc. as their own specs). This must have been late 2017/early 2018. For OGC API Features we decided to specify an API as the core that supports at least simple spatial filtering and paging. We can, of course, revisit the topic again. I see two aspects:

1. Is there sufficient demand for such an additional standard / conformance class?

As @ilkkarinne has pointed out, one can always use the building blocks to build your own API and ignore those building blocks that cannot be supported by "files on an HTTP server / in a S3 bucket". But if such a pattern is used a lot, it could be worth to specify a standard / conformance class for it.

2. If the answer to the first question is yes, should this be in OGC API Features or a separate standard?

Using "API" for such an offering sounds a bit overpromising to me. It might be cleaner to move the specification of the resources (e.g., Collection) to a separate standard, maybe with HTTP or S3 access mechanisms for fetching. In OGC API Features we would then bind query parameters, headers, etc. to the HTTP GET operations and bind additional HTTP methods to the resources.

[situx]

@pvretano
Thanks for the feedback, and I look forward to the working group's opinion.

@ilkkarinne
Indeed, it is true that the static API will not be able to have full CQL and limit support.
While it is possible to generate all possible query results beforehand (e.g. the result of every limit query), this is possibly not a viable approach.
I could think of some pre-generated query answers likely to be queried in software. Maybe the first 10 items of a collection for example.

[cportele]

Meeting 2023-10-09: We see the use case and see how in can be useful in some contexts, but we are not convinced that this pattern of use would be applied broadly. A Features API should include basic filtering capabilities. If we see that there is broad use of such a deployment pattern, it would make sense to capture the requirements in a standard, but until then we think, the scope of the Core should be kept as it is.

In Records and STAC, the items/features are operational metadata about data, not the data itself like in the typical case of feature data.

[situx]

@cportele Thank you for the quick feedback! Then I will leave it at that, maybe apart from a better documentation of the approach in my repository.

[cportele]

Thank you @situx for bringing this topic up and the work on your tooling! If we see that such an approach is used more widely, we would be happy to revisit the topic.