-
Notifications
You must be signed in to change notification settings - Fork 17
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
Allow regridding for projections in non-degree type units #178
Allow regridding for projections in non-degree type units #178
Conversation
Codecov Report
@@ Coverage Diff @@
## main #178 +/- ##
==========================================
+ Coverage 98.73% 98.75% +0.01%
==========================================
Files 33 33
Lines 3646 3680 +34
==========================================
+ Hits 3600 3634 +34
Misses 46 46
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Using |
This conversion ought to happen at this point: I would imagine that cartopy would be calling Proj here anyway. I think that in the case where units are supplied in meters, at this point cartopy describes the projection as being described in meters and is expecting data to be in meters. There is still a case that there could be more to be done to ensure that units are compatible with the coordinate system, but I'm not sure what it would mean for a coordinate to have a unit which disagreed with the coordinate system. The approach I've gone for is to treat the coordinate system as the single source of truth for a coordinate where it exists. This seems the simplest way to do things for the time being. |
Do you plan to add some testing to this PR? |
Yes, I have been thinking about adding tests. I think I would ideally want some OSGB data (or a subset of such data) to work with, since thats where this problem showed up. The closest I can find in iris-test-data seems to be transverse mercator (which I think OSGB is an instance of). If you have any other ideas of data to test this on let me know. |
@SciTools-incubator/esmf-regrid-devs This pull-request is stale due to a lack of activity in the last 90 days. Remove stale label or comment, otherwise this pull-request will close automatically in 7 days time. |
@Scit@SciTools-incubator/esmf-regrid-devs This stale pull-request has been automatically closed due to no community activity |
I think this is still worth getting done |
9c73b03
to
976a61c
Compare
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.
Thanks @stephenworsley, a few comments for you
standard_names=["projection_x_coordinate", "projection_y_coordinate"], | ||
units="m", | ||
) | ||
data = np.arange(n_lats_src * n_lons_src).reshape([n_lats_src, n_lons_src]) |
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.
Not for this PR: we do this so often I'm starting to wonder whether it's worth having a convenience for it.
Thanks @stephenworsley! |
Addresses #222
Some projections, like OSGB, have units which cannot be converted to degrees (i.e. meters) and cause regridding to fail. This PR assumes that where a coordinate system exists, units ought to already be compatible with it.