-
Notifications
You must be signed in to change notification settings - Fork 214
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
Consistency of crs.is_geographic between different EPSG representations #274
Comments
I have also been running into this, and it is due to the fact that, when a You can eg see this when displaying as WKT:
|
With changes in #263 >>> import pyproj
>>> crs = pyproj.Proj(pyproj.Proj('EPSG:4326').definition_string()).crs
>>> crs.is_geographic
False
>>> crs.source_crs.is_geographic
True |
The logic I have follows: https://github.com/OSGeo/gdal/blob/60ab2831abf9446c629b3a417a16cb35e7f41e63/gdal/ogr/ogrspatialreference.cpp#L7671-L7703 But, I wonder if there should also be a check if the original projection is bound and return geographic if it is bound and not a compound CRS. @rouault @kbevers |
Proposed solution: d69af25 |
Actually, that appears to be the way to go. I see |
…s; update CRS repr) (#263) * updated CRS repr for clarity; added BaseCRS for datum/ellipsoid/prime_meridian * add check to ensure input to CRS is a CRS (issue #267) * added support for compound CRS (issue #265) * updated repr to use EPSG code with 100% confidence for input & removed EPSG in repr * added docstrings for cython classes; cleaned up unused attributes in crs cython classes; added examples for CRS usage * fixed setting the coordinate operation name * change boolean like objects from int to bool * check if bound crs is geographic (issue #274) * added support for from_auth to CRS,Ellipsoid,PrimeMeridian,CoordinateOperation,Datum classes
@snowman2 Thanks for looking into it! |
Not a problem 👍. The solution is in master now if you want to give it a try. |
When creating an EPSG:4326 projection using a proj4 string, the value of the
proj.crs.is_geographic
property depends on whetherdefinition_string()
orcrs.to_proj4(4)
was used for initialization.It seems like the extra
towgs84=0,0,0
parameter in thedefinition_string
causes the problem. Shouldn't this be consistent? Or is this just another example of losing information when converting CRSes to proj4 strings?pyproj version is 2.1.3.
The text was updated successfully, but these errors were encountered: