I’m Bjørn from the DHIS2.org team at the University of Oslo. We’re building the Open Climate Service, a data backend that makes climate and Earth observation datasets available for health and climate-smart decision-making in low- and middle-income countries. Our stack is built on FastAPI, Zarr v3, Icechunk, and Python 3.13.
We recently tested integrating openEO as our processing layer — implementing the openEO HTTP API v1.2.0 directly in FastAPI, backed by openeo-pg-parser-networkx and openeo-processes-dask for process graph execution. The integration works well and gives us 120+ standard processes out of the box, which is a major benefit. We’re genuinely excited about the direction.
Friction we ran into
Getting openeo-processes-dask to install and run on our stack required a few workarounds:
- The
rqadeforestationdependency ships a wheel mislabelledpy3-none-anythat contains an x86-64 ELF.so, which fails at import time on macOS and ARM64 Linux. We filed the root-cause issue at EarthyScience/RQADeforestation.py#3 and opened openeo-processes-dask#377 suggesting it be made optional since it’s only used in the experimental module. - Several dependency constraints were stale against NumPy 2, Zarr v3, and Python 3.13, requiring version overrides. We worked around these but they should be updated upstream.
np.issubsctypeandnp.obj2sctypewere removed in NumPy 2.0 — we patched our vendor copy but the upstream code will fail for anyone on NumPy ≥2.
We’re currently running with a vendored copy of openeo-processes-dask with minimal patches applied. We’d much rather track upstream.
What we’d like to explore
We’d love to contribute the fixes back and discuss how we can cooperate going forward. Happy to share our implementation, the specific patches we applied, and test results. Is there a good way to get in touch with the maintainers, or a preferred channel for contributing?
Thanks for building this — it’s a genuinely useful library.
— Bjørn Sandvik, DHIS2 / University of Oslo