BackendLookupFailure: No backend matching all constraint

openEO Platform
1

Hello,

I am trying to download fused data (S1,S2,DEM) after applying spatial and temporal resampling for alignment, but my jobs keep returning errors. I am currently using https://openeocloud-dev.vito.be as backend as CDSE has some issues with credits being fixed.

First I got:

openeo.rest.OpenEoApiError: [400] ProcessUnsupported: Process with identifier ‘resample_cube_temporal’ is not available in namespace ‘None’.

Although the ‘resample_cube_temporal’ shows up in the list of available processes (from processes = connection.list_processes()).

I tried to reduce the scope of the operations (smaller time chunck, perform only resampling and download individually the collections) but still get:

openeo.rest.OpenEoApiError: [400] BackendLookupFailure: No backend matching all constraint

Is this an issue with the backend not supporting these operations or is there something else I can try? Individual “simple” cubes get downloaded with no issues.

Thanks!

2

Hi Antonella,

To get better insights in your use case: what exact collections are you using here? Or could you share your code, a process graph or job ids?

About resample_cube_temporal: that (experimental) process is currently only supported by the SentinelHub backend (part of the openEO Platform federation), while the data collections you are trying to load are only available on a different backend in the federation.
Which explains this error

BackendLookupFailure: No backend matching all constraint

tip: when sharing errors, make sure to include job or request ids
(something like r-390410270547939dfe71d601f66312 )

3

Dear Stefaan,

thanks!

Here below a summary of the process graph (changed to a random area of similar size) related to the error:

openeo.rest.OpenEoApiError: [400] ProcessUnsupported: Process with identifier ‘resample_cube_temporal’ is not available in namespace ‘None’. (ref: r-2509081114244691a6a13c5d99f16d18)

Now I am connecting to https://openeo.dataspace.copernicus.eu.

