[gdal-dev] gdalwarp across the antimeridian with a source extent >180E

[Michael Sumner]

I forgot to mention that it needs earthdata credentials set up, basically
your "Authorization: Bearer <token>" in GDAL_HTTP_HEADERS or similar
config.

https://urs.earthdata.nasa.gov/documentation/for_users/user_token

You can't download or stream these files without that set or logging in
(the file used is indexed here:
https://cmr.earthdata.nasa.gov/virtual-directory/collections/C1996881146-POCLOUD/temporal/2024/01/01
)

I also crafted a gist to keep the formatting easier to copy paste:

https://gist.github.com/mdsumner/4ab86d52dd981621ad508297ba1a409c

Cheers, Mike



On Sat, Jun 1, 2024 at 4:19 PM Michael Sumner <mdsumner at gmail.com> wrote:

> This data source has an odd georeferencing, it's a 36000x17999 raster in
> the extent -179.995 -89.995 180.005 89.995.
>
> vrt://NETCDF:/vsicurl/
> 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
>
> (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).
>
> But also the x registration is half a cell to the east from what you would
> expect.
>
> 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.
>
> 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).
>
> gdalwarp $dsn -te 173.00 -19.85 185.00 -15.00 out1.tif -co COMPRESS=LZW
>
> 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.
>
>
> vrt://NETCDF:/vsicurl/
> 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
>
> gdalwarp $dsnfix -te 173.00 -19.85 185.00 -15.00 out2.tif -co COMPRESS=LZW
>
>
> 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.
>
> The compressed file sizes reflect the missing data in the second one,
> these are 625K and 1.1Mb.
>
> 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.
>
> 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).
>
> Cheers, Mike
>
> --
> Michael Sumner
> Research Software Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsumner at gmail.com
>


-- 
Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240601/fa94475b/attachment.htm>