[PROJ] Intermediate steps due same datum transformation

[Oleg Bizin]

Even,

Thank you for the detailed answer!

I have a couple more clarifying questions.

More generally PROJ >= 6 will not use WGS 84 as a compulsory pivot in
> coordinate transformations

1. Is it correct that the  PROJ < 6 definitely uses WGS84 as a compulsory
pivot?

2. Currently, before your fix, for custom crs transformation to WGS84 may
perform, but  without significant impact on accuracy?


вт, 19 июл. 2022 г. в 17:33, Even Rouault <even.rouault at spatialys.com>:

> 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 listPROJ at lists.osgeo.orghttps://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/a6bb5398/attachment.htm>