<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Will do.</div><div>Thanks!</div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>From: </b>"Even Rouault" <even.rouault@spatialys.com><br><b>To: </b>"Rahkonen Jukka (MML)" <jukka.rahkonen@maanmittauslaitos.fi>, "hays" <Hays.Barrett@gmail.com><br><b>Cc: </b>gdal-dev@lists.osgeo.org<br><b>Sent: </b>Tuesday, March 30, 2021 11:12:38 AM<br><b>Subject: </b>Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in data loss.<br></div><div><br></div><div data-marker="__QUOTED_TEXT__"><p>Jukka' suggestion is a good one. Using -tps solver or affine
      approximation -order 1 fixes the issue. The default behaviour with
      GCPs when there are 6 or more of them is to use the second order
      polynomial adjustment. The issue here is when computing output
      bounds. We actually compute two 2nd order polynomial adjustments:
      one from source image coordinates to georeferenced ones, and one
      from georeferenced ones to source image. The former one is used to
      compute the output bounds, but the second one is used to do
      warping. The issue with 2nd order polynomial is that those two
      transformers are generally not the inverse of each other... We
      should likely compute the source image coordinates ->
      georeferenced coordinates as an iterative inversion of the other
      one, so they are invertible. The first order polynomial / affine
      transformation hasn't that issue due to how affine transformation
      works. The TPS one isn't likely perfectly invertible but TPS
      transformation is  guaranteed to be exact at GCPs, so that
      diminishes the effect. But 2nd order polynomial has overshoots
      particularities that can cause the issue observed.</p>
    <p>Another workaround is to specify the desired output bounds with
      -te<br>
    </p>
    <p>Anyway, Hays, could you file an issue about that in
      <a href="https://github.com/OSGeo/gdal/issues" target="_blank" rel="nofollow noopener noreferrer">https://github.com/OSGeo/gdal/issues</a>, ideally copying over your
      web page (or pointing to it if it can remain stable), and pasting
      my above comment.</p>
    <p>Even<br>
    </p>
    <div class="moz-cite-prefix">Le 30/03/2021 à 18:51, Rahkonen Jukka
      (MML) a écrit :<br>
    </div>
    <blockquote>
      
      <div class="WordSection1">
        <p class="MsoNormal">Hi,</p>
        <p class="MsoNormal"> </p>
        <p class="MsoNormal"><span lang="EN-US">I did not have a close
            look into your ground control points but perhaps they are
            not very well distributed and therefore the default warping
            algorithm eats one corner of the image. Have a try with thin
            plate splin (-tps) instead.  There may be some bug, it does
            not feel right that some source data are lost with default
            algorithm.</span></p>
        <p class="MsoNormal"><span lang="EN-US"> </span></p>
        <p class="MsoNormal"><span lang="EN-US">-Jukka Rahkonen-</span></p>
        <p class="MsoNormal"><span lang="EN-US"> </span></p>
        <p class="MsoNormal"><span lang="EN-US"> </span></p>
        <div>
          <p class="MsoNormal"><b><span lang="EN-US">Lähettäjä:</span></b><span lang="EN-US"> Hays Barrett <a href="mailto:hays.barrett@gmail.com" target="_blank" rel="nofollow noopener noreferrer"><hays.barrett@gmail.com></a>
              <br>
              <b>Lähetetty:</b> tiistai 30. maaliskuuta 2021 19.32<br>
              <b>Vastaanottaja:</b> Rahkonen Jukka (MML)
              <a href="mailto:jukka.rahkonen@maanmittauslaitos.fi" target="_blank" rel="nofollow noopener noreferrer"><jukka.rahkonen@maanmittauslaitos.fi></a><br>
              <b>Kopio:</b> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="nofollow noopener noreferrer">gdal-dev@lists.osgeo.org</a><br>
              <b>Aihe:</b> Re: [gdal-dev] Adding gcps to a raster using
              gdal_translate can result in data loss.</span></p>
        </div>
        <p class="MsoNormal"><span lang="EN-US"> </span></p>
        <div>
          <div>
            <p class="MsoNormal">I put together a page that better
              explains the issue and used one of the actual images from
              our project.</p>
          </div>
          <p class="MsoNormal"><a href="https://haysbarrett.com/gdal_translate/" target="_blank" rel="nofollow noopener noreferrer">https://haysbarrett.com/gdal_translate/</a></p>
          <div>
            <p class="MsoNormal">Thanks for looking into this for me.</p>
          </div>
          <div>
            <p class="MsoNormal">-Hays</p>
          </div>
        </div>
        <p class="MsoNormal"> </p>
        <div>
          <div>
            <p class="MsoNormal">On Fri, Mar 26, 2021 at 2:59 PM
              jratike80 <<a href="mailto:jukka.rahkonen@maanmittauslaitos.fi" target="_blank" rel="nofollow noopener noreferrer">jukka.rahkonen@maanmittauslaitos.fi</a>>
              wrote:</p>
          </div>
          <blockquote>
            <p class="MsoNormal">Hi,<br>
              <br>
              Please give an exact example. Preferably with a raster
              that can be created<br>
              from command line with gdal_create followed by other
              required commands. Or<br>
              alternatively Python code that re-produces the issue.<br>
              <br>
              -Jukka Rahkonen-<br>
              <br>
              <br>
              <br>
              Hays Barrett wrote<br>
              > If the gcps stretch the image beyond the dimensions
              of the original raster<br>
              > it appears to clip the data that sits outside of the
              original raster<br>
              > dimensions rather than increase the raster dimensions
              to fit the stretched<br>
              > data . <br>
              > Is this the expected behavior? <br>
              > If so is there a way to increase the dimensions of a
              raster so there is no<br>
              > data loss? <br>
              > Thanks, <br>
              > -Hays <br>
              > <br>
              > _______________________________________________<br>
              > gdal-dev mailing list<br>
              <br>
              > <a href="mailto:gdal-dev@.osgeo" target="_blank" rel="nofollow noopener noreferrer">gdal-dev@.osgeo</a><br>
              <br>
              > <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank" rel="nofollow noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
              <br>
              <br>
              <br>
              <br>
              <br>
              --<br>
              Sent from: <a href="http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html" target="_blank" rel="nofollow noopener noreferrer">
http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html</a><br>
              _______________________________________________<br>
              gdal-dev mailing list<br>
              <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="nofollow noopener noreferrer">gdal-dev@lists.osgeo.org</a><br>
              <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank" rel="nofollow noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></p>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre">_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="nofollow noopener noreferrer">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank" rel="nofollow noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature">-- 
<a href="http://www.spatialys.com" target="_blank" rel="nofollow noopener noreferrer">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  
<br>_______________________________________________<br>gdal-dev mailing list<br>gdal-dev@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/gdal-dev<br></div></div></body></html>