Backend portability: dimension names, band value scaling, and synchronous parameter binding

[emmanuelmathot]

Backend portability: dimension names, band value scaling, and synchronous parameter binding

Summary

While building reusable openEO UDPs (e.g NDCI cyanobacteria detection, with the same process graph executed against multiple backends for development previews and later registered as a UDP in APEx), we hit three distinct portability gaps that required client-side workarounds. The workarounds are not hard, but each would be unnecessary if the spec were a bit more prescriptive. Filing as one issue because they are tangled together in practice, but they are separable asks.

All three reduce to the same pattern: a process graph that works against backend A fails against backend B for reasons unrelated to the algorithm, forcing clients to query endpoint-specific metadata ahead of graph construction.

Context

• openEO API spec (master branch as of this writing).

• openEO Python client 0.x.

• Backends observed: Copernicus Data Space (openeo.dataspace.copernicus.eu), EOPF Explorer (api.explorer.eopf.copernicus.eu), a TiTiler-openEO development instance (openeo.ds.io).

• Backend portability: Dimension naming is recommended, not required #588

• Backend portability: Band-value scaling is unspecified in openEO, and not consistently surfaced via STAC #589

• Backend portability: Synchronous execution has no parameter-binding contract #590

Happy to

- Open separate issues if you prefer one per gap.

• Draft a spec PR for Gap 2 (the STAC raster:scale / raster:offset handshake seems the most tractable).

cc @soxofaan @m-mohr

[m-mohr]

Thanks @emmanuelmathot, many useful information. I think it would indeed be helpful to subdivide this into separate issues. We can add them as sub-issues to this one. I'll answer in the separate issues then.

[emmanuelmathot]

@m-mohr sub-issues created and description updated