BUG: Convert grad/radian angular parameters to degrees in CRS.to_cf - #1643
Open
charan-rathore wants to merge 2 commits into
Open
charan-rathore wants to merge 2 commits into
charan-rathore wants to merge 2 commits into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1641.
Problem
CRS.to_cf()wrote angular parameter values (prime meridian longitude,longitude/latitude of natural origin, standard parallel) in whatever unit
the CRS defines them in. For CRSs with grad angular units such as the
French Lambert zones (EPSG:27571/27572/27573, NTF Paris datum), the CF dict
contained values like
standard_parallel = 52.0andlongitude_of_prime_meridian = 2.5969213- grad numbers in fields that CFexpects to be degrees. Round-tripping through
CRS.from_cfthenreinterpreted those numbers as degrees and the reprojection was off by
hundreds of kilometers.
Fix
Added a shared
_to_degrees()helper inpyproj/crs/_cf1x8.pythatconverts grad and radian values to degrees using the parameter's unit
conversion factor, leaving degree values untouched.
CRS._to_dict()nowroutes angular parameters through it, and
CRS.to_cf()uses it forlongitude_of_prime_meridian.Tests
Three regression tests in
test/crs/test_crs_cf.py:test_to_cf__grad_units__converts_to_degrees: EPSG:27572 exportsstandard_parallel46.8 andlongitude_of_prime_meridian2.33722917.test_to_cf__grad_prime_meridian__converts_to_degrees:+proj=longlat +pm=parisexports the Paris prime meridian in degrees.test_cf_round_trip__grad_units: the from_cf round trip keeps thenatural-origin latitude in degrees and lands within 10 m of the direct
transform (previously ~579 km off).
Also added the change to
docs/history.rstunder Latest.Verification
run_tests.shclones the repo at the base, confirms the patch applies,installs the released pyproj 3.8.0 wheel (its
crs.pyand_cf1x8.pyarebyte-identical to the base commit, so the wheel exercises the same code the
patch changes), and runs master's
test/crs/test_crs_cf.pyagainst theinstalled wheel:
of the suite shows zero new failures compared with baseline.
Caveats
and after the patch. They come from running master's tests against the
3.8.0 wheel's bundled PROJ rather than a source build, not from this
change.
to_cfdoes not write anyscale-factor entry for this 1SP Lambert projection, so
from_cfdefaultsscale_factor_at_natural_originto 1.0 instead of the original0.99987742. That is a separate pre-existing gap (a missing CF field, not
a units bug) and is left out of scope here; the round-trip test asserts
within 10 m and documents this.
bundled PROJ 9.8.1; a source build against the system's PROJ was not run.