-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static API Specification of OGC API Features #860
Comments
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:
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 I'll leave commenting regarding OGC API Features SWG plans to support something like this someone else, perhaps @cportele or @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. |
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:
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.
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. |
@pvretano @ilkkarinne |
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. |
@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. |
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. |
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:
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
The text was updated successfully, but these errors were encountered: