search

actinia-org / actinia-stac-plugin

Plugin for actinia to read STAC catalogs and retrieve data for processing
GNU General Public License v3.0
3 stars 2 forks source link

Support STAC collections as processing input via openeo-grassgis-driver #48

Closed mmacata closed 2 years ago

mmacata commented 2 years ago

The openeo-grassgis-driver is already able to list the collections from /stac/collections within its own /collections endpoint, so they can be theoretically used for processing (see https://github.com/Open-EO/openeo-grassgis-driver/pull/124). Now that the import of the real data for processing within actinia-core is implemented, the whole processing workflow can be prepared and tested.

joaherrerama commented 2 years ago

@metzm @mmacata @neteler I am creating the PC to import the items from the STAC into grass. The import issue were solved. But during this development in OpenEO, some questions have been coming up:

  1. The code use the naming structure to define the location where the process will be performed, however, there is no stac location in GRASS. Thereupon should I define a location for it?

  2. As a user can have the same STAC with different spatio-temporal constrains in multiple or the same location. Should we implement a naming structure on these cases (implemented in Actinia Core in this way using the Date format)? Or should we restrict the spatio-temporal import to one an only STDR per collection?

mmacata commented 2 years ago

Discussed internally:

  1. The code use the naming structure to define the location where the process will be performed, however, there is no stac location in GRASS. Thereupon should I define a location for it?

The location is determined by the processing endpoint which is called.

For integration with openEO, the initial idea was that the location in which to calculate is determined by load_collection process from openEO - this is not very intuitive for the user, as there only the epsg code for the BBOX filter can be specified, but it would allow some kind of control at least. Default is EPSG:4326. So the way to go: analyse the load_collection process as this always needs to be used within a process graph and if there is no CRS set, then default 4326 is used which corresponds fortunately to our latlong_wgs84 location which is present on all deployed actinias. For the first step it would be fine to start with this and if a different CRS is set in load_collections, then message returned that a user is not yet allowed to create a new location. This corresponds to the ideas for prototypical implementation https://github.com/mundialis/actinia-stac-plugin/wiki/3-Read#possible-solutions

  1. As a user can have the same STAC with different spatio-temporal constrains in multiple or the same location. Should we implement a naming structure on these cases (implemented in Actinia Core in this way using the Date format)? Or should we restrict the spatio-temporal import to one an only STDR per collection?

The user can control the name of the STRDS and contained maps via map parameter value in the actinia process chain. If it already exists it will be overwritten.