Thanks Even,
looks like a good workaround for the moment. Hopefully, the USGS will update
their files accordingly.
Thanks Kirk for kicking this up. I'm sure it is not trivial to fix such an
issue for a national dataset.
Have a great day,Conrad
On Friday, March 22, 2024 at 04:57:03 AM EDT,
I put in a ticket to the USGS National Map help desk so they'll know it
needs to be fixed. I'm sure some USGS folks watch this forum too.
Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences Program
Phone: 843-284-6962 (email preferred)
coast.noaa.gov/digitalcoast
[he/him]
Hi,
having looked at the file, I believe GDAL behaves correctly given the
metadata in the file. This is clearly a unit type attached to the Band,
and it should be corrected by the data producer to reflect what is
really used in it
One way to correct it on your side is for example this
Le 21/03/2024 à 21:45, Conrad Bielski via gdal-dev a écrit :
Hello GDALers,
I have a question about reading USGS 3DEP (3D Elevation Program) data.
Inside of this data, a GEOTIFF tag 42114 is provided which is causing
problems with datum shifts.
There's no such thing as a GEOTIFF tag 42114.
Hello GDALers,
I have a question about reading USGS 3DEP (3D Elevation Program) data. Inside
of this data, a GEOTIFF tag 42114 is provided which is causing problems with
datum shifts.
So when I use GDAL to compute the datum shifts, the tag is read and interprets
that the DEM is showing
