He is trying to run a UDP on CDSE Federation. The UDP hardcodes a collection TERRASCOPE_S2_FAPAR_V2 (available on "terrascope" backend), but the aggregator does not inspect the UDP to discover that, so it naively dispatches the processing to the classic CDSE backend. This causes of course
OpenEoApiError: [404] CollectionNotFound: Collection 'TERRASCOPE_S2_FAPAR_V2' does not exist. (Upstream ref: 'r-2410102e12434ac3b03783069a2ce770') (ref: r-241010de909b4dbbbe700e87538c5464)
Workaround is the (currently experimental/non-standardized) job option
{
"_agg_force_backend": "terrascope"
}
to force the selection of "terrascope"
However, if the collection id was not hardcoded inside the UDP, but a parameter, then the aggregator would be able to detect that collection id. Probably best to stick this feature to a well defined parameter name collection_id
Issue brought up by @JanssenBrm .
He is trying to run a UDP on CDSE Federation. The UDP hardcodes a collection
TERRASCOPE_S2_FAPAR_V2(available on "terrascope" backend), but the aggregator does not inspect the UDP to discover that, so it naively dispatches the processing to the classic CDSE backend. This causes of courseWorkaround is the (currently experimental/non-standardized) job option
to force the selection of "terrascope"
However, if the collection id was not hardcoded inside the UDP, but a parameter, then the aggregator would be able to detect that collection id. Probably best to stick this feature to a well defined parameter name
collection_id