-
Notifications
You must be signed in to change notification settings - Fork 96
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
Update EWA ll2cr_static to handle swaths crossing the anti-meridian. #376
Update EWA ll2cr_static to handle swaths crossing the anti-meridian. #376
Conversation
Codecov Report
@@ Coverage Diff @@
## main #376 +/- ##
==========================================
+ Coverage 93.52% 93.53% +0.01%
==========================================
Files 50 50
Lines 10406 10423 +17
==========================================
+ Hits 9732 9749 +17
Misses 674 674
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
pyresample/test/test_ewa_ll2cr.py
Outdated
|
||
# wrap values in lon_arr so -180 ≤ longitude (degrees east) ≤ 180 | ||
lon_arr[lon_arr > 180] -= 360.0 | ||
print(lon_arr[0]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left over print statement. Could you remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
D'oh! I've removed that now. Thanks.
I keep going back to this PR trying to figure out why the static ll2cr had this logic in it. I'm pretty sure this is some feature I was using in my old Polar2Grid software that was, at the end of the day, going against what users should be doing if an area(grid) is defined properly. I think we had a lot of cases where users like those in Alaska had data going over the anti-meridian and wanted to use a single global (-180 to 180) Area to resample to. If the data went over the anti-meridian they didn't want one huge global area, they only wanted the small part of the image that had the contiguous data. However, this really only makes sense for the "dynamic" ll2cr grids, not the static ones so... 🤷 |
1f158ff
to
1e3e300
Compare
Yeah - the Alaska use-case is exactly how we originally found this issue. Our service is basically doing what you outlined: making a big old global grid, that has a lot of empty space. It'd be nice to have a more truncated grid, but on the other hand, it's also nice not having a longitude discontinuity in the middle of the data. Tricky stuff! |
It should be possible (having tested it recently) to play with ...or I guess you could make two separate images one of the "left" side and one for the "right" and then put both...oh discontinuities 🤦 I'll plan on merging this tomorrow. I don't trust myself merging things late at night. |
Thanks again for this. I'll see if I can make a bug fix release to include this some time today. |
Just tried out v1.21.1. Works a treat. Thanks for the quick turnaround on the merge and deploy! |
This PR removes an
elif
condition in thell2cr_static
method, which would identify when source pixels were at least three quarters of the circumference of the target projection away from the target grid origin x coordinate. Data that satisfied this condition were then incremented by the projection circumference.For swaths that cross the anti-meridian, this meant data with longitudes greater than three quarters of the target projection circumference were being shifted out of the target grid, and therefore the data were being omitted.
git diff origin/main **/*py | flake8 --diff