OSGeo / PROJ / 2916
87%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 225
Run time 40s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
2916

push

travis-ci-com

rouault 
createOperations(): keep height/z value in Helmert transform between 3D CRS

This is the consequence of a private email thread between me, Joel Haasdyk and
Roger Lott. I initially raised that the GDA2020 technical manual advertized the
Helmert transformation between GDA94 to GDA2020 to be a 3D one, with example of
a test point where ellipsoidal heights where modified. It appears this was intended.

The corresponding record in EPSG uses the EPSG:9607 "Coordinate Frame rotation (geog2D domain)"
method between the 2D geographic CRS of GDA94 and GDA2020. From the email exchange,
it appears that there's a lot of legacy explaining that Helmert transformations
are registered only between 2D CRS, which doesn't mean that when applied to the
corresponding 3D CRS, the change in ellipsoidal height should be discarded. Related
to that, the EPSG database, while it has methods flagged "(geog3D domain)" never uses them.

So... this changeset slightly ammends PROJ behaviour to ignore the "(geog2D domain)" flag,
but only consider the dimensionality of the source & target CRS. However, for a EPSG
transformation, those are always 2D CRS, hence introduce the use3DHelmert_ hack when
we know that ultimately the 'real' source & target CRS are 3D.

I wouldn't be surprised if in more complex pipeline the above logic would be lacking.
But it fixes at least simple transformations.

37894 of 43911 relevant lines covered (86.3%)

44689.57 hits per line

Jobs
ID Job ID Ran Files Coverage
1 2916.1 (BUILD_NAME=linux_gcc DETAILS="linux, gcc") 0
86.3
 Travis Job 2916.1
Source Files on build 2916
Detailed source file information is not available for this build.