merge_cubes: The merge_cubes function doesn't merge the temporal range of the previous cube.

[Pratichhya]

While creating a use case to combine an external STAC collection with the available collection, I encountered an issue where the preceding STAC collection wasn't merged. DEO-104

import openeo

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

sentinel_extent = ["2017-01-01", "2020-12-30"]
landsat_extent = ["2014-01-01", "2016-12-31"]
spatial_extent = {"west": 5.0, "south": 51.21, "east": 5.05, "north": 51.25}

s2_cube = connection.load_collection(
    "SENTINEL2_L2A",
    temporal_extent=sentinel_extent,
    spatial_extent=spatial_extent,
    bands=["B04", "B08"]
)

landsat= "https://planetarycomputer.microsoft.com/api/stac/v1/collections/landsat-c2-l2"
landsat_cube = connection.load_stac(
        landsat,
        spatial_extent=spatial_extent, 
        temporal_extent=landsat_extent, 
        bands=["OLI_B4", "OLI_B5"],
        properties={
        "platform": lambda x: x=="landsat-8"}
    )

s2_cube = s2_cube.ndvi()
landsat_cube = landsat_cube.ndvi(nir="OLI_B5", red="OLI_B4")

merged_cube = s2_cube.merge_cubes(landsat_cube)
merged_temporal= merged_cube.aggregate_temporal_period(period="season",reducer="mean")
timeseries_job = merged_temporal.execute_batch(title="landsats2_NDVI",outputfile="Merged_Landsat8Sen2.nc")
```

The received output has the following time dimension:

```
array(['2016-12-01T00:00:00.000000000', '2017-03-01T00:00:00.000000000',
       '2017-06-01T00:00:00.000000000', '2017-09-01T00:00:00.000000000',
       '2017-12-01T00:00:00.000000000', '2018-03-01T00:00:00.000000000',
       '2018-06-01T00:00:00.000000000', '2018-09-01T00:00:00.000000000',
       '2018-12-01T00:00:00.000000000', '2019-03-01T00:00:00.000000000',
       '2019-06-01T00:00:00.000000000', '2019-09-01T00:00:00.000000000',
       '2019-12-01T00:00:00.000000000', '2020-03-01T00:00:00.000000000',
       '2020-06-01T00:00:00.000000000', '2020-09-01T00:00:00.000000000',
       '2020-12-01T00:00:00.000000000'], dtype='datetime64[ns]')
```

I also tested the same example using load_collection for both collections, yet the issue exists.

[soxofaan]

related:

• merge_cubes: invalid spatial_extent merging #507
• merge_cubes: invalid band merging #508

[jdries]

I could reproduce it on a much simpler graph. It looks like a critical issue that's not necessarily related to the issues mentioned above:

{
  "process_graph": {
    "loadcollection1": {
      "process_id": "load_collection",
      "arguments": {
        "bands": [
          "NDVI"
        ],
        "id": "CGLS_NDVI_V3_GLOBAL",
        "spatial_extent": {
          "east": 51.64285714317316,
          "north": 12.214285714301129,
          "south": -1.8839285714099527,
          "west": 40.76785714315832
        },
        "temporal_extent": [
          "2020-05-01",
          "2020-06-30"
        ]
      }
    },
    "loadcollection2": {
      "process_id": "load_collection",
      "arguments": {
        "bands": [
          "NDVI"
        ],
        "id": "CGLS_NDVI300_V2_GLOBAL",
        "spatial_extent": {
          "east": 51.660714286030306,
          "north": 12.232142857158271,
          "south": -1.9017857142670955,
          "west": 40.75000000030117
        },
        "temporal_extent": [
          "2020-07-01",
          "2021-09-01"
        ]
      }
    },
    "merge1": {
      "process_id": "merge_cubes",
      "arguments": {
        "cube1": {
          "from_node": "loadcollection1"
        },
        "cube2": {
          "from_node": "loadcollection2"
        },
        "overlap_resolver": {
          "process_graph": {
            "max1": {
              "process_id": "max",
              "arguments": {
                "data": {
                  "from_parameter": "x"
                }
              },
              "result": true
            }
          }
        }
      }
    },
    "save2": {
      "process_id": "save_result",
      "arguments": {
        "data": {
          "from_node": "merge1"
        },
        "format": "NETCDF"
      },
      "result": true
    }
  },
  "parameters": []
}

[jdries]

j-240911e9fb77427f99233b30551182f3
Merging cubes with spatial indices: SparseSpaceTimePartitioner 6 false - SparseSpaceTimePartitioner 6 false

[jdries]

The problem starts here:
https://github.com/Open-EO/openeo-geotrellis-extensions/blob/f33dc1252991b5630b65c3a88fbf5872b322765c/openeo-geotrellis/src/main/scala/org/openeo/geotrellis/OpenEOProcesses.scala#L832

When the cube is resampled, it receives the partitioner of the other cube, which may not be usable.

[jdries]

Second issue: after merge_cubes of 2 cubes with time dimension, the metadata should be updated to contain the union of the two input time ranges. If not done, aggregate_temporal_period will start from an incorrect input range, resulting in loss of data.

[bossie]

Second issue: after merge_cubes of 2 cubes with time dimension, the metadata should be updated to contain the union of the two input time ranges. If not done, aggregate_temporal_period will start from an incorrect input range, resulting in loss of data.

FYI I'm currently implementing this in the context of #852.

[bossie]

Pushed a fix, needs a test.

[bossie]

@Pratichhya this is available on staging. Let me know if you encounter any issues.