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:
ModelTiepointTag (2,3):
0 0 0
440720 3751320 0
ModelPixelScaleTag (1,3):
60 60 1
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,46): "NAD83 / Michigan North + NAVD88
height (ftUS)"
ProjectedCSTypeGeoKey (Short,1): PCS_NAD83_Michigan_North
VerticalCSTypeGeoKey (Short,1): Code-6360 (NAVD88 height (ftUS))
End_Of_Keys.
End_Of_Geotiff.
Even
Le 25/01/2024 à 16:17, Even Rouault via gdal-dev a écrit :
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.1, and this new GeoTIFF version was the
opportunity to remove writing the
ProjLinearUnitsInterpCorrectGeoKey=3059 hack, since using GeoTIFF 1.1
is a way to indicate that you're implementing correctly the standard.
If you force writing GeoTIFF 1.0 by adding -co GEOTIFF_VERSION=1.0,
GDAL will write the ProjLinearUnitsInterpCorrectGeoKey when needed,
and listgeo will show the "Unknown-3059 (Short,1): Unknown-1" geotiff key.
To know if a Geotiff is 1.0 or 1.1 with listgeo , look at the
Key_Revision in the 3rd line which will be 1.0 or 1.1
So I assume ArcPro doesn't specifically implement 1.1. Either they
implement GeoTIFF themselves, or they use GDAL < 3.1 that hasn't
GeoTIFF 1.1 explicit support
Even
Le 25/01/2024 à 15:24, Kirk Waters - NOAA Federal via gdal-dev a écrit :
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 regardless of state legislation or
that the federal government has been officially metric for a long
time]. For a file that should land in the Michigan upper peninsula,
ArcPro puts it in New Zealand. It appears the issue is that Arc is
interpreting the false easting as meters instead of survey feet. If I
do a define projection in ArcPro and make a custom projection, it
lands in the right place.
I used an old listgeo from the geotiff library to look at the tags
both in the original file and a copy that had define projection
applied to see what was different. They looked essentially the same,
including having the same value for the false easting. However, the
Arc version had an extra tag (3059) that wasn't in the GDAL produced
one. An internet search turned up this 13-year old GDAL issue
<https://trac.osgeo.org/gdal/ticket/3901>. If I understand it
correctly, a bug in GDAL was found that always used meters for the
false easting and northing. In addition to fixing that, a tag (3059)
was added to indicate this was fixed so software could differentiate
broken GDAL output from new output. It looks like Arc is looking for
this tag and if it's not there, false easting is assumed to be meters.
A few questions, assuming I interpreted that issue correctly:
1) Why is gdal not adding that 3059 tag? (GDAL command used is below)
2) If it's only supposed to be relevant to GDAL written files, why is
Arc writing it?
3) How do I get GDAL to add the tag?
Command used in file creation:
gdal_translate -a_srs 'COMPD_CS[PROJCS["NAD83 / Michigan
North",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS
1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",47.08333333333334],PARAMETER["standard_parallel_2",45.48333333333333],PARAMETER["latitude_of_origin",44.78333333333333],PARAMETER["central_meridian",-87],PARAMETER["false_easting",26246666.6666667],PARAMETER["false_northing",0],UNIT["US
survey
foot",0.304800609601219],AXIS["X",EAST],AXIS["Y",NORTH]],VERTCRS["NAVD88
height (ftUS)", VDATUM["North American Vertical Datum 1988"],
CS[vertical,1], AXIS["gravity-related height (H)",up],
LENGTHUNIT["US survey foot",0.304800609601], ID["EPSG",6360]]]' -co
TILED=YES -co COMPRESS=DEFLATE -co PREDICTOR=3 -co BIGTIFF=IF_SAFER
input.tif output.tif
Kirk Waters, PhD
NOAA Office for Coastal Management
Applied Sciences Program
coast.noaa.gov/digitalcoast <http://coast.noaa.gov/digitalcoast>
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
