简介：这份预编译GDAL gdal111资源包面向从事地理空间数据处理、GIS开发与遥感分析的开发者，省去自行编译源码的繁琐步骤，可直接集成到项目中调用。包内共241个文件，以html文档、h头文件、csv坐标与投影参数表、exe可执行程序为主，另含wkt、gfs、svg、dxf、dgn等格式数据及少量dll、lib库文件，压缩包约3.46MB，涵盖lib、include、bin、data、html五类目录，分别提供链接库、API头文件、运行时组件、配置数据与参考文档。GDAL与OGR支持TIFF、JPEG、Shapefile、GeoJSON等栅格与矢量格式的读写、转换、裁剪与重采样，csv中的基准面、投影参数表对坐标转换尤为关键。目前已有297人学习下载，适合需要快速搭建GIS数据处理环境、研究库文件组织与格式支持的读者参考使用。
1. 已编译的GDAL gdal111：为什么有人宁愿用现成包也不自己编
如果你在Windows上做过GIS开发，大概率经历过这个场景：项目急着出图，需要读一个GeoTIFF或者做一次坐标转换，结果在pip install gdal这一步卡了一整个下午。报错从Microsoft Visual C++ 14.0 is required一路滚到fatal error C1083: 无法打开包括文件: “gdal.h”，最后你开始怀疑自己是不是不适合干这行。标题里的“已编译的GDAL gdal111”，说的就是有人已经把这道坎替你迈过去了——一个在Windows环境下预先编译好的GDAL 1.11.x版本，解压或安装后直接能用，不需要你本地配VS2022、不需要折腾nmake、不需要跟proj和geos的依赖链搏斗。
这个方向适合三类人：一是做C#/C++桌面GIS工具、需要直接链接gdal111.dll的开发者；二是用Python但被编译环境反复折磨的数据处理人员；三是需要在老系统或离线环境里快速搭起栅格/矢量读写能力的一线实施人员。它解决的核心问题不是“GDAL能干什么”，而是“怎么在半小时内让GDAL跑起来”。下面按选型、部署、验证、踩坑的顺序，把这条路走一遍。
2. gdal111预编译包的结构与选型判断：你到底该拿哪个目录
拿到一个“已编译的GDAL gdal111”压缩包，第一件事不是双击安装，而是先看清楚里面有什么。GDAL 1.11是一个比较老的稳定分支，它的预编译产物通常包含几个关键部分：bin目录下的gdal111.dll及其依赖DLL、data目录下的坐标系统和投影定义文件、include目录下的C/C++头文件、以及可选的Python绑定。不同来源的包结构差异很大，选错了后面全是玄学问题。
2.1 先分清三种预编译形态
常见的预编译GDAL gdal111大致分三类。第一类是纯运行时包，只有gdal111.dll和必要的依赖，适合已经用其他方式拿到头文件、只需要部署运行环境的场景。第二类是开发包，包含include、lib和bin，适合C++项目直接链接。第三类是带语言绑定的完整包，比如带Python的osgeo模块或者带Java的gdal.jar，这类包体积最大，但省去了单独配绑定的麻烦。
判断方法很简单：解压后看根目录有没有include文件夹，有就是开发包；看有没有python或java子目录，有就是带绑定的完整包。如果你只是用Python调GDAL，优先选带Python绑定的完整包，因为单独给gdal111配Python绑定需要匹配Python版本和编译器版本，很容易翻车。
2.2 版本号里的隐藏信息
“gdal111”这个写法本身有歧义。它可能指GDAL 1.11.0，也可能指1.11.1、1.11.2、1.11.3或1.11.4。这几个补丁版本在栅格驱动和投影处理上有差异，尤其是1.11.0早期版本对某些GeoTIFF的压缩方式支持不完整。拿到包后，用gdalinfo --version确认实际版本，不要只看文件名。
另外要注意编译时的依赖版本。GDAL 1.11通常搭配PROJ 4.x和GEOS 3.4/3.5。如果包里的proj.dll版本和data目录下的proj_def.dat不匹配，做坐标转换时会得到偏移几百米的错误结果，而且不报错。这是最隐蔽的坑之一。
2.3 选型对照表
| 你的场景 | 推荐形态 | 需要检查的文件 | 不推荐的做法 |
|---|---|---|---|
| Python数据处理 | 带Python绑定的完整包 | osgeo/_gdal.pyd、gdal111.dll | 自己用pip编译 |
| C++桌面工具 | 开发包 | gdal.h、gdal_i.lib | 混用不同版本的依赖DLL |
| 仅部署运行 | 纯运行时包 | gdal111.dll、proj.dll、geos.dll | 把DLL丢进System32 |
| Java GIS服务 | 带gdal.jar的包 | gdal.jar、gdal111.dll | 忽略JNI路径配置 |
提示：不要从多个来源混搭DLL。GDAL 1.11的DLL之间耦合很紧，混用不同编译选项的版本会导致进程崩溃且没有明确报错。
3. 在Windows上部署gdal111：从解压到第一个gdalinfo命令
部署的目标是让gdalinfo能跑、Python能import osgeo、C++能链接。下面按顺序做，每一步都有验证点。
3.1 目录规划与环境变量
先把包解压到一个没有空格和中文的路径，比如D:\gdal111。不要放在Program Files下，因为GDAL 1.11的部分工具对空格路径处理有问题。解压后确认目录结构类似：
D:\gdal111\ ├── bin\ │ ├── gdal111.dll │ ├── gdalinfo.exe │ ├── gdal_translate.exe │ ├── proj.dll │ └── geos.dll ├── data\ │ ├── gcs.csv │ ├── pcs.csv │ └── proj_def.dat ├── include\ │ ├── gdal.h │ └── gdal_priv.h └── lib\ └── gdal_i.lib然后设置两个环境变量。GDAL_DATA指向D:\gdal111\data，PATH里加入D:\gdal111\bin。这两个变量缺一不可：没有GDAL_DATA，坐标转换会失败；没有PATH，gdal111.dll加载不到依赖。
setx GDAL_DATA "D:\gdal111\data" setx PATH "%PATH%;D:\gdal111\bin"设置完要新开一个命令行窗口，setx不会影响当前会话。验证：
gdalinfo --version如果输出了版本号，说明运行时环境通了。如果报“找不到gdal111.dll”，检查PATH是否生效；如果报“无法加载proj.dll”，检查bin目录下依赖是否齐全。
3.2 Python绑定的配置
如果包里有Python绑定，通常是一个osgeo文件夹。把它复制到你的site-packages目录，或者把包里的python目录加到PYTHONPATH。然后测试：
# test_gdal.py from osgeo import gdal # 打印版本，确认绑定加载的是gdal111 print(gdal.VersionInfo()) # 打开一个栅格文件测试驱动 dataset = gdal.Open(r"D:\test.tif") if dataset is None: print("打开失败，检查文件路径和驱动") else: print("栅格尺寸:", dataset.RasterXSize, "x", dataset.RasterYSize) print("投影:", dataset.GetProjection()[:60])这段代码的逻辑是：先确认版本，再打开一个实际文件。gdal.Open返回None时不抛异常，所以必须显式判断。如果VersionInfo()输出的是其他版本号，说明系统里存在多个GDAL，Python加载到了错误的那个。解决方法是把osgeo目录放在PYTHONPATH最前面，或者卸载其他GDAL包。
3.3 C++项目的链接配置
在VS2022里新建项目后，需要配置三个地方。头文件目录加D:\gdal111\include，库目录加D:\gdal111\lib，链接器输入加gdal_i.lib。然后把gdal111.dll复制到输出目录，或者把bin加入PATH。
// main.cpp #include "gdal_priv.h" #include <iostream> int main() { // 注册所有驱动，必须调用 GDALAllRegister(); // 打开数据集，只读模式 GDALDataset* ds = (GDALDataset*)GDALOpen("D:\\test.tif", GA_ReadOnly); if (ds == nullptr) { std::cerr << "打开失败" << std::endl; return 1; } std::cout << "波段数: " << ds->GetRasterCount() << std::endl; std::cout << "宽高: " << ds->GetRasterXSize() << "x" << ds->GetRasterYSize() << std::endl; GDALClose(ds); return 0; }GDALAllRegister()不能省，否则驱动列表为空，GDALOpen永远返回空。GDALClose要配对调用，否则文件句柄泄漏。编译时如果报LNK2019，检查gdal_i.lib是否匹配当前架构（x86还是x64），GDAL 1.11的32位和64位库不能混用。
4. gdal111的典型工作流：栅格读写、投影转换与RPC正射校正
部署通了之后，真正要干活。GDAL 1.11虽然老，但核心的栅格读写、投影转换和RPC校正都能做。下面挑三个高频场景。
4.1 栅格读写与格式转换
最常见的操作是把一个GeoTIFF转成其他格式，或者裁剪、重采样。用gdal_translate命令行最快：
# 把输入转为JPEG压缩的GeoTIFF，并指定输出范围 gdal_translate -of GTiff -co "COMPRESS=JPEG" -co "JPEG_QUALITY=85" ^ -projwin 116.0 40.0 117.0 39.0 input.tif output.tif-of GTiff指定输出格式，-co是创建选项，COMPRESS=JPEG能大幅减小体积但会损失精度。-projwin按地理坐标裁剪，顺序是左上经度、左上纬度、右下经度、右下纬度。注意GDAL 1.11的-projwin对投影坐标和地理坐标的处理取决于源数据的坐标系，如果源是投影坐标而你给了经纬度，裁剪结果会完全错误。先用gdalinfo确认坐标系。
Python里做同样的事：
from osgeo import gdal # 打开源数据 src = gdal.Open(r"D:\input.tif") # 创建输出，指定尺寸和波段数 dst = gdal.GetDriverByName("GTiff").Create( r"D:\output.tif", src.RasterXSize, src.RasterYSize, src.RasterCount, gdal.GDT_Byte, options=["COMPRESS=JPEG", "JPEG_QUALITY=85"] ) # 复制投影和地理变换，这两步不能少 dst.SetProjection(src.GetProjection()) dst.SetGeoTransform(src.GetGeoTransform()) # 逐波段写入 for i in range(1, src.RasterCount + 1): band = src.GetRasterBand(i) dst.GetRasterBand(i).WriteArray(band.ReadAsArray()) dst = None # 关闭文件，刷新到磁盘SetProjection和SetGeoTransform如果不调用，输出文件没有空间参考，GIS软件打开会提示未知坐标系。dst = None是Python里关闭GDAL数据集的惯用写法，不写的话文件可能不完整。
4.2 投影转换的UTM参数设置
投影转换是GDAL的高频用途，也是坑最集中的地方。GDAL 1.11用PROJ 4的字符串格式定义投影。比如WGS84转UTM 50N：
from osgeo import osr # 定义源坐标系：WGS84地理坐标 src_srs = osr.SpatialReference() src_srs.ImportFromEPSG(4326) # 定义目标坐标系：UTM 50N dst_srs = osr.SpatialReference() dst_srs.SetProjCS("UTM 50N / WGS84") dst_srs.SetWellKnownGeogCS("WGS84") dst_srs.SetUTM(50, True) # 50是带号，True表示北半球 # 创建转换对象 transform = osr.CoordinateTransformation(src_srs, dst_srs) # 转换一个点：经度116.4，纬度39.9 x, y, z = transform.TransformPoint(116.4, 39.9) print("UTM坐标:", x, y)SetUTM(50, True)里的50是UTM带号，北京在50带。带号算错会导致坐标偏移几百万米。南半球要把True改成False。另外GDAL 1.11的TransformPoint返回三个值，第三个是高程，平面转换时忽略即可。
注意：如果转换结果出现
inf或nan，通常是源坐标系定义不完整。检查ImportFromEPSG是否成功，以及GDAL_DATA是否指向了正确的data目录。
4.3 RPC正射校正的安装步骤与注意事项
RPC（有理多项式系数）正射校正用于卫星影像的几何校正。GDAL 1.11通过gdalwarp支持RPC，但需要影像自带RPC元数据，或者提供_rpc.txt文件。
# 使用RPC做正射校正，输出UTM投影 gdalwarp -rpc -t_srs "+proj=utm +zone=50 +datum=WGS84 +units=m" ^ -r bilinear -et 0.5 -order 3 ^ input_rpc.tif output_ortho.tif-rpc启用RPC校正，-t_srs指定输出投影，-r bilinear是重采样方法，-et 0.5是误差阈值，-order 3是多项式阶数。注意事项有三条：第一，RPC文件必须和影像同名且后缀为_rpc.txt，或者RPC信息内嵌在GeoTIFF的元数据里；第二，-t_srs里的UTM带号要和影像覆盖范围匹配，跨带影像要分带处理；第三，GDAL 1.11的RPC校正对控制点数量敏感，如果影像没有足够的地面控制点，输出会有明显的扭曲。
验证校正结果：
from osgeo import gdal ds = gdal.Open(r"D:\output_ortho.tif") print("投影:", ds.GetProjection()) print("地理变换:", ds.GetGeoTransform()) # 检查是否有RPC元数据残留 print("RPC:", ds.GetMetadata("RPC"))如果GetMetadata("RPC")返回空字典，说明校正后RPC被清除，这是正常的。如果GetProjection()为空，说明-t_srs没生效，检查PROJ数据路径。
5. gdal111避坑记录：五个让一线工程师熬夜的典型问题
这一章按“现象→原因→解决”写，都是实际部署和使用中反复出现的。
5.1 gdalinfo能跑但Python导入报DLL加载失败
现象：命令行gdalinfo --version正常，但Python里from osgeo import gdal报ImportError: DLL load failed。
原因：Python绑定的_gdal.pyd依赖gdal111.dll，而Python进程的DLL搜索路径和命令行不同。PATH里的bin目录对Python不一定生效，尤其是用conda或虚拟环境时。
解决：把D:\gdal111\bin下的所有DLL复制到osgeo目录旁边，或者用os.add_dll_directory显式添加。Python 3.8以上必须用后者：
import os os.add_dll_directory(r"D:\gdal111\bin") from osgeo import gdal5.2 坐标转换结果偏移几百米
现象：用gdaltransform或Python做WGS84转UTM，结果和已知控制点差几百米。
原因：GDAL_DATA指向的data目录里proj_def.dat和proj.dll版本不匹配，或者gcs.csv缺失导致基准面参数错误。
解决：确认GDAL_DATA环境变量指向包自带的data目录，不要指向其他GDAL版本的data。用gdalinfo --version和proj命令交叉验证。如果data目录里文件不全，从同版本包里补齐。
5.3 gdalwarp处理大影像时内存溢出
现象：gdalwarp处理几GB的影像时进程被杀死，报MemoryError或直接崩溃。
原因：GDAL 1.11默认的缓存策略比较激进，-wm参数没设置时可能一次性读入过多数据。
解决：显式限制内存，并分块处理：
gdalwarp -wm 512 -multi -co "TILED=YES" -co "BLOCKXSIZE=256" -co "BLOCKYSIZE=256" ^ input.tif output.tif-wm 512限制缓存为512MB，-multi启用多线程，TILED=YES让输出分块存储，后续读取更省内存。
5.4 Java调用gdal.jar时报UnsatisfiedLinkError
现象：Java项目引入gdal.jar后，调用gdal.AllRegister()报UnsatisfiedLinkError: no gdal111 in java.library.path。
原因：JNI需要找到gdal111.dll，但Java的java.library.path不包含bin目录。
解决：启动时加JVM参数：
java -Djava.library.path=D:\gdal111\bin -jar yourapp.jar同时确认gdal.jar的版本和gdal111.dll匹配，不同版本的JNI接口不兼容。
5.5 VS2022配置gdal111后链接报LNK2019
现象：VS2022里配置了头文件和库目录，编译通过但链接报LNK2019: 无法解析的外部符号。
原因：gdal_i.lib是导入库，需要对应的gdal111.dll在运行时存在。链接时报错通常是库文件架构不匹配，比如项目是x64但用了32位的gdal_i.lib。
解决：确认项目平台和GDAL包的架构一致。用dumpbin /headers gdal_i.lib查看机器类型。另外VS2022默认的C++标准可能和GDAL 1.11的头文件不兼容，把项目属性里的C++语言标准设为ISO C++14或更低。
6. 让gdal111在老项目里多活几年：一个版本锁定与迁移检查的习惯
GDAL 1.11不是新版本，但在很多存量项目里它还在跑。我自己的习惯是：拿到一个gdal111预编译包后，先做一次“版本快照”——把gdalinfo --version、gdalinfo --formats、python -c "from osgeo import gdal; print(gdal.VersionInfo())"三条命令的输出存成一个文本文件，和包放在一起。这样下次换机器或者同事问“这个包到底支持什么格式”时，不用重新试。
迁移检查用下面这个脚本，能快速确认新环境是否和旧环境一致：
from osgeo import gdal, osr # 检查版本 print("GDAL版本:", gdal.VersionInfo()) # 检查关键驱动是否可用 drivers = ["GTiff", "HFA", "JPEG", "PNG", "AAIGrid"] for d in drivers: drv = gdal.GetDriverByName(d) print(f"驱动 {d}: {'可用' if drv else '缺失'}") # 检查投影转换是否正常 srs = osr.SpatialReference() srs.ImportFromEPSG(4326) print("EPSG:4326 导入:", "成功" if srs.ExportToProj4() else "失败") # 检查RPC支持 print("RPC元数据支持:", "是" if gdal.GetDriverByName("GTiff") else "否")这个脚本的逻辑是逐项验证核心能力，而不是只看版本号。驱动缺失通常意味着gdal111.dll编译时没包含对应模块，投影导入失败通常是GDAL_DATA问题。
还有一个实用技巧：如果项目必须长期用gdal111，但又想用新版本GDAL的某些功能，可以在同一台机器上装两个版本，通过环境变量切换。关键是不要同时把两个版本的bin目录放进PATH，而是用批处理脚本按需设置：
@echo off set GDAL_HOME=D:\gdal111 set GDAL_DATA=%GDAL_HOME%\data set PATH=%GDAL_HOME%\bin;%PATH% echo GDAL 1.11 环境已激活 gdalinfo --version每次开新终端跑一下这个脚本，环境就切过去了。这个习惯让我在维护老项目时少了很多“昨天还能跑今天就不行”的破事。GDAL 1.11的预编译包不是银弹，但它确实能把“配环境”这件事从一天压缩到十分钟。希望帮到你。
本文还有配套的精品资源，点击获取
