note how band("B02") and band("B08") were translated to array_element(..., index=1) and array_element(..., index=7) respectively.
This index based array_element usage is quite brittle as it depends on a predictable, consistent band order.
In the context of an openeo federation where federated collection from multiple participants are merged, it is unfortunately not straightforward to guarantee a predictable, consistent band listing (e.g see https://github.com/Open-EO/openeo-aggregator/issues/147)
Index based band math should be avoided as much as possible and label based array_element should become the default.
Some reasons it might still be useful to have index based: backend does not support label based (e.g. Terrascope backend in the past), or the client might be confused about the actual band names (e.g. after multiple possible band-name manipulating operations)
"Band math" is a often used feature in the openeo python client. For example, very roughly.:
This
res
cube will translate to a process graph with areduce_dimension
along the lines of:note how
band("B02")
andband("B08")
were translated toarray_element(..., index=1)
andarray_element(..., index=7)
respectively.This index based
array_element
usage is quite brittle as it depends on a predictable, consistent band order. In the context of an openeo federation where federated collection from multiple participants are merged, it is unfortunately not straightforward to guarantee a predictable, consistent band listing (e.g see https://github.com/Open-EO/openeo-aggregator/issues/147)Index based band math should be avoided as much as possible and label based
array_element
should become the default. Some reasons it might still be useful to have index based: backend does not support label based (e.g. Terrascope backend in the past), or the client might be confused about the actual band names (e.g. after multiple possible band-name manipulating operations)