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

Update EWA ll2cr_static to handle swaths crossing the anti-meridian. #376

Merged
merged 1 commit into from
Sep 16, 2021

Conversation

owenlittlejohns
Copy link
Contributor

@owenlittlejohns owenlittlejohns commented Sep 10, 2021

This PR removes an elif condition in the ll2cr_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.

@codecov
Copy link

codecov bot commented Sep 10, 2021

Codecov Report

Merging #376 (1e3e300) into main (031260c) will increase coverage by 0.01%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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              
Flag Coverage Δ
unittests 93.53% <100.00%> (+0.01%) ⬆️

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

Impacted Files Coverage Δ
pyresample/test/test_ewa_ll2cr.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 031260c...1e3e300. Read the comment docs.

@coveralls
Copy link

coveralls commented Sep 10, 2021

Coverage Status

Coverage increased (+0.01%) to 93.522% when pulling 1e3e300 on owenlittlejohns:fix-ewa-crossing-antimeridian into 031260c on pytroll:main.

@djhoese djhoese added the bug label Sep 13, 2021
@djhoese djhoese self-assigned this Sep 13, 2021

# wrap values in lon_arr so -180 ≤ longitude (degrees east) ≤ 180
lon_arr[lon_arr > 180] -= 360.0
print(lon_arr[0])
Copy link
Member

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?

Copy link
Contributor Author

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.

@djhoese
Copy link
Member

djhoese commented Sep 13, 2021

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... 🤷

@owenlittlejohns owenlittlejohns force-pushed the fix-ewa-crossing-antimeridian branch from 1f158ff to 1e3e300 Compare September 13, 2021 00:59
@owenlittlejohns
Copy link
Contributor Author

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!

@djhoese
Copy link
Member

djhoese commented Sep 13, 2021

It should be possible (having tested it recently) to play with +pm=180 in your PROJ.4 string definition. This basically makes the longitude space go from 0 to 360 instead of -180 to 180. With that you should be able to define your extents from something like 160 to 220 longitude. So while the data may cross the anti-meridian of the normal -180/180 space, it should be contiguous in this projection. The major downside though is that your geotiff (or other) image viewer has to support this PROJ parameter.

...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.

@djhoese djhoese merged commit 6a37a16 into pytroll:main Sep 16, 2021
@djhoese
Copy link
Member

djhoese commented Sep 16, 2021

Thanks again for this. I'll see if I can make a bug fix release to include this some time today.

@owenlittlejohns owenlittlejohns deleted the fix-ewa-crossing-antimeridian branch September 16, 2021 17:39
@owenlittlejohns
Copy link
Contributor Author

Just tried out v1.21.1. Works a treat. Thanks for the quick turnaround on the merge and deploy!

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