<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Shawn,</p>
    <p>The results depends on which PROJ grids are available on your
      system (or if you allowed network access).</p>
    <p>1) The result you get with GDAL 1.10 can be reproduced with
      modern PROJ versions by allowing (and restricting) to using the
      CONUS / us_noaa_conus.tif grid which corresponds to the "NAD27 to
      WGS 84 (79)" EPSG transformation, with an advertized accuracy of
      5.0 m:<br>
    </p>
    <p>$ echo 32.804191 -117.258911 0 | PROJ_NETWORK=ON cct -d 8
      +proj=pipeline +step +proj=axisswap +order=2,1 +step
      +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift
      +grids=us_noaa_conus.tif +step +proj=unitconvert +xy_in=rad
      +xy_out=deg +step +proj=axisswap +order=2,1<br>
      32.80423938   -117.25978145    0.00000000           inf</p>
    <p>2) The result you get with GDAL 3.4.2 / PROJ 8.1.1 can be
      actually reproduced by using only the "NAD27 to WGS 84 (6)" EPSG
      Helmert transformation, with an advertized accuracy of 7.0 m,
      which is the most precise one in the absence of any grid:</p>
    <p>$ echo 32.804191 -117.258911 | cs2cs -d 8 NAD27 WGS84<br>
      32.80423884    -117.25976448 0.00000000<br>
    </p>
    <p>or explicitly with the pipeline show by "projinfo NAD27 WGS84 
      --bbox -118,32,-117,33 --spatial-test intersects --single-line":<br>
    </p>
    <p>$ echo 32.804191 -117.258911 0 |  cct -d 8 +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=clrk66
      +step +proj=helmert +x=-8 +y=159 +z=175 +step +inv +proj=cart
      +ellps=WGS84 +step +proj=pop +v_3 +step +proj=unitconvert
      +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1<br>
      32.80423884   -117.25976448    0.00000000           inf</p>
    <p>3) You would get the """"most precise result"""" (with lots of
      quotes, because this is highly subjective, and assumes that
      NAD83(HARN) is equivalent to WGS 84, according to the comment in
      the EPSG database) with the "NAD27 to WGS 84 (41)" EPSG
      transformation, with an advertized accuracy of 1.5m, which
      combines the CONUS grid and us_noaa_cshpgn:</p>
    <p>$ echo 32.804191 -117.258911 | PROJ_NETWORK=ON cs2cs -d 8 NAD27
      WGS84<br>
      32.80424065    -117.25978105 0.00000000</p>
    <p>or explicitly with the pipeline show by "projinfo NAD27 WGS84 
      --bbox -118,32,-117,33 --spatial-test intersects --single-line":</p>
    <p>$ echo 32.804191 -117.258911 0 | PROJ_NETWORK=ON cct -d 8
      +proj=pipeline +step +proj=axisswap +order=2,1 +step
      +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift
      +grids=us_noaa_conus.tif +step +proj=hgridshift
      +grids=us_noaa_cshpgn.tif +step +proj=unitconvert +xy_in=rad
      +xy_out=deg +step +proj=axisswap +order=2,1<br>
      32.80424065   -117.25978105    0.00000000           inf<br>
    </p>
    <p>==> All those results are valid. Some are more precise than
      others, under certain assumptions... But basically speaking about
      WGS 84 introduces an intrinsic inaccuracy of about 2 meters (cf
      <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=M2ck3cAGvhg">https://www.youtube.com/watch?v=M2ck3cAGvhg</a>). I don't think there
      are any published time-dependent transformations for NAD27 to
      WGS84 or any of its realization.<br>
    </p>
    <p>Even<br>
    </p>
    <div class="moz-cite-prefix">Le 24/08/2024 à 03:14, Fox, Shawn D
      (US) via gdal-dev a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:20240824011409.B40636142C92@lists.osgeo.org">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator"
        content="Microsoft Word 15 (filtered medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-ligatures:standardcontextual;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello GDAL users.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I have noticed that from GDAL 1.10 – GDAL
          3.1.0 that gdaltransform is producing different results for
          NAD27 GCS to WGS84 GCS transformations.  The differences in
          longitude in the output is more significant.  Having tested
          the differences in feet between the points output from each
          version I can see a difference of ~5 feet primarily due to the
          change in the longitude value.  <o:p></o:p></p>
        <p class="MsoNormal"><o:p></o:p></p>
        <p class="MsoNormal">Would anyone look at the following results
          and share your thoughts about why the result of this
          transformation is different in a newer version?  Could this be
          related to the concept of WGS 84 realization being different
          in newer versions of GDAL?  I am also linking GDAL 3.4.2 with
          PROJ 8.1.1 at this time.  These results were produced with
          GDAL 3.4.2, but the same results occur with GDAL 3.1.0 as
          well.  GDAL 3.4.2 is what I am currently trying to upgrade
          to.  The results from the C++ programming API are similar in
          difference.  I just used gdaltransform for the purposes of
          this message because it was a more convenient way of producing
          something that others might be able to reproduce.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><b>GDAL 1.10.0 results<o:p></o:p></b></p>
        <p class="MsoNormal">./gdaltransform -s_srs NAD27 -t_srs WGS84<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">-117.258911 32.804191<o:p></o:p></p>
        <p class="MsoNormal">-117.2597<span style="color:red">8144845</span>
          32.80423<span style="color:red">93819884</span>
          1.32247805595398e-07<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><b>GDAL 3.4.2 results<o:p></o:p></b></p>
        <p class="MsoNormal">./gdaltransform -s_srs NAD27 -t_srs WGS84<o:p></o:p></p>
        <p class="MsoNormal">-117.258911 32.804191<o:p></o:p></p>
        <p class="MsoNormal">-117.2597<span style="color:red">64476223</span>
          32.80423<span style="color:red">88409449</span> 0<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I have read that the support for specifying
          epochs related to realizations is not available until GDAL
          3.8.0. 
          <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Here are some references I’ve read so far.<o:p></o:p></p>
        <p class="MsoNormal"><a
href="https://ascelibrary.org/doi/10.1061/%28ASCE%29SU.1943-5428.0000389"
            moz-do-not-send="true">Transforming between WGS84
            Realizations | Journal of Surveying Engineering | Vol 148,
            No 2 (ascelibrary.org)</a><o:p></o:p></p>
        <p class="MsoNormal"><a
href="https://gdal.org/development/rfc/rfc81_coordinate_epoch.html"
            moz-do-not-send="true">RFC 81: Support for coordinate epochs
            in geospatial formats — GDAL documentation</a><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Thanks,<o:p></o:p></p>
        <p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black;mso-ligatures:none">Shawn
            Fox<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black;mso-ligatures:none">San
            Diego, CA</span><span
            style="font-size:8.0pt;mso-ligatures:none">
          </span><span style="mso-ligatures:none"><o:p></o:p></span></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>