{
“process_graph”: {
“loadcollection1”: {
“process_id”: “load_collection”,
“arguments”: {
“id”: “SENTINEL2_L2A”,
“spatial_extent”: {
“west”: 12.86151363703019,
“south”: 52.2839480217307,
“east”: 12.86228393802792,
“north”: 52.28431959625967,
“crs”: “EPSG:4326”
},
“temporal_extent”: [
“2020-01-01”,
“2020-01-05”
]
}
},
“filterspatial1”: {
“process_id”: “filter_spatial”,
“arguments”: {
“data”: {
“from_node”: “loadcollection1”
},
“geometries”: {
“type”: “Polygon”,
“coordinates”: [
[
[
12.86151363703019,
52.28431076956142
],
[
12.86217244112683,
52.28431959625967
],
[
12.86228393802792,
52.28402218603096
],
[
12.8618979762296,
52.2839480217307
],
[
12.86151363703019,
52.28431076956142
]
]
]
}
}
},
“reducedimension1”: {
“process_id”: “reduce_dimension”,
“arguments”: {
“data”: {
“from_node”: “filterspatial1”
},
“dimension”: “bands”,
“reducer”: {
“process_graph”: {
“arrayelement1”: {
“process_id”: “array_element”,
“arguments”: {
“data”: {
“from_parameter”: “data”
},
“index”: 14
}
},
“eq1”: {
“process_id”: “eq”,
“arguments”: {
“x”: {
“from_node”: “arrayelement1”
},
“y”: 4
}
},
“eq2”: {
“process_id”: “eq”,
“arguments”: {
“x”: {
“from_node”: “arrayelement1”
},
“y”: 5
}
},
“or1”: {
“process_id”: “or”,
“arguments”: {
“x”: {
“from_node”: “eq1”
},
“y”: {
“from_node”: “eq2”
}
}
},
“not1”: {
“process_id”: “not”,
“arguments”: {
“x”: {
“from_node”: “or1”
}
},
“result”: true
}
}
}
}
},
“mask1”: {
“process_id”: “mask”,
“arguments”: {
“data”: {
“from_node”: “filterspatial1”
},
“mask”: {
“from_node”: “reducedimension1”
}
}
},
“resamplespatial1”: {
“process_id”: “resample_spatial”,
“arguments”: {
“align”: “upper-left”,
“data”: {
“from_node”: “mask1”
},
“method”: “bilinear”,
“projection”: “EPSG:32633”,
“resolution”: 10
}
},
“aggregatetemporalperiod1”: {
“process_id”: “aggregate_temporal_period”,
“arguments”: {
“data”: {
“from_node”: “resamplespatial1”
},
“period”: “day”,
“reducer”: {
“process_graph”: {
“median1”: {
“process_id”: “median”,
“arguments”: {
“data”: {
“from_parameter”: “data”
}
},
“result”: true
}
}
}
}
},
“resamplecubetemporal1”: {
“process_id”: “resample_cube_temporal”,
“arguments”: {
“data”: {
“from_node”: “aggregatetemporalperiod1”
},
“target”: [
“2020-01-01”,
“2020-01-02”,
“2020-01-03”,
“2020-01-04”,
“2020-01-05”
],
“valid_within”: 1
}
},
“loadcollection2”: {
“process_id”: “load_collection”,
“arguments”: {
“id”: “SENTINEL1_GRD”,
“spatial_extent”: {
“west”: 12.86151363703019,
“south”: 52.2839480217307,
“east”: 12.86228393802792,
“north”: 52.28431959625967,
“crs”: “EPSG:4326”
},
“temporal_extent”: [
“2020-01-01”,
“2020-01-05”
]
}
},
“sarbackscatter1”: {
“process_id”: “sar_backscatter”,
“arguments”: {
“coefficient”: “sigma0-ellipsoid”,
“contributing_area”: false,
“data”: {
“from_node”: “loadcollection2”
},
“elevation_model”: “COPERNICUS_30”,
“ellipsoid_incidence_angle”: false,
“local_incidence_angle”: false,
“mask”: false,
“noise_removal”: true
}
},
“filterspatial2”: {
“process_id”: “filter_spatial”,
“arguments”: {
“data”: {
“from_node”: “sarbackscatter1”
},
“geometries”: {
“type”: “Polygon”,
“coordinates”: [
[
[
12.86151363703019,
52.28431076956142
],
[
12.86217244112683,
52.28431959625967
],
[
12.86228393802792,
52.28402218603096
],
[
12.8618979762296,
52.2839480217307
],
[
12.86151363703019,
52.28431076956142
]
]
]
}
}
},
“resamplecubespatial1”: {
“process_id”: “resample_cube_spatial”,
“arguments”: {
“data”: {
“from_node”: “filterspatial2”
},
“method”: “bilinear”,
“target”: {
“from_node”: “resamplespatial1”
}
}
},
“aggregatetemporalperiod2”: {
“process_id”: “aggregate_temporal_period”,
“arguments”: {
“data”: {
“from_node”: “resamplecubespatial1”
},
“period”: “day”,
“reducer”: {
“process_graph”: {
“median2”: {
“process_id”: “median”,
“arguments”: {
“data”: {
“from_parameter”: “data”
}
},
“result”: true
}
}
}
}
},
“resamplecubetemporal2”: {
“process_id”: “resample_cube_temporal”,
“arguments”: {
“data”: {
“from_node”: “aggregatetemporalperiod2”
},
“target”: [
“2020-01-01”,
“2020-01-02”,
“2020-01-03”,
“2020-01-04”,
“2020-01-05”
],
“valid_within”: 1
}
},
“mergecubes1”: {
“process_id”: “merge_cubes”,
“arguments”: {
“cube1”: {
“from_node”: “resamplecubetemporal1”
},
“cube2”: {
“from_node”: “resamplecubetemporal2”
}
}
},
“loadcollection3”: {
“process_id”: “load_collection”,
“arguments”: {
“id”: “COPERNICUS_30”,
“spatial_extent”: {
“west”: 12.86151363703019,
“south”: 52.2839480217307,
“east”: 12.86228393802792,
“north”: 52.28431959625967,
“crs”: “EPSG:4326”
},
“temporal_extent”: [
“2020-01-01”,
“2020-01-05”
]
}
},
“filterspatial3”: {
“process_id”: “filter_spatial”,
“arguments”: {
“data”: {
“from_node”: “loadcollection3”
},
“geometries”: {
“type”: “Polygon”,
“coordinates”: [
[
[
12.86151363703019,
52.28431076956142
],
[
12.86217244112683,
52.28431959625967
],
[
12.86228393802792,
52.28402218603096
],
[
12.8618979762296,
52.2839480217307
],
[
12.86151363703019,
52.28431076956142
]
]
]
}
}
},
“resamplespatial2”: {
“process_id”: “resample_spatial”,
“arguments”: {
“align”: “upper-left”,
“data”: {
“from_node”: “filterspatial3”
},
“method”: “bilinear”,
“projection”: “EPSG:32633”,
“resolution”: 10
}
},
“resamplecubetemporal3”: {
“process_id”: “resample_cube_temporal”,
“arguments”: {
“data”: {
“from_node”: “resamplespatial2”
},
“target”: [
“2020-01-01”,
“2020-01-02”,
“2020-01-03”,
“2020-01-04”,
“2020-01-05”
]
}
},
“mergecubes2”: {
“process_id”: “merge_cubes”,
“arguments”: {
“cube1”: {
“from_node”: “mergecubes1”
},
“cube2”: {
“from_node”: “resamplecubetemporal3”
}
},
“result”: true
}
}
}

4

