Fix EWA resampling when input data is larger than the output area #398
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.
This PR fixes a bug that was only obvious with the new dask implementation of the EWA resampler and only with data that had a very large input size. In my Polar2Grid use cases this showed up with the MiRS reader where we set the weight delta max to 100.0 (that's 100 output grid cells). We expect an image like:
But were getting this:
The "feathering" near the top is expected as this data gets to high latitudes and this is a latlong output AreaDefinition. However, the vertical line in the second image is not expected. What is actually happening is that the EWA algorithm was discarding any input pixels that were to the left or below the output grid. The way the dask implementation works means that there are a lot more of these "edge" cases in the middle of the final output image. These pixels could still have an effect on the final image due to them have an elliptical weight that they apply. So even a pixel that is 1 pixel to the left of the output grid might have an effect on a lot of pixels if the weight delta max (the extent to which an input pixel has an effect) is larger than 1 (1 pixel). Although this issue was more obvious with the dask EWA implementation it does actually effect the first and last columns of all EWA output.
While fixing this I also noticed another small possible bug with how kwargs were handled in the dask EWA implementation and have fixed that. I will try to add a test tomorrow. This was definitely not TDD as I didn't even know what was causing the problem in order to write a failing test.
This fix may interest @owenlittlejohns who I think had issues with vertical lines over the anti-meridian too.
git diff origin/main **/*py | flake8 --diff