<div dir="ltr">Even,<div><br></div><div>Thank you for the detailed answer!<br></div><div><br></div><div>I have a couple more clarifying questions.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">More generally PROJ >= 6 will not use WGS 84 as a compulsory pivot in coordinate transformations</blockquote><div>1. Is it correct that the PROJ < 6 definitely uses WGS84 as a compulsory pivot?</div><div><br></div><div>2. Currently, before your fix, for custom crs transformation to WGS84 may perform, but without significant impact on accuracy?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 19 июл. 2022 г. в 17:33, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Oleg,</p>
<p>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)</p>
<p>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.</p>
<p>If you play with the projinfo utility<br>
</p>
<p>$ projinfo -s EPSG:4284 -t EPSG:28411<br>
Candidate operations found: 1<br>
-------------------------------------<br>
Operation No. 1:<br>
<br>
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.<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=axisswap +order=2,1<br>
+step +proj=unitconvert +xy_in=deg +xy_out=rad<br>
+step +proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0
+ellps=krass<br>
+step +proj=axisswap +order=2,1<br>
<br>
WKT2:2019 string:<br>
CONVERSION["6-degree Gauss-Kruger zone 11",<br>
METHOD["Transverse Mercator",<br>
ID["EPSG",9807]],<br>
PARAMETER["Latitude of natural origin",0,<br>
ANGLEUNIT["degree",0.0174532925199433],<br>
ID["EPSG",8801]],<br>
PARAMETER["Longitude of natural origin",63,<br>
ANGLEUNIT["degree",0.0174532925199433],<br>
ID["EPSG",8802]],<br>
PARAMETER["Scale factor at natural origin",1,<br>
SCALEUNIT["unity",1],<br>
ID["EPSG",8805]],<br>
PARAMETER["False easting",11500000,<br>
LENGTHUNIT["metre",1],<br>
ID["EPSG",8806]],<br>
PARAMETER["False northing",0,<br>
LENGTHUNIT["metre",1],<br>
ID["EPSG",8807]],<br>
ID["EPSG",16211]]<br>
</p>
<p>==> no datum transformation applied</p>
<p><br>
</p>
<p>$ 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"<br>
Candidate operations found: 1</p>
<p>Note: using '--spatial-test intersects' would bring more results
(11)<br>
-------------------------------------<br>
Operation No. 1:<br>
<br>
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.<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=axisswap +order=2,1<br>
+step +proj=unitconvert +xy_in=deg +xy_out=rad<br>
+step +proj=push +v_3<br>
+step +proj=cart +ellps=krass<br>
+step +proj=helmert +x=25 +y=-141 +z=-78.5 +rx=0 +ry=-0.35
+rz=-0.736 +s=0<br>
+convention=coordinate_frame<br>
+step +inv +proj=helmert +x=25 +y=-141 +z=-78.5 +rx=0 +ry=0.35
+rz=0.736 +s=0<br>
+convention=position_vector<br>
+step +inv +proj=cart +ellps=krass<br>
+step +proj=pop +v_3<br>
+step +proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0
+ellps=krass<br>
<br>
[...]</p>
<p>Her's a datum transformation is applied due to the +towgs84
clause. Before the fix I've just submitted in
<a href="https://github.com/OSGeo/PROJ/pull/3265" target="_blank">https://github.com/OSGeo/PROJ/pull/3265</a>, 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.</p>
<p><br>
</p>
<p>If both sides used the same +towgs84, it is optimized away:</p>
<p>$ 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" <br>
</p>
<p>Candidate operations found: 1<br>
-------------------------------------<br>
Operation No. 1:<br>
<br>
unknown id, unknown, 0 m, unknown domain of validity<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=unitconvert +xy_in=deg +xy_out=rad<br>
+step +proj=tmerc +lat_0=0 +lon_0=63 +k=1 +x_0=11500000 +y_0=0
+ellps=krass<br>
<br>
<br>
</p>
<p>Even<br>
</p>
<div>Le 19/07/2022 à 15:39, Oleg Bizin a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
I want to clarify for myself the question about the work of the
library under the hood.<br>
I have a lot of work with QGIS which uses the library as a
reprojecting mechanism.<br>
<br>
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?<br>
<br>
For example, if I project data from <i>EPSG 4284 Pulkovo 1942</i> to<i> EPSG
28411 Pulkovo 1942 / Gauss-Kruger zone 14 </i>which both on
Pulkovo 42 datum<br>
the pipeline looks like this?
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div> EPSG 4284 > WGS84 > EPSG 28411</div>
<div><br>
</div>
</blockquote>
<div>or in case of custom CRS like this:</div>
<div><br>
+proj=tmerc +lat_0=0 +lon_0=xxxx +k=1 +x_0=xxxxx +y_0=xxxx +<b>ellps=krass
+towgs84</b>=25,-141,-78.5,0,0.35,0.736,0 +units=m +no_defs
</div>
<div><br>
</div>
<div> here I see an explicit to WGS clause<br>
<br>
</div>
<div>Or in this case intermediate steps to the universal WGS 84
are not performed?<br>
</div>
<div><br>
</div>
<div>Thanks!</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
PROJ mailing list
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div>