load_stac and remove job-id subtype #384

[m-mohr]

To avoid ambiguities, I think we can remove the batch job id subtype. A batch job ID can also just be provided via the uri subtype. Either you provide the canonical (i.e. "public") link and then it's just like any external data. Or you can simply provide a URI such as https://example.com/api/v1.0/jobs/12345/results and then you can easily detect the job id from it. The clients can help with it by allowing Job objects as input for example.

[LukeWeidenwalker]

I like this change! Subsuming the openeo-internal "result" concept into the generally-applicable "datacube-described-by-STAC" concept (which exists outside of openeo) makes total sense to me.

What prevents us from doing something similar for load_collection? At the end of the day each collection is also just a STAC collection, right? Is the "collection" concept in openeo anything other than "STAC collection openeo platform knows about and has an explicit name for"? The geometry parameter that load_collection has could just as well be added to load_stac.

(If my understanding of the collection abstraction is somehow inaccurate, I'd also love to hear in what way 😇)

[jdries]

@LukeWeidenwalker FYI, not each openEO collection is a STAC collection. In Terrascope backend for instance, the majority of collections is based on opensearch or even simply finding tif or netcdf files on disk by globbing.

[m-mohr]

Change id to url.

[m-mohr]

Ready for review.