bands in results out of order for Sentinel 2 collection(s) on CDSE

[bossie]

Requesting the bands separately shows that the combination has both bands swapped:

connection = openeo.connect("openeo.dataspace.copernicus.eu").authenticate_oidc()

def statistics(bands) -> dict:
    data_cube = (connection
                 .load_collection("SENTINEL2_L2A",
                                  temporal_extent=["2023-09-24", "2023-09-25"],
                                  bands=bands)
                 .aggregate_spatial(geometries={"type": "Polygon", "coordinates": [[[4.912844218500582, 51.02816932187383], [4.912844218500582, 51.029815337603594], [4.918160603369832, 51.029815337603594], [4.918160603369832, 51.02816932187383], [4.912844218500582, 51.02816932187383]]]},
                                    reducer="mean")
                 .save_result("JSON"))

    return data_cube.execute()

statistics_a = statistics(["SAA", "VAA"])
statistics_b = statistics(["SAA"])
statistics_c = statistics(["VAA"])

print(json.dumps(statistics_a))
print(json.dumps(statistics_b))
print(json.dumps(statistics_c))

assert statistics_a["2023-09-24T00:00:00Z"][0][0] == statistics_b["2023-09-24T00:00:00Z"][0][0]  # boom!
assert statistics_a["2023-09-24T00:00:00Z"][0][1] == statistics_c["2023-09-24T00:00:00Z"][0][0]

{"2023-09-24T00:00:00Z": [[107.97330474853516, 165.93194580078125]]} {"2023-09-24T00:00:00Z": [[165.93194580078125]]} {"2023-09-24T00:00:00Z": [[107.97330474853516]]} FAILED tests/debug_local_spark.py:4731 (Test.test_cdse_sentinel2_bands_order_statistics) 107.97330474853516 != 165.93194580078125

[bossie]

@EmileSonneveld just to be sure, is this the expected behavior for S2L2A on Creo? I'm comparing B03 that comes out of OpenEO against the original .jp2 file.

https://github.com/Open-EO/openeo-geotrellis-extensions/blob/3988f4c8bc70de9657668102ba0268164d293824/openeo-geotrellis/src/test/scala/org/openeo/geotrellis/file/CreoPyramidFactoryTest.scala#L119

[EmileSonneveld]

Sounds right. Recent products in S2L2A (And L1C) now needs to be offseted before being used further. They did that to be able to represent negative values without using signed data. https://github.com/Open-EO/openeo-geotrellis-extensions/issues/144

[bossie]

Prepending (angle) band indices lead to a reverse order so appending instead. Similarly, prepending to and reversing the list afterwards has been replaced with appending.