[gdal-dev] false easting and northing units

Thu Jan 25 07:47:28 PST 2024

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
>> 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.
>
> _______________________________________________
> 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/1c5ee8d8/attachment.htm>