OGC API Features and enclosure links

GeoServer GeoServer User
1

Hello dear GS and OGC API specialists,
Through geOrchestra, we are seeing more and more platforms using the OGC API Features service of GeoServer. The DataHub is a client to these services, displaying a preview of the data and generating links to download the data. The OGC API Features standard makes a distinction between items links and enclosure links. Items links are meant for a few items download, up to 10.000, and support pagination for larger datasets. Enclosure links are meant for bulkdownload. When publishing a dataset from GeoServer as OGC API Features, we only get items links.
Do you know if this is configurable? What would be the process to ask for this feature to be supported if it’s not already done?
Thanks!

2

Hi,
the enclosure link is not a mandatory part of the OGC API Features implementation, and not even an recognized optional one, it’s cited just as an example, quoting:

Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by the API. For example, an enclosure link could reference a bulk download of a collection. Or a related link on a feature could reference a related feature.

When I participated to the Testebeds in OGC, enclosure was seen as a way to link to the original data, for static file download, but the example above is not specific about this approach.

If you have the original data handy, it’s already possible to configure custom links on a per layer basis.

A dynamically generated bulk download link could be nice to have for small datasets, but will definitely be problematic for larger ones. Depending on the format, it will present different challenges. Assuming the source data is in a database:

  • If the output format can be streamed (e.g. GeoJSON), it will require keeping a connection open to the database for all the time it takes to generate and send over the output. A slow client can exarcerbate this issue.
  • If the output format cannot be streamed (e.g., GeoPackage), it will require keeping a large file on disk during the production and the subsequent download.

Some limits will have to be placed to avoid these issues (e.g., fail the download if the source has more than X records).

As for “how to ask”, this is the guide on how to get anything done in GeoServer:

Hope this helps
Andrea

3

Thanks for the detailed answer! We will see what we can achieve with this, and go further if needed.

4

Thank you @aaime-geosolutions for the quick response. Another interrogation we had is that with the GeoServer extension we can do a /items?f=json request without any limit parameter and it will return the full dataset (up to a certain server-defined limit). The OGC API Features spec says that no limit will fallback to the default value (10). Was there a reason for this apparent deviation from the spec? or did I misunderstand something?

It’s tempting to rely on this mechanism to offer a full download link of a dataset, but I feel like it might change in the future to comply with the spec and these links will then all break.

Thanks in advance :slight_smile:

5

This is again a case of taking an example as part of the binding part of the specification:

Quoting:

The values for minimum, maximum and default in requirement /req/core/fc-limit-definition are only examples and MAY be changed.

It’s up to the server to decide the value for the “default”, and GeoServer uses the value configured in the WFS service panel, which is normally large, but not massive (1 million?).

For full downloads we normally prefer something that handles asynchronous requests, OGC API Features, in all of its forms, will fail for large datasets. I would recommend exploring the OGC API Processes community module instead, in combination with the “wps download” module (as a process, it should work equally well with both WPS and OGC API).

Hope this helps
Andrea