stac.dataspace.copernicus.eu has an issue with small job

[bossie]

And regular jobs fail as well:
 
OpenEO batch job failed: geotrellis.raster.gdal.MalformedDataTypeException: Unable to determine NoData value. GDAL Exception Code: 4
 
j-241222b4d0e84ae59471411738527310
 
(Note that using regular band names - without _x0m postfix - rightfully gives an error on the band name not existing)

https://teams.microsoft.com/l/message/19:[email protected]/1733753973200?tenantId=9e2777ed-8237-4ab9-9278-2c144d6f6da3&groupId=befdddf8-55e8-4c70-855e-8802739f2ae9&parentMessageId=1733753973200&teamName=Remote%20Sensing%20Services&channelName=openeo-devs&createdTime=1733753973200

[bossie]

The actual GDAL error is this:

�[30;1m�[45;1m[1 of 1000]�[0m �[31;1mFAILURE(3) CPLE_OpenFailed(4) "Open failed." s3://eodata/Sentinel-2/MSI/L2A_N0500/2020/06/28/S2A_MSIL2A_20200628T112121_N0500_R037_T29TNE_20230404T183214.SAFE/GRANULE/L2A_T29TNE_A026203_20200628T112608/IMG_DATA/R10m/T29TNE_20200628T112121_B02_10m.jp2: No such file or directory �[0m

which is to be expected since GDAL requires paths that look like this: /vsis3/EODATA/...

[bossie]

Incidentally, I fixed this recently in the context of #979.

Replaying the process graph now gives this error:

OpenEO batch job failed: Exception during Spark execution: java.lang.IllegalArgumentException: array_element: Could not find label B08, these labels are available:[B02_10m, B04_10m, B08_10m]

which is to be expected because the labels used in reduce_dimension should match those present in the load_stac data cube.

@JorisCod you can get the process graph to run by using the _x0m bands in load_stac as well as reduce_dimension*

* this is because in the absence of eo:bands, load_stac will use asset keys as band names and consider the assets single-band assets (this is effectively the case). Ideally load_stac should support bands in addition to eo:bands but this is not yet implemented (#1015).