Kirk Waters - NOAA Federal via gdal-dev
writes:
> Thanks for the explanation and tips. I'm not clear on how setting to 26988
> (Michigan North meters) would help. If I do a gdal_translate with that, it
> shows as being in New Zealand, just as Arc had done. It would certainly
> make lots more sens
Le 25/01/2024 à 17:08, Kirk Waters - NOAA Federal a écrit :
Even,
Thanks for the explanation and tips. I'm not clear on how setting to
26988 (Michigan North meters) would help.
Hopefully forcing 1.0 will fix the issue.
ah, I didn't realize that the "NAD83 / Michigan North" in your WKT was
*n
Even,
Thanks for the explanation and tips. I'm not clear on how setting to 26988
(Michigan North meters) would help. If I do a gdal_translate with that, it
shows as being in New Zealand, just as Arc had done. It would certainly
make lots more sense to actually put the data in a standard projection
Kirk,
perhaps you could try using -a_srs EPSG:26988+6360 instead of a full
WKT. That way GDAL will *not* write the projected parameter definitions,
but just reference the horizontal and vertical CRS codes:
Geotiff_Information:
Version: 1
Key_Revision: 1.1
Tagged_Information:
Mo
Kirk,
this is a complicated story indeed... What changed since
https://trac.osgeo.org/gdal/changeset/31405 is that OGC GeoTIFF 1.1 was
published, which mostly fixes issues with vertical CRS, which your CRS
uses. So by default GDAL 3.1 or later, when seeing a CompoundCRS write
it as GeoTIFF 1.
Hi,
I've run across an odd issue with GeoTIFFS using custom projections written
by GDAL and their interpretation in ArcPro. The specific case is doing a
projection for Michigan State Plane North using U.S. survey feet. [insert
embarrassing tale of another US agency wanting to always use survey feet
