Skip to content

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