Jeroen Dries

I also see this issue when doing: GDALRasterSource(path).reproject(crs) Where crs is Web Mercator and path is a global geotiff in EPSG:4326 with Extent(-180.0, -90.0, 180.0, 90.0). So I get this...

I would also be interested in this feature: users do not always need the full scene, in some cases they even require a few pixels only. Would be nice to...

A fix for this is being proposed in this pull request: https://github.com/Open-EO/openeo-processes/pull/106

Interesting idea! In fact, we already try to do something similar to offering this array api with out 'band math' functionality. But there the user has to mix some openEO...

Hi Michael, thanks for the feedback. This made me look at the Range implementation again, and I noticed that it is in fact an immutable class. Which makes me wonder...

@VincentVerelst this is certainly a possibility. I suggest that data engineering is free to extend this job manager as needed. Main reason not to do it would be to avoid...

Nice idea! This can help quite a bit in finding jobs again, maybe the same goes for job title? As default implementation, for title, we could just use the name...

The python requests library even supports this quite easily ``` from requests.adapters import HTTPAdapter, Retry retries = Retry(total=5,read=10,other=10,status=10, backoff_factor=0.1, status_forcelist=[ 502, 503, 504,404,429], method_whitelist=["HEAD", "GET", "OPTIONS","POST"]) session.mount('https://', HTTPAdapter(max_retries=retries)) session.mount('http://', HTTPAdapter(max_retries=retries))...

I would say aggregate_spatial preserves band names when going from raster to vector, so can we just copy that part of the metadata? Maybe @VincentVerelst can prepare a PR for...

This is there on backend side, we will of course have to keep XArrayDataCube around for quite a bit. Next step is to update documentation to favour UDF's without XArrayDataCube...