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

Prevent segfault in LambertAzimuthalEqualArea #1100

Merged
merged 2 commits into from
Aug 2, 2018

Conversation

ajdawson
Copy link
Member

@ajdawson ajdawson commented Aug 1, 2018

Computing the boundary of the Lambert azimuthal equal area projection requires finding the anitpode of the projection centre in lat and lon, shifting it a little bit in latitude then transforming to the native coordinate system. This shifting is required because the exact antipode is not within the target projection. The implementation of the shift allowed for out-of-range latitudes when the central latitude is less than -89.9 degrees. This change avoids shifting the antipode out-of-range of the PlateCarree projection before transforming to LambertAzimuthalEqualArea to compute the projection boundary.

Fixes #1099.

Avoid shifting the antipode out-of-range of the PlateCarree
projection before transforming to LambertAzimuthalEqualArea to
compute the projection boundary.
@dopplershift
Copy link
Contributor

The approach to me looks like a reasonable tweak to the original. Can you add the test case from #1099 as a test?

Copy link
Member

@pelson pelson left a comment

Choose a reason for hiding this comment

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

Works for me. Thanks @ajdawson! @dopplershift's suggestion of a simple test is worth the effort IMO.

crs = ccrs.LambertAzimuthalEqualArea(central_latitude=latitude)
expected = ('+ellps=WGS84 +proj=laea +lon_0=0.0 +lat_0={} '
'+x_0=0.0 +y_0=0.0 +no_defs'.format(latitude))
assert crs.proj4_init == expected

This comment was marked as resolved.

These tests produce the LamberAzimuthalEqualArea CRS with central
latitudes at the poles to ensure the extreme cases work as required.
@pelson pelson merged commit 00b65a1 into SciTools:master Aug 2, 2018
@pelson
Copy link
Member

pelson commented Aug 2, 2018

Thanks @ajdawson!

@mjbrodzik
Copy link

Thanks for the fast action on this. This is one of my first issues opened here. Can you please tell me how to figure out in which cartopy version I should expect to see the fix released?

@ajdawson
Copy link
Member Author

ajdawson commented Aug 2, 2018

You should expect to see it in 0.17.0, I don't know when that will be though.

If your use case can cope with using -89.9 as the central latitude then that is a possible workaround for the current version (e.g. might be ok for plotting, but not for more precise transform requirements).

@pelson
Copy link
Member

pelson commented Dec 5, 2018

We finally released v0.17 @mjbrodzik, so an update of your environment should see you right. 👍

@mjbrodzik
Copy link

Thank you! I've updated to 0.17.0 and confirmed that I can now initialize LamberAzimuthalEqualArea with central_latitude=-90.0.
Much appreciated.

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

Successfully merging this pull request may close these issues.

None yet

5 participants