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

GeogCS.as_cartopy_projection handling non-Earth planets #4497

Merged
merged 9 commits into from
Jan 20, 2022

Conversation

wjbenfold
Copy link
Contributor

🚀 Pull Request

Description

Fixes #4408 by passing the GeogCS as a globe to the cartopy.crs.PlateCarree constructor


Consult Iris pull request check list

@wjbenfold
Copy link
Contributor Author

Currently the introduced test fails because Cartopy doesn't appear to pick up the central longitude all the way through (see example below). It's sort of there, but not fully. Don't know whether to make the test less stringent, stop trying to pass through the central longitude at all, or do something else.

>>> gcs = GeogCS(6000000, 6000000, longitude_of_prime_meridian=30)
>>> gcs.__dict__
{'semi_major_axis': 6000000.0, 'semi_minor_axis': 6000000.0, 'inverse_flattening': 0.0, 'longitude_of_prime_meridian': 30.0}
>>> pc = gcs.as_cartopy_projection()
>>> pc
<Derived Projected CRS: +proj=eqc +a=6000000.0 +b=6000000.0 +lon_0=30.0 +t ...>
Name: unknown
Axis Info [cartesian]:
- E[east]: Easting (unknown)
- N[north]: Northing (unknown)
- h[up]: Ellipsoidal height (metre)
Area of Use:
- undefined
Coordinate Operation:
- name: unknown
- method: Equidistant Cylindrical (Spherical)
Datum: unknown
- Ellipsoid: unknown
- Prime Meridian: Reference meridian

>>> pc.prime_meridian
PRIMEM["Reference meridian",0,
    ANGLEUNIT["degree",0.0174532925199433,
        ID["EPSG",9122]]]
>>> pc.prime_meridian.longitude
0.0

@wjbenfold
Copy link
Contributor Author

As well as the test I know is failing (that's my new one), there's also one failing in test_mapping because it relies on getting a vanilla PlateCarree back from as_cartopy_projection rather than one the right size for the cube. What's the best fix for this?

@wjbenfold
Copy link
Contributor Author

DeepDiff of a PlateCarree with a lon_0 of 180 with one of 0, for context

Value of root._proj4_params['lon_0'] changed from 180 to 0.
Value of root.proj4_init changed from "+ellps=WGS84 +a=6378137.0 +proj=eqc +lon_0=180 +to_meter=111319.4907932736 +vto_meter=1 +no_defs" to "+ellps=WGS84 +a=6378137.0 +proj=eqc +lon_0=0 +to_meter=111319.4907932736 +vto_meter=1 +no_defs".
Value of root.srs changed from "+proj=eqc +ellps=WGS84 +a=6378137.0 +lon_0=180 +to_meter=111319.4907932736 +vto_meter=1 +no_defs +type=crs" to "+proj=eqc +ellps=WGS84 +a=6378137.0 +lon_0=0 +to_meter=111319.4907932736 +vto_meter=1 +no_defs +type=crs".

@wjbenfold
Copy link
Contributor Author

The fix for the failing test in test_mapping seems somewhat circular, in that the test now uses very similar logic to the function it's testing. Seems fine though? The other option is to just remove that assert from the test, though maybe it's important to check that PlateCarree is the default?

Copy link
Contributor

@stephenworsley stephenworsley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

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

Successfully merging this pull request may close these issues.

Conversion between projections & coordinate systems does not always preserve the ellipsoid.
2 participants