<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Michael,</p>
    <p><a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/10108">https://github.com/OSGeo/gdal/pull/10108</a> will fix it.</p>
    <p>You can also workaround the issue by overriding the extent of the
      source dataset to be exactly -179.995,89.995,180.005,-89.995 with<br>
    </p>
    <p> "vrt://NETCDF:20240102090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analysed_sst?a_srs=EPSG:4326&a_ullr=-179.995,89.995,180.005,-89.995"</p>
    <p>The issue was twofolds:</p>
    <p>- the dataset uses lon/lat arrays with single precision
      floating-point numbers. Hence -179.99 gets actually read a a  
      read as -179.99000549316406 as a double-precision number, and thus
      the maxx - minxx difference was slightly over 360 degrees. I've
      added a heuristics to try to round -179.99-single-precision as
      -179.99-double-precision<br>
    </p>
    <p>- which defeated a heuristics in the warper to identify the
      center longitude of a dataset registered in a geographic CRS. This
      center longitude is just (min_lon + max_lon) / 2 if the dataset
      doesn't cover more than 360 degrees of longitude. This value, when
      computed, is passed as a hint OGRCoordinateTransformation so that
      it can post-correct longitudes to apply a +/- 360 degree offset,
      to be in the range of the source dataset. I've relaxed the sanity
      check to allow slighly more than 360 degrees</p>
    <p>Even<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 01/06/2024 à 08:19, Michael Sumner
      via gdal-dev a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAAcGz9-F2ttdk5AT+foCfiQXAXVyrcZhdm+R4uG0MGFAf5z6KQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">This data source has an odd georeferencing, it's a
        36000x17999 raster in the extent -179.995 -89.995 180.005
        89.995. <br>
        <br>
        vrt://NETCDF:/vsicurl/<a
href="https://archive.podaac.earthdata.nasa.gov/podaac-ops-cumulus-protected/MUR-JPL-L4-GLOB-v4.1/20240101090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analysed_sst?a_srs=EPSG:4326"
          moz-do-not-send="true" class="moz-txt-link-freetext">https://archive.podaac.earthdata.nasa.gov/podaac-ops-cumulus-protected/MUR-JPL-L4-GLOB-v4.1/20240101090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analysed_sst?a_srs=EPSG:4326</a><br>
        <br>
        (Why is it 17999: well there's one missing row - you'd expect
        18000 at 0.01 resolution and that manifests as half a cell short
        at the top and bottom). 
        <div><br>
        </div>
        <div>But also the x registration is half a cell to the east from
          what you would expect. <br>
          <br>
          It's correctly registered in that frame though, if we shift it
          west by the half cell I've verified visually that it "looks
          wrong" compared to coastlines etc. <br>
          <br>
          The point of this report is, gdalwarp misses the western
          window of data for a request across the antimeridian (there's
          no data in the output east of 180). <br>
          <br>
          gdalwarp $dsn -te 173.00 -19.85 185.00 -15.00 out1.tif -co
          COMPRESS=LZW<br>
          <br>
          If we "fix" the extent to be more longitudinally pleasing, we
          get the data east of the antimeridian, the map is properly
          filled either side of the antimeridian. <br>
          <br>
          <br>
          vrt://NETCDF:/vsicurl/<a
href="https://archive.podaac.earthdata.nasa.gov/podaac-ops-cumulus-protected/MUR-JPL-L4-GLOB-v4.1/20240101090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analysed_sst?a_srs=EPSG:4326&a_ullr=-180,89.995,180,-89.995"
            moz-do-not-send="true">https://archive.podaac.earthdata.nasa.gov/podaac-ops-cumulus-protected/MUR-JPL-L4-GLOB-v4.1/20240101090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.nc:analysed_sst?a_srs=EPSG:4326&a_ullr=-180,89.995,180,-89.995</a><br>
          <br>
          gdalwarp $dsnfix -te 173.00 -19.85 185.00 -15.00 out2.tif -co
          COMPRESS=LZW<br>
          <br>
          <br>
          Which is good, but as mentioned above the workaround means we
          are now half a cell out. It works fine for projected windows
          over the antimeridian in either situation.<br>
          <br>
          The compressed file sizes reflect the missing data in the
          second one, these are 625K and 1.1Mb. <br>
          <br>
          I'd like the warper to be able to correctly fill the data from
          the western window in the original case, we have determined
          that we can't feasibly "fix" the extent. </div>
        <div><br>
        </div>
        <div>Or maybe something else I'm missing? I don't *think*
          SAMPLE_GRID or SOURCE_EXTRA helps here. I know that I could
          craft a meridian-crossing combination in VRT but I'd rather
          like this workflow to work as-is.  (Chasing down the weird
          grid referencing is another project, but it's a really massive
          dataset so I'm pretty unconfident of that occurring). <br>
          <br>
          Cheers, Mike<br clear="all">
          <div><br>
          </div>
          <span class="gmail_signature_prefix">-- </span><br>
          <div dir="ltr" class="gmail_signature"
            data-smartmail="gmail_signature">
            <div dir="ltr">Michael Sumner<br>
              Research Software Engineer<br>
              Australian Antarctic Division<br>
              Hobart, Australia<br>
              e-mail: <a href="mailto:mdsumner@gmail.com"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">mdsumner@gmail.com</a></div>
          </div>
        </div>
      </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>