STAC, Collection and Workspace handling in openEO

[m-mohr]

Related

• User-generated Collections openeo-api#376
• Consider using a standardized API for file access openeo-api#135
• export_to_workspace #467
• https://github.com/stac-api-extensions/collection-transaction

Changelog

• Added export_collection
• Added export_workspace
• Added stac_modify
• save_results: Returns the STAC resource instead of boolean true

[jdries]

So for my use case of storing metadata of jobs in an existing STAC collection, I would use export_collection?
This collection can then optionally expose a STAC api I assume, as this is already foreseen.
By default, this would be a private collection? Do we already have a way to make such a collection public?
Sharing within a group would perhaps be via signed url?

[m-mohr]

@jdries

So for my use case of storing metadata of jobs in an existing STAC collection, I would use export_collection?

• If you want to store it as an openEO Collection (i.e. exposed via /collections, usable via load_collection): export_collection
• If you just want to have a STAC Collection on cloud storage somewhere (usable via load_stac): export_workspace (if your backend exports STAC Collections for batch job results, otherwise it would be an Item)

This collection can then optionally expose a STAC api I assume, as this is already foreseen.

export_collection would automatically expose this through the openEO API (i.e. /collections), which can optionally have the STAC API Items endpoints (i.e. /collections/:id/items).

By default, this would be a private collection?

Yes, by default this is only accessible after authentication from the user that created the collection.

Do we already have a way to make such a collection public?
Sharing within a group would perhaps be via signed url?

No, I'd like to generally target sharing in a common manner across all openEO resource types.

We pretty much have defined the behavior for making resources public (happy to adopt the public flag as implemented by VITO and signed URLs as documented in batch job results). We don't have anything more specific for users or groups. Both will need separate work items (a smaller one for public sharing, and a larger one for user/group based sharing). Unfortunately, there's currently no funding foreseen for this in any project afaik.

[m-mohr]

Any further reviews? @soxofaan @jdries @GeraldIr @clausmichele @dthiex
Otherwise, I'd merge this soon.

[clausmichele]

Any further reviews? @soxofaan @jdries @GeraldIr @clausmichele @clausmichele Otherwise, I'd merge this soon.

Comments added, thanks for tagging me and my twin @clausmichele for a double review

[jdries]

@bossie you implemented export_workspace, did we have any remarks on the process description?
Can you perhaps also check stac_modify? As we also plan to implement that one.

[jdries]

Here's a next step in how I plan to use this to export openEO results directly into a stac api:

• save_result -> generates static stac
• stac_modify -> update metadata as needed
• export_workspace(merge="https://openeo.stac.vito.be/.../my_user_collection", workspace="my_workspace")

For this to work, the openeo service needs to have permission to write into the referenced stac collection, or a presigned url with write permission needs to be provided. (A presigned url mechanism for writing is not part of the stac spec afaik,...)