Dear Stefaan, about the availability of resample_cube_temporal, I do see it both in the documentation (openEO API Processes) and is listed in the available processes when connecting to https://openeocloud-dev.vito.be:

>>> processes = connection.list_processes()
Partial process listing: missing federation components: ['dummy', 'eodc'].
>>> temporal_processes = [p['id'] for p in processes if 'temporal' in p['id'].lower()]
>>> print(f"Available temporal processes: {temporal_processes}")
Available temporal processes: ['aggregate_temporal', 'aggregate_temporal_period', 'filter_temporal', 'resample_cube_temporal']
>>> print(f"resample_cube_temporal available: {'resample_cube_temporal' in temporal_processes}")
resample_cube_temporal available: True

while it is indeed not present when connecting to https://openeo.dataspace.copernicus.eu

>>> temporal_processes = [p['id'] for p in processes if 'temporal' in p['id'].lower()]
>>> print(f"Available temporal processes: {temporal_processes}")
Available temporal processes: ['aggregate_temporal', 'aggregate_temporal_period', 'filter_temporal'] 
>>> print(f"resample_cube_temporal available: {'resample_cube_temporal' in temporal_processes}")
resample_cube_temporal available: False

In my previous reply I was connecting to CDSE, but I get exactly the same error with EGI/openeocloud-dev.vito and the process graph is identical except for

$ diff CDSE_short_process_graph.json test_short_process_graph.json 
70c70
<                 "index": 14
---
>                 "index": 13
5

To clarify the state of resample_cube_temporal a bit more:

  • it’s indeed listed at openEO API Processes, but that is just the official openEO process specification, it does not imply a guarantee that it’s available or an obligation for backends to implement it. Technically, the process is still flagged as “experimental” in the latest official release of the openeo-processes specification: 1.2.0
  • it is also listed under the openEO Platform federation (openeo.cloud, openeocloud.vito.be, openeocloud-dev.vito.be), because there is one participating backend in the federation (SentinelHub) that supports it. However, this backend does not support all the collections you want to use. And vice versa, the backend that provides all the collections you want to use (VITO/Terrascope) does not support resample_cube_temporal yet. As a result, your openEO workflow can not be resolved at the moment.
    • side note: the federation has an experimental feature for “cross-backend” processing, but that is not supported by the SentinelHub backend either, so that is currently a dead end too
    • side note two: authentication is currently broken on SentinelHub backend, so that’s also not helping
  • CDSE (https://openeo.dataspace.copernicus.eu), which is powered by the same backend-implementation as VITO/Terrascope, does not support resample_cube_temporal either

Long story short: I wouldn’t bet on a short term solution for your use case to use these particular collections SENTINEL2_L2A, SENTINEL1_GRD, COPERNICUS_30 with the resample_cube_temporal process.

How important is using resample_cube_temporal for your use case? Note that there is also aggregate_temporal and aggregate_temporal_period, which can also be used to temporally align data cubes before merging.

6

Thanks a lot for the explanation, just as clarification, whenever I am connecting to the OpenEO cloud, I am connecting to the federation and see information generally valid for the federation, but then only have access to the services/collections/etc of the backend I select (in my example, vito-dev), is this right? How can I make sure I get the info specific for the selected backend to avoid confusion in the future? For example now I was getting from connection.list_processes() that the process was available, despite being connected to vito-dev.

Back to the resample_cube_temporal, the only reason for me to do it was to align the data temporally, keeping daily readings (I also run .aggregate_temporal_period(period="day", reducer="median") in order to ensure one reading per day). The reasoning behind using resample_cube_temporal was to ensure the collections had consistent “t axis”, keeping days without readings “empty” (nan values).

7

When you connect to a federation, like openEO Platform with connection url openeo.cloud, you get information from and interact with that backend as a whole. In general, you can not “select” (as you put it) a particular “sub” backend.

If you want specific information about another backend, like the VITO backend, you should connect directly to it through openeo.vito.be

You also mention “vito-dev” here, but I think there is some additional confusion in play as well:

  • If you want to use openEO platform (with website https://openeo.cloud), you should connect your openeo client to https://openeo.cloud
  • when you connect to https://openeo.cloud there is some under the hood magic that will actually redirect your client to https://openeocloud.vito.be/openeo/1.0.0/, but that is still the openEO Platform federated backend. It’s just hosted under a vito.be domain, but that is an implementation detail of openEO platform. It does not mean you are connecting to the “VITO” openEO backend here (hosted at openeo.vito.be), that’s a completely separate deployment.
  • there is also a development instance of openEO platform at https://openeocloud-dev.vito.be/, which you seem to be using based on your posts, but that endpoint should not be used for general usage.

Long story short: for openEO platform:

  • connect to openeo.cloud
  • do not connect to openeocloud.vito.be or openeocloud-dev.vito.be URLs unless you know what you are doing