createOperations(): do Helmert transformation in 2D when one of source or target CRS is compound

[rouault]

Fixes #4335

[pchilds]

Sorry, shouldn't the additional || condition here only pin if they are both Compound CRSs and have the same vertical CRS? E.g. one might be AHD (EPSG:5711), and the other AVWS (EPSG:9458).

[rouault]

Sorry, shouldn't the additional || condition here only pin if they are both Compound CRSs and have the same vertical CRS?

I was wondering too, and I'm not sure to be honest. There's a bit of ambiguity related to Helmert transformations in the EPSG dataset if they are intended to be applied in 2D only or 3D. There are different method codes in theory but the "(geog2D domain)" ones are always used, even in cases when they are 3D. So it seems safer to do 3D only when both sides are Geographic3D crs.

If I do, projinfo -s "GDA94 + AHD height" -t "GDA2020 + AVWS height" --spatial-test intersects, the default pipeline returned is

Operation No. 1:

unknown id, GDA94 to GDA2020 (1) + Inverse of GDA2020 to AHD height (1) + GDA2020 to AVWS height (2), 0.26 m, Australia - Australian Capital Territory, New South Wales, Northern Territory, Queensland, So
uth Australia, Tasmania, Western Australia and Victoria - onshore. Christmas Island - onshore. Cocos and Keeling Islands - onshore.

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +proj=push +v_3
  +step +proj=cart +ellps=GRS80
  +step +proj=helmert +x=0.06155 +y=-0.01087 +z=-0.04019 +rx=-0.0394924
        +ry=-0.0327221 +rz=-0.0328979 +s=-0.009994 +convention=coordinate_frame
  +step +inv +proj=cart +ellps=GRS80
  +step +proj=pop +v_3
  +step +proj=vgridshift +grids=au_ga_AUSGeoid2020_20180201.tif +multiplier=1
  +step +inv +proj=vgridshift +grids=au_ga_AGQG_20201120.tif +multiplier=1
  +step +proj=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

The push/pop +v_3 here seems at least consistent with the below pipeline which uses the horizontal grid for GDA94 to GDA2020:

Operation No. 2:

unknown id, GDA94 to GDA2020 (3) + Inverse of GDA2020 to AHD height (1) + GDA2020 to AVWS height (2), 0.3 m, Australia - Australian Capital Territory; New South Wales; Northern Territory; Queensland; South Australia; Tasmania; Western Australia; Victoria.


+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +proj=hgridshift +grids=au_icsm_GDA94_GDA2020_conformal.tif
  +step +proj=vgridshift +grids=au_ga_AUSGeoid2020_20180201.tif +multiplier=1
  +step +inv +proj=vgridshift +grids=au_ga_AGQG_20201120.tif +multiplier=1
  +step +proj=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

[pchilds]

I was wondering too, and I'm not sure to be honest. There's a bit of ambiguity related to Helmert transformations in the EPSG dataset if they are intended to be applied in 2D only or 3D. There are different method codes in theory but the "(geog2D domain)" ones are always used, even in cases when they are 3D. So it seems safer to do 3D only when both sides are Geographic3D crs.

I'm a bit uncertain on that too. I know for the Helmert transformation from GDA94 to GDA2020 we get a nation-wide 9cm vertical offset between the datums (though in this case we are just talking about horizontal datums, but their 3D equivalents do have height difference as the ITRF to which they are pinned is moving in a way that local heights change). I don't know if proj offers any pathways of helmert transforms between vertical datums though. I suspect it does, though they would be rare, e.g. the tunnel datum for the UK is 100 m below the spheroid.

[rouault]

know for the Helmert transformation from GDA94 to GDA2020 we get a nation-wide 9cm vertical offset between the datums

yes, looking at the GDA2020 technical manual (https://www.icsm.gov.au/sites/default/files/GDA2020%20Technical%20Manual%20V1.8_published_0.pdf , e.g. example page 29), ellipsoidal height change seems the thing to do. Fine tuning for this transformation in #4341