-
Notifications
You must be signed in to change notification settings - Fork 48
Description
From @rhugonnet from here #911 (comment) :
Instead of a matrix/shift_... for affine methods, bias correction methods store either a fit_param that they optimize for the given the function fit_func to correct (can be anything, a 2D polynomial, a 1D sum of sinusoids). They can also use binning statistics (bin_ parameters) either before the fit, or by itself to derive a purely empirical correction (they apply the binning statistic piecewise or per-bin later on, depending on bin_apply).
The core logic is coded here (and used by every single function, including affine methods actually):
xdem/xdem/coreg/base.py # Option 1: Run fit and save optimized function parameters
This behaviour should make it fairly easy to cover them in BlockwiseCoreg, we just need to run the apply() of the block and it should behave correctly!
To be clear: Applying "aggregation" methods for BlockwiseCoreg.apply (what @marinebcht is working on) only makes sense for affine methods, for a BiasCorr it's always an independent apply per chunk.
The couple challenges are:
For the general case, apply() for a BiasCorr methods requires a bias_vars input (an array/raster the same size as the input) to be passed. We need to deal with this input out-of-memory (as unloaded Raster), and load it only block-by-block. We can use the same icrop logic we already have for this.
For some subclasses like Deramp or DirectionalBias, the bias_vars is not a user-input, but an input we derive ourselves based on the coordinates of the data, like done here and here. We need to ensure those work properly within a block (for instance, I think get_xy_rotated might re-set the initial coordinate to zero... But as long as "fit" received the same input, it should all be good, we just need to double-check).
And that's it I think! I hope I didn't miss anything 🙂