c++如何解析TIFF图像中的GeoTIFF地理位置信息标签【深度】

c++如何解析TIFF图像中的GeoTIFF地理位置信息标签【深度】

如何用 libtiff 读取 GeoTIFF 的 GeoKeyDirectoryTag 和 GeoDoubleParamsTag

如果你以为GeoTIFF的地理信息藏在常规的EXIF里，那可就错了。它的核心机制是通过一组特殊的TIFF标签来嵌入的。其中，GeoKeyDirectoryTag（标签号34735）扮演着“总目录”的角色，定义了坐标系、投影参数以及键值映射关系。而具体的数值，则存放在两个辅助标签里：GeoDoubleParamsTag（34736）负责存储浮点参数，比如标准纬线、中央经线；GeoAsciiParamsTag（34737）则存放字符串，例如椭球体名称、单位名称。需要明确的是，libtiff库本身并不会自动解析这些标签，一切都需要我们手动提取并按规范解码。

具体操作时，有几个关键点不容忽视：

• 首先，使用TIFFGetField(tif, TIFFTAG_GEOKEYDIRECTORY, &count, &dir)来获取GeoKeyDirectoryTag的原始数据，它是一个ushort数组。这个数组的前4个元素是固定的头信息，包括版本、修订号、主键数量和扩展键数量。从第5个元素开始，每4个元素构成一组，分别对应KeyID（键ID）、TagLocation（标签位置）、Count（数量）和ValueOffset（值偏移）。
• 这里有个解码的核心规则：当TagLocation等于0时，表示键值直接存储在第4个字段（ValueOffset）中，但这仅限于short类型的数据。如果TagLocation是34736，那么ValueOffset就是一个索引，指向GeoDoubleParamsTag数组中的具体位置；如果是34737，则指向GeoAsciiParamsTag字符串中的偏移量。
• 务必进行完整性校验：检查获取到的count是否大于等于4，并且整个数组的长度能否被4整除。如果不符合，那很可能文件已损坏，或者它根本就不是一个标准的GeoTIFF文件。

为什么 TIFFTAG_GEOKEYDIRECTORY 读出来全是 0？

这个问题困扰过不少开发者。最常见的原因，是TIFF文件使用了BigTIFF格式，而你使用的旧版libtiff可能对GeoKeyDirectoryTag的支持不完整，或者在编译时没有启用LIBTIFF_BIGTIFF_SUPPORT宏。另一个比较隐蔽的原因，是图像数据被压缩了（比如用了LZW或ZIP算法）。在某些libtiff版本中，如果没有先调用TIFFSetDirectory(tif, dirnum)切换到主图像目录，就直接读取自定义标签，可能会失败。

遇到这种情况，可以按以下步骤系统排查：

立即学习“C++免费学习笔记（深入）”；

• 先用命令行工具tiffinfo your.tif确认文件中是否确实包含GeoKeyDirectoryTag，并查看其长度是否非零。这是判断问题出在文件还是代码的第一步。
• 检查你链接的libtiff库版本，建议使用4.5.0或更高版本，其对GeoTIFF和BigTIFF的支持更为完善。
• 在代码中，确保在TIFFOpen()打开文件之后，立即调用TIFFSetDirectory(tif, 0)切换到第一个目录（即使是单页图像也建议这么做）。
• 如果上述方法都失败了，那就得考虑“手动档”操作了：尝试使用TIFFReadCustomDirectory()函数，手动定位并解析标签在文件中的偏移量（这需要你从IFD文件头开始手动计算跳转）。

如何把 GCS_WGS_84 或 PCS_NAD83_UTM_zone_10N 转成 EPSG 代码？

GeoTIFF规范里定义了一系列键，如GTModelTypeGeoKey（模型类型，键号2048）、GTRasterTypeGeoKey（栅格类型，键号2049）、GeographicTypeGeoKey（地理类型，键号2049）等，它们的值对应着预定义的常量。但问题是，这些常量并不直接等于EPSG代码。你需要一个映射表来进行转换——目前最可靠的方式，是在代码里硬编码一些常用的组合，而不是依赖运行时的网络查询，那样会引入不确定性和延迟。

映射的逻辑其实很清晰：

• 如果GTModelTypeGeoKey的值是ModelTypeProjected（表示是投影坐标系），并且ProjectedCSTypeGeoKey的值是PCS_NAD83_UTM_zone_10N（其数值等于26910），那么对应的EPSG代码就是26910。
• 如果GTModelTypeGeoKey的值是ModelTypeGeographic（表示是地理坐标系），并且GeographicTypeGeoKey的值是GCS_WGS_84（其数值等于4326），那么EPSG代码就是4326。
• 需要特别注意：并非所有的GeoKey值都有对应的EPSG代码。例如，遇到自定义的投影坐标系时，你就需要结合ProjLinearUnitsGeoKey（投影线性单位）、ProjStdParallel1GeoKey（第一标准纬线）等一系列参数，来重新构建完整的WKT（Well-Known Text）描述字符串。

说到常量定义，libgeotiff库的geotiff.h头文件里已经定义好了所有这些键和值。但libgeotiff是一个独立的库，不会随libtiff自动链接。如果你不想引入这个额外的依赖，一个更轻量的办法是直接去查阅libgeotiff的源码，把需要的常量定义复制到自己的项目里。

解析出的坐标系参数为何和 QGIS 显示不一致？

这可能是最让人头疼的问题之一。其根本原因在于，GeoTIFF里存储的GeoKey参数，描述的是“模型空间”的坐标系信息，而决定图像在地图上具体位置的，是另一组用于“栅格定位”的标签。很多开发者只读取了GeoKey，却忽略了ModelTransformationTag（33550）或ModelPixelScaleTag（33551）加上ModelTiepointTag（33552）这些基础几何标签，导致计算出来的坐标完全对不上。

要准确定位，必须协同使用以下几组标签：

• ModelPixelScaleTag（33551）：一个包含3个double值的数组，分别表示X、Y、Z方向上一个像素所代表的真实世界单位（可能是度，也可能是米）。
• ModelTiepointTag（33552）：一个至少包含6个double值的数组，其格式为[i, j, k, x, y, z]。其中(i, j, k)是图像上的像素坐标（通常i和j是0，k也是0），(x, y, z)是对应的真实世界地理坐标。
• 将两者结合，就能构造一个简单的仿射变换：X_geo = tie_x + i * scale_x，Y_geo = tie_y - j * scale_y（注意Y坐标通常是减号，因为图像坐标的原点在左上角，而地理坐标的原点在左下角）。

真正复杂的情况出现在多Tiepoint（多个地面控制点）或者非正交缩放（图像有旋转或剪切）的时候。这时就必须使用ModelTransformationTag，它是一个包含16个元素的double矩阵，用于进行完整的齐次坐标变换。这里还有一个细节陷阱：必须确认矩阵的存储顺序是行优先还是列优先，根据GeoTIFF规范，它要求的是列优先顺序，这一点在计算时千万不能搞错。