-
Notifications
You must be signed in to change notification settings - Fork 390
rotated geodetic #33
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
rotated geodetic #33
Conversation
lib/cartopy/crs.py
Outdated
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.
The way this has been designed, the ellipse is not propagated as is the case for the superclass. I think it needs to be.
|
@bblay : There is an outstanding action on you before this can be merged. (handle ellipse and datum better) |
lib/cartopy/_crs.pyx
Outdated
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.
Seems strange that I should set the ellipse keyword, but it only kicks in if I provide proj params.
Worse, I don't think we should be exposing the user to the proj4_params - it is an implementation detail that we are using proj.4 under the hood.
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.
Seems strange...
Indeed. It looks a bit like a square peg has been driven into a round hole. Supplying the proj4_params argument completely circumvents the definition of the Geodetic class! One could now do: crs = Geodetic({'proj': 'tmerc', ...}) and end up with a "geodetic" CRS which is actually a transverse Mercator!
The way to avoid this would be to allow only the parameters relevant to the rotated geodetic, e.g.:
class Geodetic
def __init__(self, pole_longitude, pole_latitude, ellipse, datum)
But now the Geodetic class looks just like the RotatedGeodetic class! Which highlights the need for either:
- Make Geodetic a subclass of RotatedGeodetic.
- Get rid of the inheritance between Geodetic and RotatedGeodetic.
Out of those two I'd rather have option (2). It gives us what we need with the minimum of complexity.
|
Obviously, I have some concerns about the implementation details with regards to this PR, but I think this is a great new feature and I am very eager to merge! Thanks fro your work @bblay! |
|
Thanks, doing these actions. Why are Geodetic and Geocentric in _crs.pyx rather than crs.py? |
I don't think there's a reason they have to be in |
lib/cartopy/crs.py
Outdated
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.
And this one.
Support for rotated geodetic CRS.
For SciTools/iris#67