`stac` subtype: Include ItemCollections?

[m-mohr]

The stac subtype (see https://github.com/Open-EO/openeo-processes/blob/draft/meta/subtype-schemas.json#L281) currently allows to pass a single item, collection or catalog (which includes API landing pages). It does NOT include ItemCollections, which is what you get returned by a STAC search (i.e. a GeoJSON FeatureCollection where each feature is a STAC Item).

Is that good or bad?

Came up in a discussion here: opengeospatial/ogcapi-processes#467

First thought was that it might be good to add ItemCollection, but then on the other hand I'm thinking that it may be bad because we actually may want to do the search implcitly using the parameters provided in the load_* processes.

So just capturing some thoughts from otheres here that implement it.

cc @clausmichele @soxofaan @jdries

[m-mohr]

Any practical insights from the implementations? @soxofaan @clausmichele and others?

[soxofaan]

Good question.

But if I understand correctly, purely within the openEO ecosystem there is little reason to widen the scope at the moment, right?
The only openEO process that purely creates a stac entity (in the "net" sense, so without requiring existing stac objects as input) is save_result, so it's technically a backend implementer's choice what kind of STAC entity is produced. At the moment there is not really a reason to consider a ItemCollection at that point, as there is already a more classic STAC Collection option I would think.

Is the reason to widen the scope to better align with a wider ecosystem?
Or is it to allow introduction of additional processes (e.g. stac_api_search) that creates a stac object?

[m-mohr]

This came from discussions with OGC API - Processes, where some processes may return an ItemCollection. I'm not sure how broadly this happens, personally not a big fan of just passing an ItemCollection.

[soxofaan]

related question brought up at Open-EO/openeo-geopyspark-driver#1278:
should load_stac also support loading ItemCollections?