简介：资源为基于Visual Studio 2010编译的GDAL 1.11库，面向使用C++、C#或Python进行GIS与遥感数据处理的中高级开发者。该版本集成HDF/HDF5、NetCDF支持，便于遥感和气象科学数据读取；同时提供C#与Python接口，降低GIS功能调用门槛。压缩包共374个文件，约11.52MB，包含83个dll、72个头文件、12个py以及多个csv和exe等，覆盖运行库、开发头文件、扩展驱动、命令行工具、API文档及示例配置，目录结构按csharp、python、bin、include等模块划分，便于集成与查阅。资源已由255人浏览学习，适合需要离线部署或特定VS2010环境下使用GDAL的开发者。压缩包内含data与extensions_dll，提供坐标转换、格式驱动等扩展能力，html文档可辅助快速检索接口，整体为跨语言、多场景的地理空间数据处理提供了可直接引用的工具链。
1. 项目背景与编译环境准备
1.1 为什么还在用GDAL1.11 + VS2010？
说实话，2025年还在折腾GDAL 1.11 + VS2010这个组合，放在整个GIS开发圈子里都挺“复古”的。但如果你接手过老系统、维护过十年前交付的GIS平台，就会明白这不是怀旧，而是没得选。
我这次编译GDAL 1.11.2 for VS2010，是因为公司一套水利信息管理系统还在跑，底层空间分析模块就绑死在GDAL 1.x上。客户的生产服务器是Windows Server 2008 R2，上面装的是VC++ 2010运行库，新版GDAL 3.x编译出来的二进制根本跑不起来——要么缺MSVCP140.dll，要么系统接口不兼容。强行升级运行库？客户机房里还有别的老系统共用了这个环境，动了可能连坐。
所以结论很简单：系统可以老，但你必须能在老环境里把东西编译出来。这篇文章就把整个过程的坑和细节完整复现一遍，给后面接手类似老工程的同行留个参考。
1.2 VS2010环境搭建的几个细节
VS2010在Windows 10上安装本身没问题，但有几个关键点必须先处理好，不然编译过程中会莫名其妙地失败。
第一，VS2010装上之后，第一步必须是打SP1补丁。GDAL 1.11的makefile脚本会在编译前检查编译器版本，VS2010 RTM（未打补丁）的C++编译器对C++标准支持不完整，处理GDAL源码里一些模板特化代码时会出现奇怪的C2059、C2065这类语法错误，而SP1版本就正常。网上有人问“win10下VS2010如何升级到SP1”，直接去微软官方下载中心搜“VS2010 SP1”，有独立的exe安装包，不需要通过Windows Update，装上之后编译器版本会从16.0.30319.1变成16.0.40219.325。
第二，如果编译64位版本，必须安装VS2010的64位编译器组件。默认安装不会带x64编译工具，需要在控制面板的“添加或删除程序”里找到VS2010，选择“更改安装”，勾选“Visual C++ 编译器（x64）”和“Visual C++ 库（x64）”。少了这步，后面nmake时会出现“找不到vcx64”的报错。
第三，命令提示符要用“以管理员身份运行”打开。虽然编译本身不一定要求管理员权限，但GDAL的install步骤会往 C:\Program Files 里写文件，路径带空格的情况下如果权限不足很容易出幺蛾子，干脆直接管理员运行省心。
2. GDAL 1.11源码准备与编译思路
2.1 源码获取与目录规划
GDAL 1.11的源码可以从官方网站的下载归档里找到，文件名类似 gdal-1.11.2.tar.gz。注意，1.11版本还保留着“gdal-版本号”的旧命名规范，从GDAL 2.0之后才拆分成“gdal-版本号”和“libgdal-版本号”两个包。如果你下错成新版，整个编译流程完全不适用。
解压之后，最好把目录放在一个纯英文、无空格的路径下，比如D:\src\gdal-1.11.2，不要放在C:\Program Files这类带空格的路径。虽然新版GDAL已经能处理带空格的路径，但1.11年代的nmake脚本没有做完整的引号转义，踩过的人都知道这种坑有多恶心。
源码目录结构： D:\src\gdal-1.11.2 ├── frmts\ # 各种栅格驱动 ├── ogr\ # 矢量驱动 ├── port\ # 可移植性层 ├── alg\ # 算法 ├── apps\ # 命令行工具源码 ├── nmake.opt # 核心配置文件（重点修改对象） ├── makefile.vc # NMake入口编译脚本 ├── GDALmake.opt # GNU Make环境下的配置（Linux用）2.2 NMake编译体系的核心逻辑
GDAL 1.x在Windows上使用NMake作为编译工具链，这是微软自家的make工具，随VS2010一同安装。先搞清楚NMake的运作逻辑，后面改配置才不会抓瞎。
NMake依赖makefile文件，而 makefile.vc 是入口，它会读取 nmake.opt 中的参数配置，再把编译任务分发给各个子目录下的makefile。你可以把 nmake.opt 理解成总开关和全局配置中心，所有编译选项、依赖库路径、输出目录都在这里设置。
编译时只需要三条命令：
nmake /f makefile.vc MSVC_VER=1600 nmake /f makefile.vc MSVC_VER=1600 install nmake /f makefile.vc MSVC_VER=1600 devinstall其中 MSVC_VER=1600 是VS2010编译器版本号。这个参数必须显式指定，因为nmake脚本会通过它判断是调用哪个版本的编译器。VS2008对应1500，VS2010对应1600，VS2012对应1700，VS2013对应1800，VS2015对应1900。不同版本的编译器对C++标准的支持程度不一样，如果不显式指定，脚本可能在环境检测上出现偏差。
提示：如果这条命令在64位系统上第一次执行时报“无法打开包含文件:stdint.h”，先别急着改源码—— 检查一下是不是环境变量问题，正常情况VS2010本身不带stdint.h，GDAL源码的 port 目录里有兼容实现，nmake脚本会自动处理好。
3. nmake.opt关键配置项详解
3.1 逐项解读必须改的参数
打开 nmake.opt ，里面全是形如变量名 = 值的配置项。我挑几个最核心的来说，每个都是踩过坑才总结出来的经验。
GDAL_HOME = C:\GDAL
这个变量决定最终安装路径，也就是编译完成后头文件、静态库、动态库和工具集会被拷贝到的位置。设成短路径更安全，太深的路径嵌套或者带空格都会增加未知风险。GDAL编译完之后，后续其他项目要引用GDAL时，也是通过这个路径来找头文件和导入库的。
GDAL_VER = 1.11
这个不建议改，它是版本标识，会被写入安装目录结构和生成文件里。
MSVC_VER = 1600
刚才提到过，指定编译器版本。确保只保留这一个值，如果同时出现多个MSVC_VER配置，脚本最后取到的可能是错误版本。
WIN64 = YES / NO
这个非常关键。在32位系统或编译32位版本时，保持WIN64 = NO。在64位系统上要编译64位版时，改成 WIN64 = YES。实际项目中如果两种版本都要，需要分别配置两次，分别编译。注意设完WIN64 = YES之后，要确保VS2010的命令行环境是x64工具集——否则即使变量设了64，编译器还是32位的。
GDAL_DRIVER_PATH = $(GDAL_HOME)\lib\gdalplugins
这是插件驱动的输出路径。GDAL 1.x支持将部分格式驱动编译成独立插件，便于按需加载。如果留空或者路径不存在，编译过程中会自动跳过插件格式支持。
CXX_OPTFLAGS = /Ox /DNDEBUG
优化选项。/Ox是最大优化，/DNDEBUG会禁用断言检查，这对性能密集型场景（如大规模遥感影像处理）很重要。注意：编译GDAL时不要加 /MT 或 /MD 混用错误，否则运行时库不一致会造成崩溃。
3.2 外部依赖库的启用与关闭
GDAL的强项之一就是支持格式丰富的栅格和矢量数据格式，但这些格式有些需要依赖外部库（JPEG、PNG、GEOTIFF等）。默认情况下很多依赖都是关闭的，需要手动打开或在源码目录里放置对应库文件。
我这次编译时刻意全部保持默认关闭状态。原因是老项目上用到的数据格式以Shapefile、GeoTIFF、IMG、MrSID为主，这些要么是内置支持，要么通过插件驱动实现，不需要外部依赖库。如果有需要额外格式（如PostgreSQL、SQLite、HDF5），就得事先准备好对应库并进行配置，调过依赖库匹配的都知道，版本对不上编译期各种cast错误跑都跑不完，老项目能少碰就少碰。
注意：GDAL 1.11的nmake.opt中有默认打开的部分依赖项，如 libpng、zlib 在某些版本里是自带源码的。如果编译中报错找不到这些依赖，检查一下 “GDAL 源码目录\frmts\png” 和 “frmts\zlib” 这些目录下有没有对应源码，缺少时从官网补齐即可。
4. 编译、安装与验证的完整实操记录
4.1 三条命令的完整执行过程
环境准备好后，打开“VS2010 x64 兼容工具命令提示符”（或对应的32位版本），进入源码目录，依次执行：
第一步：执行主编译
cd /d D:\src\gdal-1.11.2 nmake /f makefile.vc MSVC_VER=1600 WIN64=NO这里以32位版本为例示范。如果所有配置正确，编译大概耗时10-20分钟（取决于机器配置），每编译完一个模块（port、gcore、frmts、ogr、apps），终端都会输出对应的 obj 文件清单。第一次编译建议全程盯着，一旦出现Error就直接看前一条warning，大多数问题都能顺藤摸瓜找到。
提示：出现“NMAKE : fatal error U1077”这种错误的时候，会比较难判断问题在哪，但经验是80%出在编译器环境不对，先确认当前命令提示符的编译器版本再说。
第二步：安装到系统目录
nmake /f makefile.vc MSVC_VER=1600 install这条命令把核心DLL（gdal.dll）和命令行工具复制到$(GDAL_HOME)\bin目录。如果之前在 nmake.opt 里没设GDAL_HOME，默认会装到C:\Program Files\GDAL。
第三步：安装开发库
nmake /f makefile.vc MSVC_VER=1600 devinstall这条命令把头文件、导入库、.lib静态库等安装到$(GDAL_HOME)\include和$(GDAL_HOME)\lib目录。以后其他项目想用GDAL，配置头文件搜索路径、库文件搜索路径分别指到这里就行。
4.2 安装目录结构解析
编译安装完成后，GDAL_HOME 目录下应该是这个结构：
C:\GDAL ├── bin\ │ ├── gdal.dll │ ├── gdal_contour.exe │ ├── gdal_translate.exe │ ├── ogr2ogr.exe │ └── ...其他命令行工具 ├── include\ │ ├── gdal_priv.h │ ├── gdalwarper.h │ ├── ogr_api.h │ └── ...其他头文件 ├── lib\ │ ├── gdal.lib │ ├── gdal_i.lib │ └── ...插件dll文件 └── data\ ├── csv\ ├── gdal_datum.csv └── ...坐标参考相关数据文件看到这个结构基本就算成功了。我自己遇到过的老项目中，有些同事只跑 install 忘了跑 devinstall，程序运行没问题但后续开发环境引用不了头文件，非常头疼。
4.3 功能验证三板斧
编译成功不等于没毛病，完整验证得做三步：
第一步：命令行验证
C:\GDAL\bin\gdalinfo.exe --version能正确输出 “GDAL 1.11.2, released 2015/02/10” 之类的版本信息，说明DLL加载正常，基础功能没问题。
第二步：环境变量配置
把C:\GDAL\bin加入系统PATH；新建两个系统环境变量：
GDAL_DATA = C:\GDAL\data GDAL_DRIVER_PATH = C:\GDAL\lib\gdalpluginsGDAL_DATA不配的话，EPSG坐标参考编码查不到，这是最经典的运行时问题；GDAL_DRIVER_PATH不配的话，部分以插件形式存在的格式驱动不会被加载。
第三步：用真实数据测试转换
用系统里存的老影像文件（或自己合成的测试tif）跑转换命令：
gdal_translate -of GTiff test.img E:\output\test_new.tif如果能正常生成输出文件并打印出尺寸、波段数、坐标范围等元数据，说明最关键的基础路径是通的。
5. 编译图形库与Python绑定的扩展操作
5.1 在VS2010下编译C++图形扩展库
老GIS项目里经常会用到GDAL的可视化渲染场景，这里补充一个常见需求—— 在VS2010下编译GDAL的图形库扩展，用于绘制统计图表和地图渲染。
GDAL生态里与图形直接相关的主要是libpng、libjpeg、giflib等三方库。这里以 libpng 为例说明方法：
第一步：下载适配版本
VS2010对应C89标准，建议选择 libpng 1.6.x 系列，代码兼容性和稳定性都比较好。源码放置到D:\src\gdal-1.11.2\frmts\png\libpng下（如果目录不存在就新建，注意目录名必须使用小写）。
第二步：修改 nmake.opt 打开依赖开关
找到nmake.opt中关于PNG的配置项，默认时PNG_EXTERNAL_LIB = 1是注释掉的，放开注释或改成1，指定库路径。
PNG_EXTERNAL_LIB = 1 PNG_INCLUDE = -ID:\src\gdal-1.11.2\frmts\png\libpng PNG_LIB = D:\src\gdal-1.11.2\frmts\png\libpng\libpng.lib第三步：重新编译GDAL
nmake /f makefile.vc MSVC_VER=1600 clean nmake /f makefile.vc MSVC_VER=1600编译完成后，GDAL就具备读取和写入PNG格式栅格数据的能力了。这个方法可以类推到JPEG、TIFF等依赖库，核心思想就一点：找到对应库源码，在nmake.opt里打开开关并指对路径，重新全量编译。
5.2 Python绑定编译的取舍方案
我现在明白为什么热词里会同时出现“gdal 3.10.1 cp313 cp313 win_amd64.whl”和“python安装gdal”—— 新一代的GIS开发者接触GDAL，大多数冲Python来的。但这里必须做个区分：GDAL 1.11时代的Python绑定跟今天的pygdal完全是两码事。
GDAL 1.11官方自带的Python绑定基于Python 2.7 / 3.4时代，用的还是distutils那一套。如果你在今天（2025年）想在Python 3.13上调用GDAL，就别指望GDAL 1.11的官方绑定——它连编译都过不了。
我的建议是分场景做取舍：
- 纯Python开发新项目：直接用pip安装新版GDAL的Python轮子，类似
pip install gdal==3.10.1（对应CPython 3.13的win_amd64环境），不要去碰老版本。新版轮子自带独立的GDAL库，跟老系统的GDAL 1.11互不干扰。 - 在C++老项目里集成Python脚本：保留GDAL 1.11的C++ API，Python侧用新的pyogrio、fiona等库做数据读取，两边通过文件或数据库交换数据，而不是强行绑定。
- 必须让老版本GDAL和Python通信：编译一个Python 3.5时代同一个小版本的绑定（如CPython 3.5 + GDAL 1.11），保证运行库一致，然后用subprocess方式调用，绕开扩展模块ABI兼容性问题。
来回折腾之后，长期维护的老系统里，新老Python绑定混用、GDAL版本混用，还真不如把边界切干净省心。
5.3 命令行工具的日常使用技巧
编译完成后，日常用得最多的是这几个工具：
gdalinfo：查看影像信息。
gdalinfo C:\data\卫星影像.tif输出内容包括尺寸、波段数、像元大小、投影坐标系、地理范围、金字塔级别等，快速判断数据质量就看这个。
gdal_translate：格式转换和裁剪。
gdal_translate -projwin 120.2 30.3 121.1 29.8 -of GTiff C:\data\原图.img C:\data\裁剪后.tif-projwin参数依次是左上角X、左上角Y、右下角X、右下角Y（对应投影坐标），用于空间裁剪。遇到大文件时，建议加-co TILED=YES -co COMPRESS=LZW两个选项，生成GeoTIFF时能显著提高打开速度和压缩率。
ogr2ogr：矢量格式转换。
ogr2ogr -f "ESRI Shapefile" C:\output\out.shp C:\input\原始数据.mdb这个命令支持上百种矢量格式互换，字段类型映射、坐标转换都封在内部，平时处理空间数据够够的。
6. 常见编译问题与排查手册
6.1 nmake.opt和makefile.vc相关报错速查
表里的每一条都是我实际编译中遇到过的，不是从文档里抄来的：
| 报错信息 | 可能原因 | 解决办法 |
|---|---|---|
NMAKE : fatal error U1077 | 编译器环境不对或路径含空格 | 重新打开VS2010对应的命令提示符，检查路径无空格 |
无法打开包含文件:stdint.h | 编译器版本过老，缺少C99标准头文件 | GDAL源码port目录自带兼容实现，确认源码目录完整，不要只拷贝部分文件 |
c1038: 编译器内部错误 | 优化选项冲突 | 把 CXX_OPTFLAGS 从 /Ox 临时改成 /Od 再编译一次，能过就是优化参数问题 |
unresolved external symbol | lib文件没配或顺序不对 | 检查项目配置中的附加依赖项，确保 gdal_i.lib 在链接列表里 |
error C2664: “…无法将参数 1 从…转换为…” | 编译器不一致，调用方用了更高版本编译器 | 确认整个项目所有模块都用VS2010编译，不要混用版本 |
6.2 运行时问题与解决方案
编译通过只是第一关，运行时的问题更隐蔽，坑也更深：
问题一：找不到gdal.dll
程序编译通过，但一运行就报“无法加载gdal.dll”。多半是C:\GDAL\bin没在PATH里，或者运行环境是64位但装了32位DLL。解决方法是把C:\GDAL\bin加到系统PATH最前面，然后再开一个新的命令行窗口测试。
问题二：EPSG坐标参考全部显示为 unknown
这就是前面提到的GDAL_DATA环境变量没配置。GDAL 1.11在没有GDAL_DATA时会去当前目录找数据文件，找不到就全部返回unknown。配置好GDAL_DATA并指向data目录后，重启应用（或进程）即正常。
问题三：Release版本编译成功但Debug版本崩溃
这个问题很经典。GDAL 1.x的调试版和发布版可能使用不同的运行时库。调试程序时，如果GDAL是 /MD（发布版运行时库）编译，而自己的程序是 /MDd（调试版运行时库），混合使用会引起堆损坏。解决方案是一致使用/MD编译项目中的所有模块。
问题四：多线程环境下偶尔崩溃
老版本GDAL对线程安全的支持还不如现在，1.11版需要调用GDALAllRegister之后获得线程局部句柄再干活，而在多线程并发时某些驱动会出问题。如果遇到随机崩溃，检查代码是不是多个线程共享同一个GDALDataset指针进行操作，加锁或者每个线程独立打开数据源是比较好的做法。
6.3 性能调优的几条经验
编译完还能再压榨一下性能，下面三个点是我反复验证有效的：
- 开启 /O2 优化配合 /GL（链接时代码生成），GDAL整体吞吐大约有5%-10%的提升。代价是编译时间变长、二进制体积变大，老项目如果对性能敏感可以试试。
- 启用GeoTIFF内部压缩写加强在大批量影像转换时，给 gdal_translate 加
-co COMPRESS=LZW -co TILED=YES -co BLOCKXSIZE=256 -co BLOCKYSIZE=256，输出文件的体积减少50%-70%，打开预览速度提升明显。 - 设置缓存大小在程序中调用
GDALSetCacheMax(64 * 1024 * 1024)将读块缓存提高到64MB，处理大数据量的重采样、投影转换时会有立竿见影的效果。
7. 环境升级与长期维护的一点体会
编译GDAL 1.11 + VS2010这件事本身不难，难的是在“老环境必须支持”和“长期可维护”之间找到平衡点。
我在处理这个老系统时有一个原则：老系统能不动就不动，新系统能隔离就隔离。老水利系统保持GDAL 1.11 + VS2010不变，跑得稳比跑得快重要；但新接手的数据处理模块，我已经在引导团队用Python的 GDAL 3.x 轮子或者PostGIS做事了，两边通过文件或数据库对接数据，不搞进程内混用。这样可以避免老系统绑定技术栈，也为未来整体迁移做了铺垫。
还有一个多数人容易忽视的点：老版本GDAL的源码包要做好归档。把gdal-1.11.2源码、VS2010编译器安装包、SP1补丁、编译好的完整目录（包含bin/include/lib/data），全部压成一个压缩包，放到项目文档服务器上。等若干年后你要在新电脑上重新搭建这套环境时，就明白这一步值多少钱了。我就是因为当年没存好，这次折腾着重新下源码、找补丁，白白浪费了大半天时间。
最后分享一个小技巧：把编译好的C:\GDAL目录复制一份到其它机器上，装上VS2010对应的VC++运行库（vcredist_x86.exe / vcredist_x64.exe），基本上就能直接跑命令行工具，不需要每台机器都装完整VS环境。这个过程叫“绿色部署”，OSGeo4W也是类似的护法思路，只是我们手工做了而已。老系统的维护就是这样—— 多用工程手段，少走回头路。
本文还有配套的精品资源，点击获取
