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