Skip to content
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

Fix EWA resampling when input data is larger than the output area #398

Merged
merged 2 commits into from
Nov 18, 2021

Conversation

djhoese
Copy link
Member

@djhoese djhoese commented Nov 18, 2021

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:

image

But were getting this:

image

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.

  • Closes #xxxx
  • Tests added
  • Tests passed
  • Passes git diff origin/main **/*py | flake8 --diff
  • Fully documented

@djhoese djhoese added the bug label Nov 18, 2021
@codecov
Copy link

codecov bot commented Nov 18, 2021

Codecov Report

Merging #398 (e2cf8af) into main (d219e1f) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #398   +/-   ##
=======================================
  Coverage   93.80%   93.81%           
=======================================
  Files          65       65           
  Lines       11061    11076   +15     
=======================================
+ Hits        10376    10391   +15     
  Misses        685      685           
Flag Coverage Δ
unittests 93.81% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pyresample/ewa/dask_ewa.py 90.98% <100.00%> (ø)
pyresample/test/test_ewa_fornav.py 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d219e1f...e2cf8af. Read the comment docs.

@coveralls
Copy link

coveralls commented Nov 18, 2021

Coverage Status

Coverage increased (+0.009%) to 93.619% when pulling e2cf8af on djhoese:bugfix-ewa-zero into d219e1f on pytroll:main.

@djhoese
Copy link
Member Author

djhoese commented Nov 18, 2021

Got approval from Panu on slack. Merging now and then making a patch release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants