[gdal-dev] false easting and northing units

[Even Rouault]

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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240125/4f06effa/attachment-0001.htm>