You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Cartopy bounds for EPSGProjection are wrong, and make the Projection unusable --- because how the bounds are to be determined depends on the type of projection involved: Stereographic, etc. Thus, EPSGProjection shouldn't really be a class, but a helper method to construct. (I was getting this problem with EPSG 3413)
For my purposes, I looked only at the Stereographic projection --- because that's what I'm using right now. A general solution for PROJ->Cartopy would be nice; but one that works with the projections I need right now is even better.
Looking at the Cartopy code, it looks like it's just PROJ underneath. Moreover... Cartopy's Stereographic class does a lot of useless stuff, in the sense that it defines its own parameter names, which map 1-to-1 onto PROJ's parameters. So it seemed that I could solve my problems by making my own simplified Stereographic class that didn't rename / remap parameters. I did it by taking the code from Cartopy's Stereographic, but simplifying the __init__() method. Now I can give it a dict of PROJ parameters, and it will create a Stereographic Projection directly; and it's simpler than the original, to boot. Great, problem solved!
As for my problems with EPSG projections... the problem was that the bounds checking in EPSGProjection are simply wrong for Polar stereogrpahic projections; of which EPSG3413 is one. The SOLUTION is to create an EPSG projection directly in PROJ; and then use my new Stereographic class instead of EPSGProjection. This is all encapsulated in my function crs. Eg:
Description
Two problems vexed me with Cartopy:
It would be REALLY useful to produce a Cartopy
Projection
directly from a PROJ description string / parameter dict (and by extension, from a WKT, since PROJ handles that). This has been requested and discussed numerous times before: Create Cartopy projection from pyproj.Proj #813, WIP: Addfrom_proj4
function to create CRS from PROJ.4 definitions #1023, MNT: Drop Python 3.4 from test matrix #926.The Cartopy bounds for
EPSGProjection
are wrong, and make the Projection unusable --- because how the bounds are to be determined depends on the type of projection involved: Stereographic, etc. Thus,EPSGProjection
shouldn't really be a class, but a helper method to construct. (I was getting this problem with EPSG 3413)https://stackoverflow.com/questions/54569028/ignore-projection-limits-when-setting-the-extent
Solution Approach
For my purposes, I looked only at the
Stereographic
projection --- because that's what I'm using right now. A general solution for PROJ->Cartopy would be nice; but one that works with the projections I need right now is even better.Looking at the Cartopy code, it looks like it's just PROJ underneath. Moreover... Cartopy's
Stereographic
class does a lot of useless stuff, in the sense that it defines its own parameter names, which map 1-to-1 onto PROJ's parameters. So it seemed that I could solve my problems by making my own simplifiedStereographic
class that didn't rename / remap parameters. I did it by taking the code from Cartopy'sStereographic
, but simplifying the__init__()
method. Now I can give it a dict of PROJ parameters, and it will create aStereographic
Projection directly; and it's simpler than the original, to boot. Great, problem solved!As for my problems with EPSG projections... the problem was that the bounds checking in
EPSGProjection
are simply wrong for Polar stereogrpahic projections; of whichEPSG3413
is one. The SOLUTION is to create an EPSG projection directly in PROJ; and then use my newStereographic
class instead ofEPSGProjection
. This is all encapsulated in my functioncrs
. Eg:Done, and done. See the code at:
https://github.com/pism/uafgi/blob/eaf/develop/uafgi/cartopyutil.py
Any thoughts on how this could be expanded into a more full / complete / general PR?
The text was updated successfully, but these errors were encountered: