GDAL读取的坐标起点在像素左上角还是像素中心?
1. 问题
笔者在处理地理栅格数据的时候,总是会发生偏差半个像素的问题。
比如说通过ArcMap打开一张.tif,查看其地理信息;同时用记事本打开.tfw,比较两者得地理信息:
同样的起点位置(左上角坐标),两者却相差半个像素的距离。
而对于另一些数据,比较ArcMap与tfw的信息,两者的地理信息又可以是一样的。那么对于地理栅格数据,其起点位置(左上角坐标)是以哪一种为准?为什么两者会相差半个像素的距离?
而GDAL可以也读取地理栅格数据(DEM、DOM等)的坐标信息:
//
GDALAllRegister();
CPLSetConfigOption("GDAL_FILENAME_IS_UTF8", "NO");
//
const char * pszFile = "D:\\Data\\imgDemo\\K52E004015AD005M2010A.TIF";
GDALDataset *poDataset = (GDALDataset*)GDALOpen(pszFile, GA_ReadOnly);//使用只读方式打开图像
if (!poDataset)
{
printf("File: %s不能打开!\n", pszFile);
}
//获取地理坐标信息
double padfTransform[6];
if (poDataset->GetGeoTransform(padfTransform) == CE_Failure)
{
printf("获取仿射变换参数失败");
}
cout << fixed << "仿射变换参数:" << endl
<< padfTransform[0] << endl //左上角点坐标X
<< padfTransform[1] << endl //X方向的分辨率
<< padfTransform[2] << endl //旋转系数,如果为0,就是标准的正北向图像
<< padfTransform[3] << endl //左上角点坐标Y
<< padfTransform[4] << endl //旋转系数,如果为0,就是标准的正北向图像
<< padfTransform[5] << endl; //Y方向的分辨率
那么GDAL读取坐标起点也就是左上角点坐标(padfGeoTransform[0],padfGeoTransform[3])又应该是哪一种呢?
2. 结论
经过比较和论证,笔者发现GDAL和ArcMap在处理TIF格式的地理栅格数据的时候,都遵循以下原则:
- GDAL/ArcMap读取的起点位置都是左上角像素左上角的位置。
- TFW里面存储的坐标起点标识的是左上角像素中心的位置。
- 而TIF内部存储的坐标起点标识的是左上角像素左上角的位置。所以两者的地理坐标的距离总是差半个像素的距离。
- TIF内部可以不存储地理信息,此时GDAL/ArcMap会以TFW里面存储的起点位置为准,但因为TFW是像素中心的位置,读取的起点位置会偏移半个像素的距离。
- 一旦TIF内部可以存储地理信息,此时GDAL/ArcMap会以TIF内部可以存储地理为准。此时TFW文件就不起作用了。
3. 例外
GDAL和ArcMap都没有区分处理的地理栅格数据是DEM(地形)还是DOM(影像),其实对于地形栅格数据,很多时候会把起点位置处理成左上角像素中心的位置。比如说软件GlobalMapper中,打开TIF的时候会询问是将其作为DEM处理还是DOM处理。当作为DEM处理的时候,其余的原则一样,但是读取的起点就是左上角像素中心的位置了。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)