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

Improvements in transformations from/to WGS 84 (Gxxxx) realizations and vertical <--> geog transormations #1608


Copy link

@rouault rouault commented Sep 12, 2019

Assorted set of improvements to:

  • make creation of a vertical CRS with a geoidgrid easier through the API (to avoid having to manually compose a PROJ string with +geoidgrid)
  • make horizontal transformations from/to WGS 84 (Gxxxx) realizations use the generic WGS 84 as intermediate, when there is no direct transformation from/to the particular WGS 84 realization. Currently we would fallback to a ballkpark transformation, which is clearly suboptimal. To achieve that, we insert no-op transformation between WGS 84 generic and WGS 84 (Gxxxx) in the PROJ namespace for that effect, as well as a new table geodetic_datum_preferred_hub so that when WGS 84 (Gxxxx) is in the source/target CRS, then WGS 84 generic is considered as an intermediate step.
  • when transforming between a vertical CRS (generally through a compound CRS) and a geographic CRS, when there is no direct vertical transformation between those 2 CRS, but there are transformations between the vertical CRS and other geographic CRS, then use those transformations as potential candidates for the vertical part of the transformation. This is better than doing a ballpark vertical transformation as currently done. Use case: NAD83+NAVD88 to WGS84

A few fixes:

  • the sorting function of transformations wasn't transitive, which could cause the sorting to not work properly
  • when tranforming from a compoundCRS whose vertical component is a BoundCRS, do not apply the horizontal transformation twice

rouault added 5 commits Sep 12, 2019
…nd b < c --> a < c), to get consistent results
Currently very few transformations from/to WGS84 (Gxxxx) are registered
in the EPSG database, and there isn't even transformations between WGS84 EPSG:4326
and those ones. Consequently transformations to those realizations often
ended up as no-operation, whereas going through WGS84 EPSG:4326 will bring
more meaningful results. So register those EPSG:4326<-->WGS 84 (Gxxx)
null transformations, and when having WGS 84 (Gxxx) as source/target,
consider EPSG:4326 as an intermediate.
This change has no effect on the existing direct transformations
from/to WGS 84 (Gxxx).
…eographic and vertical CRS

For example when transforming from NAD83+NAVD88 height to WGS84, there
is no transformation between NAVD88 height to WGS84. In that case,
use all potential transformations from NAVD88 height to another geographic CRS
for the vertical part.
…l component is a BoundCRS, do not apply the horizontal transformation twice
@rouault rouault force-pushed the improve_transforms_fromto_wgs84_gXXXX_realizations branch from 00457ed to e6eae43 Compare Sep 12, 2019
@kbevers kbevers merged commit 6dcbdb9 into OSGeo:master Sep 15, 2019
3 checks passed
@kbevers kbevers added this to the 7.0.0 milestone Sep 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants