<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">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">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">mdsumner@gmail.com</a></div></div></div></div>