Romain Hugonnet

After more thinking, I'm wondering if directly using https://docs.dask.org/en/latest/generated/dask.array.overlap.map_overlap.html would make more sense, even if for now our input arrays are not chunked in-memory. It would: - Make the functionality...

An additional point I just thought of: If resolving the bug involves removing the `warp_dem` function, that's for the best. It is likely responsible for artefacts seen in #584, and...

@adebardo I think we can close this since #707?

Sounds good to have those as class methods of the Raster objects, as for terrain attributes! 🙂 We have a Raster-type class for altitude differences, `dDEM`, that we use for...

Finally found more on this mysterious issue: The downloading only fails for the first notebook executed by Readthedocs that calls `DEM.to_vcrs()` (Reminder: it works fine locally). By default, this is...

The temporary fix in #666 works but is not ideal (adds useless code to `biascorr.md`, might break if we add a new page that executes before alphabetically), so re-opening this...

Additionally, would be a good moment to add more tests to avoid this happening again in the future.

OK, the cause is indeed that `BlockwiseCoreg` either applies or estimates the horizontal shift in the wrong direction contrary to classic `apply` (vertical unaffected), I don't understand why yet...

Even when the coregistration is applied in the right direction (which is not the case by default for `BlockwiseCoreg` somehow, even after #585, so probably an error in the original...

Yes those are the artefacts! The "stable" documentation is the latest release. The wrong direction compared to other apply appeared since #530, so it's in "latest": https://xdem.readthedocs.io/en/latest/advanced_examples/plot_blockwise_coreg.html