Define consistent nodata propagation for interp_points
and allow to return interpolator
#560
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most of the line changes in this PR are due to re-structuring, moving out functions of the
Raster
class (see #539, in preparation for #383) into their own module, here only those linked tointerp_points
.This PR also adds a nodata propagation scheme (as
scipy.interpolate.interpn
does not support nodata propagation natively except for methods "nearest" and "linear") and allows to return an interpolator that contains this nodata propagation (to optimize speed of iterative methods calling the same interpolator several times, such as DEM coregistration).It turned out that interpolation of
map_coordinates
with splines of order 3/5 does not match "cubic" or "quintic" ininterpn
, only order 0/1 do match for "nearest" and "linear", so all other are dropped. The nodata propagation and accuracy of results for values near the edge of NaNs is now tested thoroughly! 😄Resolves #559
Starts addressing #539 for functions related to
interp_points
TO-DO:
return_interpolator
,