That's fantastic! Thank you Even!
On Sun, Sep 1, 2024 at 3:08 PM Even Rouault
wrote:
> Fixed per https://github.com/OSGeo/gdal/pull/10709 in 3.9 branch, and
> more extensive fix in master in https://github.com/OSGeo/gdal/pull/10708
>
> Even
>
> --
> http://www.spatialys.com
> My software is free
Fixed per https://github.com/OSGeo/gdal/pull/10709 in 3.9 branch, and
more extensive fix in master in https://github.com/OSGeo/gdal/pull/10708
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
Please disregard my previous message with the gdalinfo output. Here is the
correct one:
$ gdalinfo "dem.tif"
Driver: GTiff/GeoTIFF
Files: dem.tif
Size is 1541, 1335
Coordinate System is:
GEOGCRS["WGS 84",
ENSEMBLE["World Geodetic System 1984 ensemble",
MEMBER["World Geodetic System 198
$ gdalinfo dem.tif
Driver: GTiff/GeoTIFF
Files: dem.tif
Size is 1541, 1335
Coordinate System is:
GEOGCRS["WGS 84",
ENSEMBLE["World Geodetic System 1984 ensemble",
MEMBER["World Geodetic System 1984 (Transit)"],
MEMBER["World Geodetic System 1984 (G730)"],
MEMBER["World G
What is the gdalinfo output on dem.tif ?
Is this a bug? It appears that the data type change might be
influenced by the nodata value.
Yes, there is some logic to take the "union" of the largest data types
involved in the warping (but it should probably ignore nodata values
that are outside of
