[gdal-dev] GeoTIFF: connection between CRS WKT and GeoKeys

Even Rouault even.rouault at spatialys.com
Wed Oct 13 09:45:28 PDT 2021


Le 13/10/2021 à 18:35, Eric Robeck a écrit :
> I have a question about which GeoTIFF tags should be used for storing 
> CRS information. I have two GeoTIFFs: one original and the same file 
> saved as a COG. Then I created gdalinfo and listgeo reports for each 
> and compared them for changes.
>
> *gdalinfo*: Aside from the difference in the PROJCRS citation ("WGS 84 
> / UTM zone 6N" vs. "WGS_84_UTM_zone_6N"), the only change is the COG 
> and LZW predictor.
>
> *listgeo*: a large number of GeoTags were never populated by the 
> original GeoTIFF creators. Other ASCII citation values were replaced 
> by the Esri conversion tool.
>
> A number of the listgeo-reported GeoKeys in the COG (e.g. 
> GeogGeodeticDatumGeoKey, GeogAngularUnitSizeGeoKey, 
> GeogEllipsoidGeoKey, etc.) are missing from the custom-made original 
> GeoTIFF. The extra CRS tags were added upon conversion to COG. Those 
> parameters are fundamental components of the CRS and are reported in 
> the gdalinfo WKT as DATUM/ELLIPSOID, ANGLEUNIT, etc.
>
> However, the WKT reported by gdalinfo is identical in both cases. So 
> it had access to the full WKT components even when the corresponding 
> GeoKeys were missing in the GeoTIFF.
>
> My questions are:
>
>  1. If the GeoKeys storing that information are missing from the
>     GeoTIFF, where does GDAL retrieve them from? Does it refer to the
>     PROJ library to retrieve the EPSG values for the EPSG codes in
>     ProjectedCSTypeGeoKey, VerticalCSTypeGeoKey, etc.?
>
Yes, GDAL / libgeotiff uses the EPSG codes of the geokeys that contain 
some to build its CRS object by querying the PROJ database. If you've a 
ProjectedCSTypeGeoKey, then the geokeys describing the linear unit, the 
geographic CRS, datum, etc are useless. When outputing GeoTIFF 1.0, GDAL 
will write a bit more than needed. This has been restricted to the 
minimum set to avoid any contradiction when using GeoTIFF 1.1 output. 
GeoTIFF 1.0 is the default when no vertical information is available. 
GeoTIFF 1.1 when there's one. This can be controlled with the 
GEOTIFF_VERSION creation option.
>
>  1. Some software, following guidance in DGIWG-108 and DGIWG-250, did
>     not assign a VerticalDatumGeoKey. Prior to release of GeoTIFF 1.1,
>     the "unknown" value caused problems with vertical projection in
>     some software, like QT Modeler. Does GDAL now fill in or assume
>     the missing key based on the VerticalCSTypeGeoKey?
>
If VerticalCSTypeGeoKey is present and the GeoTIFF version 1.0, GDAL 
will use its rather complex heuristics to try to guess a vertical CRS, 
but will not reoprt it by default unless you define the 
GTIFF_REPORT_COMPD_CS=YES configuration option 
(https://gdal.org/drivers/raster/gtiff.html#configuration-options)

If the file is GeoTIFF 1.1, it will report the vertical information by 
default, when present in the file.

Even

||

> Thanks in advance!
>
> Regards,
> Eric
>
>
> _______________________________________________
> 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/20211013/53aed04a/attachment.html>


More information about the gdal-dev mailing list