[PROJ] Intermediate steps due same datum transformation

[Even Rouault]

Oleg,

When transforming CRS with the same datum, no datum transformation is 
done. More generally PROJ >= 6 will not use WGS 84 as a compulsory pivot 
in coordinate transformations (it might use it when transforming between 
CRS of datum A and B, that there's no known datum transformation between 
them but both have recorded transformations to WGS 84)

The PROJ.4 string representation with the +towgs84= is a legacy one, not 
used by PROJ internals, unless you specify one of the CRS from it.

If you play with the projinfo utility

$ projinfo -s EPSG:4284 -t EPSG:28411
Candidate operations found: 1
-------------------------------------
Operation No. 1:

EPSG:16211, 6-degree Gauss-Kruger zone 11, 0 m, Between 60°E and 66°E, 
northern hemisphere between equator and 84°N, onshore and offshore.

PROJ string:
+proj=pipeline
   +step +proj=axisswap +order=2,1
   +step +proj=unitconvert +xy_in=deg +xy_out=rad
   +step +proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0 
+ellps=krass
   +step +proj=axisswap +order=2,1

WKT2:2019 string:
CONVERSION["6-degree Gauss-Kruger zone 11",
     METHOD["Transverse Mercator",
         ID["EPSG",9807]],
     PARAMETER["Latitude of natural origin",0,
         ANGLEUNIT["degree",0.0174532925199433],
         ID["EPSG",8801]],
     PARAMETER["Longitude of natural origin",63,
         ANGLEUNIT["degree",0.0174532925199433],
         ID["EPSG",8802]],
     PARAMETER["Scale factor at natural origin",1,
         SCALEUNIT["unity",1],
         ID["EPSG",8805]],
     PARAMETER["False easting",11500000,
         LENGTHUNIT["metre",1],
         ID["EPSG",8806]],
     PARAMETER["False northing",0,
         LENGTHUNIT["metre",1],
         ID["EPSG",8807]],
     ID["EPSG",16211]]

==> no datum transformation applied


$ projinfo -s EPSG:4284 -t "+proj=tmerc +lat_0=0 +lon_0=63 +k=1 
+x_0=11500000 +y_0=0 +ellps=krass +towgs84=25,-141,-78.5,0,0.35,0.736,0 
+units=m +no_defs +type=crs"
Candidate operations found: 1

Note: using '--spatial-test intersects' would bring more results (11)
-------------------------------------
Operation No. 1:

unknown id, Pulkovo 1942 to WGS 84 (16) + Inverse of Transformation from 
unknown to WGS84 + unknown, unknown accuracy, Armenia; Azerbaijan; 
Belarus; Estonia - onshore; Georgia - onshore; Kazakhstan; Kyrgyzstan; 
Latvia - onshore; Lithuania - onshore; Moldova; Russian Federation - 
onshore; Tajikistan; Turkmenistan; Ukraine - onshore; Uzbekistan.

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=krass
   +step +proj=helmert +x=25 +y=-141 +z=-78.5 +rx=0 +ry=-0.35 +rz=-0.736 
+s=0
         +convention=coordinate_frame
   +step +inv +proj=helmert +x=25 +y=-141 +z=-78.5 +rx=0 +ry=0.35 
+rz=0.736 +s=0
         +convention=position_vector
   +step +inv +proj=cart +ellps=krass
   +step +proj=pop +v_3
   +step +proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0 
+ellps=krass

[...]

Her's a datum transformation is applied due to the +towgs84 clause. 
Before the fix I've just submitted in 
https://github.com/OSGeo/PROJ/pull/3265, PROJ wasn't smart enough here 
to detect that EPSG:4284 uses the same datum transformation, but 
expressed with a different convention.  The 2 chained Helmert 
transformations are almost a no-op. The difference in the result is 
typically sub-millimetric.


If both sides used the same +towgs84, it is optimized away:

$ projinfo -s "+proj=longlat +ellps=krass 
+towgs84=25,-141,-78.5,0,0.35,0.736,0 +no_defs +type=crs" -t 
"+proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0 +ellps=krass 
+towgs84=25,-141,-78.5,0,0.35,0.736,0 +units=m +no_defs +type=crs"

Candidate operations found: 1
-------------------------------------
Operation No. 1:

unknown id, unknown, 0 m, unknown domain of validity

PROJ string:
+proj=pipeline
   +step +proj=unitconvert +xy_in=deg +xy_out=rad
   +step +proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0 
+ellps=krass


Even

Le 19/07/2022 à 15:39, Oleg Bizin a écrit :
> Hi,
>
> I want to clarify for myself the question about the work of the 
> library under the hood.
> I have a lot of work with QGIS which uses the library as a 
> reprojecting mechanism.
>
> When there is reprojection between CRS with  the same datum, is the 
> intermediate transformation of datums to wgs84 used as an intermediate 
> step or not?
>
> For example, if I project data from /EPSG 4284 Pulkovo 
> 1942/   to/ EPSG 28411 Pulkovo 1942 / Gauss-Kruger zone 14 /which both 
> on Pulkovo 42 datum
> the pipeline looks like this?
>
>      EPSG 4284 > WGS84 > EPSG 28411
>
> or in case of custom CRS like this:
>
> +proj=tmerc +lat_0=0 +lon_0=xxxx +k=1 +x_0=xxxxx +y_0=xxxx 
> +*ellps=krass +towgs84*=25,-141,-78.5,0,0.35,0.736,0 +units=m +no_defs
>
>  here I see an explicit to WGS clause
>
> Or in this case  intermediate steps to the universal WGS 84 are not 
> performed?
>
> Thanks!
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220719/99574b7e/attachment-0001.htm>