1 Discover

concept (80/100)

General

• First, only external STAC catalogs should be referenced (for usage with openeo-grassgis-driver)
• Later, the data inside the grassdb should be exposed via STAC as well
• No complete catalogs should be cached - better a reference to the original STAC instance should be requested and links adjusted

Endpoint /stac

• HTTP POST
  • API endpoint within actinia. Receives parameters "stac-url" + "stac-instance-id" in post body
  • stac-url can be any URL contained in a STAC catalog
  • for prototypical implementation, stac-url needs to be a link to a collection. In this case, the user also provides a "stac-collection-id" -> need to be original collection name
  • later, actinia finds out, which type it is and registers collection(s)
    • for item => superior collection
    • for catalog => follow child links 1x, if they are a collection, it will be registered
    • for collection => collection
    • collection_id will be read and stored
    • how to find out type?
      • Item = type feature, from 1.0.0 type collection / catalog possible as well
      • before 1.0.0: if licenes + extent exists => collection, else catalog
      • see best-practices.md#how-to-differentiate-stac-files
  • needed information are stored in redis (stac-instance-id, collections with id, url, openeoID see below in Naming Convention
  • If already exists, remove old references and store again "refresh" --> see HTTP PUT below
  • HTTP DELETE also removes all references to a STAC instance. WARNING: if collection URL, then only delete collection URL. TODO: design more finely. --> see HTTP DELETE below

Endpoints /stac/collections and /stac/collections/<collection_id>

• HTTP GET
  • returns a list of all already registered STAC collections / a single collection (with description, temporal & spatial extent, ...)
  • It should return all information needed by openEO, eg https://openeo-loose.mundialis.de/api/v1.0/collections
  • Datamodel see here: https://openeo.org/documentation/1.0/developers/api/reference.html#operation/list-collections
    • Further "content extensions" exist (for datacube, EO, SAR; Pointcloud, single file, ..)
    • Here as well: preferred to request original STAC instance and adjust URLs, instead of caching everything. But if Schemata exist in python, they can be validated
• HTTP PUT to update a collection
• HTTP DELETE to unregister a collection

Endpoints /stac/instances and /stac/instances/<instance_id>

• HTTP GET
  • returns a list of all already registered STAC instances / a list of all already registered STAC collections from a certain instance
• HTTP PUT to update an instance
• HTTP DELETE to unregister an instance including all related collections

Naming convention

• actinia registers all collections as STRDS = openEO collections
• Does the datatype needs to be checked? For STAC it is always spatial + temporal + raster. Vector data is not encouraged but could be referenced theoretically
• stac.<stac-instance-id>.rastercube.<stac-collection-id> Example: stac.element84.rastercube.sentinel-s2-l2a-cogs (analogue to openeo collection name, e.g. latlong_wgs84.modis_ndvi_global.strds.ndvi_16_5600m).
  • We need to be able to distinguish between internal data in grassdb and STAC references
  • Drawback for user to have collection id in external catalog and openEO ID which differs for same collection
  • instance-id makes sense, also if general and user data are separated in different catalogs

Misc

• Add config option for initial STAC Catalog references
• Storing some information in the redis db is necessary, because to retrieve base information about e.g. ~50 STAC catalogs on the fly in one request would not be feasable

GRASSDB in STAC

/-catalog	catalog	catalog	collection	collection
sentinel-2
landsat-8
grassdb	location 1	mapset 1	raster_layer 1	strds_raster_layer 1
	location 2	mapset 2	raster_layer 2
	location 3	mapset 3	strds 1