<div dir="ltr"><div>Even, thanks for the answer. The symlinks to the old grid names worked as expected. Thanks for reporting the fix to PROJ and for finally help me understand the libraries' dependencies.</div><div><br></div><div>Regards,<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">







<p>---<br></p><p><span>Juan Pedro Pérez Alcántara</span></p>
<p><span><a href="mailto:jp.perez.alcantara@gmail.com" target="_blank">jp.perez.alcantara@gmail.com</a></span></p></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 28 Mar 2021 at 21:17, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<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>Juan Pedro,</p>
    <p>the fact that the es_ign_SPED2ETV2.tif grid wasn't used turned
      out to be a PROJ issue, with a fix now queued in
      <a href="https://github.com/OSGeo/PROJ/pull/2619" target="_blank">https://github.com/OSGeo/PROJ/pull/2619</a></p>
    <p>One easy workaround is that you create symbol links:</p>
    <p>ln -s es_ign_SPED2ETV2.tif /usr/local/share/proj/PENR2009.gsb</p>
    <p>ln -s es_ign_SPED2ETV2.tif /usr/local/share/proj/BALR2009.gsb</p>
    <p>Regarding the differences in output between gdaltransform and
      cs2cs, this is just different rounding modes of the floating point
      values. You can change the number of decimals of cs2cs with the -d
      {number_of_decimals} switch<br>
    </p>
    <p>Even<br>
    </p>
    <div>Le 28/03/2021 à 19:57, Juan Pedro Pérez
      Alcántara a écrit :<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Even, thanks for replying, and Javier, thanks for the
          advice about the list etiquette. I will not change the subject
          in such events.</div>
        <div><br>
        </div>
        <div>I'm sure it's the only PROJ installation because I'm
          building the libraries in a Docker container. I've also
          conducted some more tests from zero, I've found out I've been
          using some old tests I wrote some time ago that were outdated
          and faulty, sorry about that. What follows is the detailed
          actions I've taken.</div>
        <div><br>
        </div>
        <div>With the IGN (Spanish National Geographic Institute)
          geodesic calculator I performed a EPSG 23030 (ED50 UTM 30N) to
          EPSG 25830 (ETRS89 UTM 30N) shift:</div>
        <div><br>
        </div>
        <div>235205.243 4142110.093  >  235094 4141906</div>
        <div>
          <div>
            <div>
              <div dir="ltr">
                <div dir="ltr">
                  <div>
                    <div dir="ltr">
                      <p>I take this as the target result.</p>
                      <p>I set PROJ_LIB to /usr/local/share/proj and
                        configured PROJ with a simple ./configure, no
                        options.</p>
                      <p>Using cs2cs:</p>
                      <p>cs2cs EPSG:23030 EPSG:25830 > 235094.09
                        4141905.02</p>
                      <p>which I suppose is a 7 parameters shift, which
                        is great, but not perfect, can do better with
                        the grid. Thus:</p>
                      <p>cs2cs +proj=utm +zone=30 +ellps=intl +units=m
                        +no_defs
                        +nadgrids=/usr/local/share/proj/es_ign_SPED2ETV2.tif
                        +to EPSG:25830 > 235094.00 4141906.00</p>
                      <p> which nails it. Again, my fault assuming PROJ
                        was using the grid by default.</p>
                      <p>Then I compiled GDAL with another flat
                        ./configure, it found a PROJ >= 6. Using
                        gdaltransform:</p>
                      <p>gdaltransform -s_srs EPSG:23030 -t_srs
                        EPSG:25830 > 235094.087184815
                        4141905.01683498</p>
                      <p>which is consistent with cs2cs. Using:<br>
                      </p>
                      <p>gdaltransform -s_srs "+proj=utm +zone=30
                        +ellps=intl +units=m +no_defs
                        +nadgrids=/usr/local/share/proj/es_ign_SPED2ETV2.tif"
                        -t_srs EPSG:25830 > 235094.000297496
                        4141905.99963473</p>
                      <p>which is consistent with cs2cs too.</p>
                      <p>Then, having solved this part of the issue, I
                        would like very much if you can advice me on how
                        to "tweak" default definitions of the SRS to
                        include the use of the grid by default, which
                        would be not absolutely necessary for my
                        application but a nice to have.</p>
                      <p>Also, just out of curiosity, why are PROJ and
                        GDAL yielding slightly different outputs (albeit
                        perfectly ok both)? Is GDAL doing its own
                        calculations besides PROJ? Forgive my lack of
                        deep understanding of the GDAL inner
                        architecture for I am an end user and not a
                        developer. Just curious.</p>
                      <p><br>
                      </p>
                      <p>Best regards,<br>
                      </p>
                      <p>---<br>
                      </p>
                      <p><span>Juan Pedro Pérez Alcántara</span></p>
                      <p><span><a href="mailto:jp.perez.alcantara@gmail.com" target="_blank">jp.perez.alcantara@gmail.com</a></span></p>
                    </div>
                  </div>
                </div>
              </div>
            </div>
            <br>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sat, 27 Mar 2021 at 21:32,
          Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote">Juan Pedro,<br>
          <br>
          <br>
          ><br>
          > I'm at a loss trying to understand the relationship
          between PROJ8, <br>
          > GDAL, and how to use TIFF national grids. So far my
          findings are:<br>
          ><br>
          > - PROJ8 is installed and cs2cs uses the grid to
          transform, performing <br>
          > an extremely accurate shift;<br>
          ><br>
          > - GDAL, compile on the above PROJ8, when using<br>
          > gdaltransform, yields less accurate<br>
          <br>
          There's no fundamental reason for transforms with
          gdaltransform being <br>
          less accurate than with cs2cs. You have to be much more
          specific with <br>
          the exact gdaltransform invokation you are trying. And are you
          really <br>
          sure that you use the PROJ version you think ? (check with ldd
          <br>
          libgdal.so on Linux)<br>
          <br>
          You can also set the PROJ_DEBUG=2 and CPL_DEBUG=ON environment
          variables <br>
          and look at the traces.<br>
          <br>
          Even<br>
          <br>
          <br>
          -- <br>
          <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
          My software is free, but my time generally not.<br>
          <br>
        </blockquote>
      </div>
    </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>