-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-organization of coreg.py
#327
Comments
Yes, I agree with those points. Below I outlined the main steps to be done, hopefully in logical order:
|
Adding some points after closing #158: |
Since #436, relevant for the re-org: Make subsampling consistent in |
Several ideas here in relation to the one-liner coregistration: #267 (review)
More generically:
Coreg
methods should live outside ofCoreg
classes for readability and flexibility (e.g., functions to estimate the horizontal shift, to deramp, etc). In other words allCoreg
methods should only be wrappers of already existing functions;fit.py
instead of directly callingscipy.optimize
, so that their tolerance and outputs are consistently tested, and that any type of optimization method can be used;np.ndarray
, they should still be optimized to function withRaster
objects (e.g., modifying the geotransform instead of resampling in case of a horizontal shift). To have a similar default behaviour fornp.ndarray
objects, we could potentially introduce a return of atransform
object as output ofapply()
.Maybe @adehecq has more specific things to add!
The text was updated successfully, but these errors were encountered: