简介资源为基于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_VER1600 nmake /f makefile.vc MSVC_VER1600 install nmake /f makefile.vc MSVC_VER1600 devinstall其中 MSVC_VER1600 是VS2010编译器版本号。这个参数必须显式指定因为nmake脚本会通过它判断是调用哪个版本的编译器。VS2008对应1500VS2010对应1600VS2012对应1700VS2013对应1800VS2015对应1900。不同版本的编译器对C标准的支持程度不一样如果不显式指定脚本可能在环境检测上出现偏差。提示如果这条命令在64位系统上第一次执行时报“无法打开包含文件:stdint.h”先别急着改源码—— 检查一下是不是环境变量问题正常情况VS2010本身不带stdint.hGDAL源码的 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_VER1600 WIN64NO这里以32位版本为例示范。如果所有配置正确编译大概耗时10-20分钟取决于机器配置每编译完一个模块port、gcore、frmts、ogr、apps终端都会输出对应的 obj 文件清单。第一次编译建议全程盯着一旦出现Error就直接看前一条warning大多数问题都能顺藤摸瓜找到。提示出现“NMAKE : fatal error U1077”这种错误的时候会比较难判断问题在哪但经验是80%出在编译器环境不对先确认当前命令提示符的编译器版本再说。第二步安装到系统目录nmake /f makefile.vc MSVC_VER1600 install这条命令把核心DLLgdal.dll和命令行工具复制到$(GDAL_HOME)\bin目录。如果之前在 nmake.opt 里没设GDAL_HOME默认会装到C:\Program Files\GDAL。第三步安装开发库nmake /f makefile.vc MSVC_VER1600 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第三步重新编译GDALnmake /f makefile.vc MSVC_VER1600 clean nmake /f makefile.vc MSVC_VER1600编译完成后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 gdal3.10.1对应CPython 3.13的win_amd64环境不要去碰老版本。新版轮子自带独立的GDAL库跟老系统的GDAL 1.11互不干扰。在C老项目里集成Python脚本保留GDAL 1.11的C APIPython侧用新的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 TILEDYES -co COMPRESSLZW两个选项生成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 symbollib文件没配或顺序不对检查项目配置中的附加依赖项确保 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 COMPRESSLZW -co TILEDYES -co BLOCKXSIZE256 -co BLOCKYSIZE256输出文件的体积减少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也是类似的护法思路只是我们手工做了而已。老系统的维护就是这样—— 多用工程手段少走回头路。本文还有配套的精品资源点击获取