简介：本资源为已编译完成的 GDAL gdal111 二进制包，面向从事地理空间数据处理、GIS 软件开发及遥感影像分析的开发者与研究人员，省去自行编译源码的繁琐步骤，可直接集成到项目中调用。压缩包共 241 个文件，约 3.46MB，以 html 文档、h 头文件、csv 数据表、exe 可执行程序为主，另含 dll、lib 库文件及 wkt、gfs、svg、dxf、dgn 等格式样例，涵盖 lib、include、bin、data、html 五类目录，分别提供链接库、API 头文件、运行时组件、配置数据与参考文档。GDAL 支持 TIFF、JPEG、Shapefile、GeoJSON 等栅格与矢量格式，OGR 负责点线面几何及属性表操作，可用于数据读取、转换、裁剪、重采样等任务。目前已有 297 人学习下载，适合需要快速搭建 GIS 数据处理环境、研究 GDAL 接口调用与格式支持的读者参考使用。
1. 拿到 gdal111 压缩包先别急着解压：它到底省掉了哪一步
如果你在 Windows 上从源码编译过 GDAL，大概率经历过这样的下午：装完 Visual Studio，配好 PROJ、GEOS、SQLite、curl、zlib 一堆依赖，CMake 报错刷屏，好不容易编译通过，运行时又提示找不到 proj.db。所以当我第一次看到「已编译的 GDAL gdal111」这个包时，第一反应不是它有多强，而是——它把最耗时的编译环节替我省了。这个包本质是一份预编译好的 GDAL/OGR 运行库，版本线对应 1.11.x，核心价值在于：解压后能直接拿到gdal111.dll、配套的 C 头文件、导入库以及 OGR 矢量驱动，让 C/C++、C# 或 Python 项目跳过源码构建，直接进入调用阶段。它适合三类人：需要把 GDAL 嵌进桌面端或服务端程序的 C++ 开发者、用 C# 做 GIS 数据处理工具的工程师、以及想快速验证坐标系转换和栅格读写逻辑的算法同学。不适合谁？如果你要的是最新版特性（比如 COG 驱动、Zarr 支持），1.11 这条线偏老，得另找新版；如果你只写 Python，直接用 pip 装 wheel 更省事，没必要碰这个包。这一章先把定位说清，后面几章拆目录结构、配置方法、投影校正参数和踩坑记录。
2. 拆开 gdal111 目录：头文件、导入库、DLL 各管什么
2.1 预编译包的典型目录结构与文件职责
一个能用的 GDAL 预编译包，目录不会只有孤零零一个 DLL。我拆过的这类包里，通常能看到bin、include、lib、data四个核心目录，外加可能的python绑定目录。先看一张对照表，把每个目录的职责和你在工程里要引用的路径对上：
| 目录 | 关键文件 | 工程里怎么用 |
|---|---|---|
| bin | gdal111.dll、gdal111_i.lib（或 .lib） | 运行时放可执行文件同目录，链接时指向 lib |
| include | gdal.h、ogr_api.h、gdal_priv.h、ogr_geometry.h | 编译期#include，配置附加包含目录 |
| lib | gdal_i.lib、gdal.lib | 链接器附加依赖项 |
| data | gcs.csv、pcs.csv、proj.db、epsg.wkt | 设置 GDAL_DATA 环境变量，否则坐标系查不到 |
| python | osgeo 包、_gdal.pyd | 需要 Python 绑定时加入 sys.path |
这里有个容易被忽略的点：data目录不是可选项。GDAL 在运行时通过GDAL_DATA环境变量定位gcs.csv、pcs.csv这些坐标系统定义文件，找不到就会在OGRSpatialReference::importFromEPSG时返回失败，报错信息往往是「Unable to load EPSG support」之类。很多人编译链接都过了，一跑坐标转换就崩，根子就在这。
2.2 用 dumpbin 和头文件确认版本与导出符号
拿到包别急着往工程里塞，先验证它是不是完整、版本对不对。Windows 上可以用 Visual Studio 自带的dumpbin看 DLL 导出了哪些符号，确认 OGR 和 GDAL 的 API 都在：
# 查看 DLL 导出的函数符号，确认 GDAL/OGR API 是否齐全 dumpbin /exports gdal111.dll > exports.txt # 过滤出关键入口，确认栅格和矢量 API 都存在 findstr /I "GDALOpen OGRRegisterAll GDALAllRegister OGR_L_GetFeature" exports.txt逻辑说明：dumpbin /exports把 DLL 的导出表打印出来，重定向到文本方便检索。findstr过滤几个标志性函数——GDALAllRegister是栅格驱动注册入口，OGRRegisterAll是矢量驱动注册入口，OGR_L_GetFeature是 OGR 图层读要素的 C API。这几个都在，说明包的核心功能完整。参数上，/exports是 dumpbin 的固定开关，后面跟 DLL 路径即可；如果提示 dumpbin 不是内部命令，需要从「VS 开发人员命令提示符」里运行，或者把 VS 的 VC\Tools\MSVC\版本\bin 加进 PATH。
再看头文件里的版本宏，确认它确实是 1.11 线：
/* 打开 gdal_version.h，确认版本号 */ #define GDAL_RELEASE_NAME "1.11.x" #define GDAL_VERSION_MAJOR 1 #define GDAL_VERSION_MINOR 11如果头文件里GDAL_VERSION_MINOR不是 11，那这个包名和内容就对不上，趁早换。这一步花两分钟，能避免后面链接时一堆符号找不到的血泪经验。
3. 在 VS2022 里配置 gdal111：包含目录、库目录、环境变量三步走
3.1 工程属性里的三处路径配置
VS2022 配置 GDAL 的流程，说穿了就是告诉编译器「头文件在哪」、告诉链接器「导入库在哪」、告诉运行时「DLL 和 data 在哪」。前两步在工程属性里改，第三步靠环境变量或拷贝文件。假设你把包解压到了D:\sdk\gdal111，按下面配：
第一步，附加包含目录。右键项目 → 属性 → C/C++ → 常规 → 附加包含目录，加入：
D:\sdk\gdal111\include第二步，附加库目录。链接器 → 常规 → 附加库目录，加入：
D:\sdk\gdal111\lib第三步，附加依赖项。链接器 → 输入 → 附加依赖项，加入导入库文件名。注意 1.11 线的命名可能是gdal_i.lib或gdal.lib，以 lib 目录里实际存在的为准：
gdal_i.lib配完这三处，写个最小测试程序验证：
#include "gdal_priv.h" #include "ogr_api.h" #include <iostream> int main() { // 注册所有栅格和矢量驱动，缺这一步后面打开文件会失败 GDALAllRegister(); OGRRegisterAll(); // 打印 GDAL 版本，确认链接的是预期版本 std::cout << "GDAL Version: " << GDALVersionInfo("RELEASE_NAME") << std::endl; // 尝试打开一个栅格文件，验证驱动可用 GDALDataset* ds = (GDALDataset*)GDALOpen("test.tif", GA_ReadOnly); if (ds != nullptr) { std::cout << "Raster size: " << ds->GetRasterXSize() << " x " << ds->GetRasterYSize() << std::endl; GDALClose(ds); } else { std::cout << "Open failed, check GDAL_DATA and driver." << std::endl; } return 0; }逻辑说明：GDALAllRegister()和OGRRegisterAll()必须在任何打开操作之前调用，它们把编译进 DLL 的驱动注册到全局管理器。GDALVersionInfo("RELEASE_NAME")返回版本字符串，用来确认运行时加载的 DLL 和头文件版本一致——如果头文件是 1.11 但运行时加载了别的版本 DLL，这里会露馅。GDALOpen返回GDALDataset*，失败返回空指针，所以判空是必须的。参数上，GA_ReadOnly表示只读打开，写操作要用GA_Update。
3.2 让运行时找到 DLL 和 GDAL_DATA
编译链接通过只是第一步，运行时还有两个环境变量要处理。PATH要包含 DLL 所在目录，GDAL_DATA要指向 data 目录。开发阶段我一般直接在系统环境变量里设，部署时改成在程序启动脚本里设，避免污染全局。
# 开发机临时设置（cmd 窗口内有效） set PATH=D:\sdk\gdal111\bin;%PATH% set GDAL_DATA=D:\sdk\gdal111\data # 验证 GDAL_DATA 是否生效，用 gdalinfo 看坐标系统信息 gdalinfo --version gdalinfo test.tif逻辑说明：set PATH=...;%PATH%把 GDAL 的 bin 目录插到 PATH 最前面，保证优先加载这个版本的 DLL，避免和系统里其他 GDAL 冲突。GDAL_DATA指向 data 目录后，gdalinfo才能正确解析文件的坐标系统和投影信息。如果gdalinfo test.tif输出的 Coordinate System 是空或者报错，八成是GDAL_DATA没设对。注意set只在当前 cmd 窗口有效，要持久化得用setx，但setx对已开窗口不生效，这是新手常翻车的地方。
4. 用 gdal111 做 RPC 正射校正与 UTM 投影：参数怎么给
4.1 RPC 正射校正的输入条件与 gdalwarp 参数
RPC 正射校正（Rational Polynomial Coefficients）是卫星影像处理的常见需求，GDAL 里靠gdalwarp配合-rpc参数完成。但这里有个前提：影像必须自带 RPC 元数据，通常存在.rpb文件或影像内部的 RPC 域里。没有 RPC 信息，-rpc就是空转。先确认影像有没有 RPC：
# 查看影像元数据，确认是否存在 RPC 相关字段 gdalinfo input.tif | findstr /I "RPC" # 如果 RPC 在独立的 .rpb 文件里，确保它和影像同名同目录 # 例如 input.tif 对应 input.rpb确认有 RPC 后，执行正射校正并输出到 UTM 投影：
# RPC 正射校正，同时重投影到 UTM 50N（EPSG:32650） gdalwarp -rpc ^ -t_srs EPSG:32650 ^ -r bilinear ^ -tr 0.5 0.5 ^ -of GTiff ^ input.tif output_ortho.tif逻辑说明：-rpc告诉 gdalwarp 使用影像自带的 RPC 模型做几何校正，这是正射校正的核心开关。-t_srs EPSG:32650指定输出坐标系为 UTM 50N，EPSG 编码要按影像实际经度带选，选错带号会导致坐标偏移几百公里。-r bilinear是重采样方法，正射校正常用双线性或三次卷积，-r cubic更锐但更慢。-tr 0.5 0.5指定输出分辨率，单位是目标投影的单位（UTM 下是米），不指定则按源影像估算。-of GTiff指定输出格式。注意 Windows cmd 里换行用^，Linux 下用\，混用会报错。
参数选择上有个经验：-tr不要设得比源影像地面分辨率还小太多，否则是插值放大，细节不会凭空出现，只是文件变大。如果 RPC 校正后影像有黑边，加-dstalpha生成 alpha 波段，方便后续裁剪。
4.2 UTM 投影转换与 EPSG 编码的对应关系
UTM 投影的 EPSG 编码有规律：北半球从 32601 到 32660，南半球从 32701 到 32760，后两位是带号。中国经度范围大致对应 43 到 53 带。选带号可以用经度除以 6 再加 31 估算：
# 用 gdalinfo 查看影像中心经度，确定 UTM 带号 gdalinfo input.tif | findstr /I "Center" # 假设中心经度是 117 度，带号 = int(117/6) + 31 = 50 # 对应 EPSG:32650（北半球）逻辑说明：UTM 每 6 度一个带，带号从 180 度经线起算。公式带号 = floor((经度 + 180) / 6) + 1，简化估算可以用int(经度/6) + 31。北半球加 32600，南半球加 32700。选错带号的典型现象是：转换能成功，但坐标值明显偏离，比如 X 坐标本该是 50 万左右却变成 40 万或 60 万。这时候别怀疑 GDAL，先回去核对带号。
如果要做投影转换而不是正射校正，用gdalwarp不带-rpc即可：
# 纯投影转换，从 WGS84 地理坐标转到 UTM 50N gdalwarp -s_srs EPSG:4326 -t_srs EPSG:32650 -r bilinear input.tif output_utm.tif-s_srs指定源坐标系，如果影像内部已经带了正确的坐标系信息，可以省略，GDAL 会自动读取。但源坐标系信息缺失或错误时，必须显式指定，否则转换结果就是玄学。
5. 避坑与排查：gdal111 配置中最容易翻车的五件事
5.1 现象：编译通过但运行时报「找不到 gdal111.dll」
原因：DLL 不在可执行文件的搜索路径里。Windows 加载 DLL 的顺序是：可执行文件目录 → 系统目录 → PATH 环境变量。很多人只配了工程属性里的库目录，那只影响链接期，运行期不生效。
解决：把gdal111.dll拷贝到 exe 同目录，或者把 bin 目录加进 PATH。部署时推荐前者，避免依赖用户环境。如果还不行，用 Dependency Walker 或 VS 的「模块」窗口看实际加载的是哪个路径的 DLL，确认没有加载到系统里另一个旧版本。
5.2 现象：坐标转换返回失败，提示无法加载 EPSG
原因：GDAL_DATA环境变量没设，或者指向的目录里缺gcs.csv、pcs.csv、proj.db。GDAL 1.11 线部分版本用 CSV 定义坐标系统，部分用 proj.db，取决于编译时的 PROJ 版本。
解决：确认GDAL_DATA指向包的 data 目录，且目录里确实有这些文件。用gdalinfo --version和gdalinfo --formats先确认基本功能正常，再测坐标转换。如果 data 目录文件缺失，这个包就是残包，得换。
5.3 现象：链接时报「无法解析的外部符号 GDALAllRegister」
原因：附加依赖项里的导入库名字写错，或者库目录没配对。1.11 线的导入库可能叫gdal_i.lib，也可能叫gdal.lib，不同编译方式命名不同。
解决：打开 lib 目录，看实际文件名是什么，照着填。如果只有.dll没有.lib，说明这个包没带导入库，C++ 没法直接链接，只能用LoadLibrary+GetProcAddress动态加载，麻烦得多。选包时一定要确认 lib 目录里有导入库。
5.4 现象：RPC 正射校正后影像位置整体偏移
原因：RPC 元数据和影像不匹配，或者-t_srs的带号选错。也有可能是影像的 RPC 本身精度有限，1.11 线对某些新型卫星的 RPC 模型支持不完整。
解决：先用gdalinfo确认 RPC 字段存在且数值合理，再核对 UTM 带号。如果 RPC 精度不够，考虑用地面控制点做多项式校正替代。1.11 线对 RPC 的支持边界就在这里，别硬扛。
5.5 现象：Python 绑定导入 osgeo 报「DLL load failed」
原因：Python 的_gdal.pyd依赖gdal111.dll，但 Python 进程的 DLL 搜索路径里没有它。另外 Python 版本和 pyd 的编译版本必须匹配，比如 pyd 是 cp37 编译的，就不能用在 Python 3.10 上。
解决：把 bin 目录加进 PATH 后再启动 Python，或者用os.add_dll_directory（Python 3.8+）显式添加。版本匹配问题只能换对应的 pyd，没有捷径。用python -c "import sys; print(sys.version)"确认版本，再对照 pyd 文件名里的 cp 标记。
6. 进阶验证：用 gdal111 批量处理时怎么确认结果可信
批量跑正射校正或投影转换时，最怕的是「跑完了但结果不对」。我一般会在流程里加两个验证点。第一个是坐标范围检查：转换后的影像四角坐标应该落在目标 UTM 带的合理范围内，X 在 16 万到 83 万之间，Y 在北半球 0 到 930 万之间。超出这个范围，基本可以判定带号或 RPC 有问题。
# 提取转换后影像的四角坐标，检查是否落在合理范围 gdalinfo -corners output_ortho.tif | findstr /I "Upper Left Lower Right"第二个验证点是分辨率一致性：gdalinfo输出的 Pixel Size 应该和-tr参数一致，如果差很多，说明重采样环节出了岔子。批量处理时我会写个脚本，对每个输出文件跑一遍gdalinfo，把坐标范围和分辨率抓出来存成日志，跑完统一扫一遍异常值。
# 批量验证：遍历输出目录，提取每个文件的坐标范围和分辨率 for %f in (output\*.tif) do ( echo === %f === gdalinfo -corners %f | findstr /I "Upper Left Lower Right Pixel Size" )逻辑说明：for %f in (...)是 cmd 的循环语法，在批处理文件里要写成%%f。gdalinfo -corners输出四角坐标，findstr过滤关键行。把结果重定向到日志文件，跑完用文本工具搜异常值。这个习惯帮我逮到过好几次带号选错的问题——单看一个文件不容易发现，批量对比就露馅了。
还有一个技巧：如果怀疑 RPC 校正精度，可以找几个已知坐标的地面点，用gdallocationinfo查转换后影像上对应位置的像素值，和预期对比。1.11 线没有内置的精度评估工具，得自己搭这套验证流程。从那以后我每次批量处理前，都强制先拿一个样本文件走完整流程并人工核对坐标，确认无误再放开跑全量。希望帮到你。
本文还有配套的精品资源，点击获取
