★ FEATURED ARTICLE 简介针对Python 2.7环境下在Win7 64位平台安装GDAL的实战指南面向需要处理地理空间数据的Python开发者、GIS初学者。资源为一份docx文档共1个文件包体仅95KB内容精炼。已有628人浏览学习。文档完整记录两种安装路径利用core代码配合SWIG自行编译以及直接下载官方MSI安装并详细列出过程中常见的错误及解决办法如swig.exe缺失需安装swig2.10.0并配置环境变量以及ImportError DLL load failed时需将GDAL的bin目录加入Path。此外还介绍了Visual Studio 2010与GEOS 3.3.8等依赖项的准备工作帮助读者理清安装顺序与依赖关系。适合在旧版Python环境搭建GIS开发环境时作为参考。1. 一个老组合的安装困境Python 2.7 的 GDAL 在 Win7 64 位机上为什么总装不上GDAL 在 Win7 64 位平台上的 Python 2.7 安装几乎是每个做遥感、GIS 数据处理的开发者都绕不开的一道坎。这套组合放在今天看确实老旧但很多存量项目、教学代码和内部工具还跑在 Python 2.7 上而 GDAL 恰恰是读取栅格、矢量数据最常用的库。装不好会怎样最常见的就是你在 Python 里敲import gdal迎面一句ImportError: DLL load failed: 找不到指定的模块毫无头绪卡上半天。这篇文章记录的是一套真实踩过坑、最终跑通的完整安装流程覆盖两个方案——官方 MSI 直装和源码 swig 自编译以及对应的版本选择思路和三个高频报错的排查方法。适合正卡在 GDAL 安装上的同学照着走也适合想理解 GDAL 绑定结构、自己动手编译的开发者参考。整个安装过程中每一步参数和路径都写清楚新手能一步步走通熟手也能看到版本差异和取舍逻辑。2. 装前准备环境依赖与两条安装路线的取舍2.1 依赖清单VS2010、GEOS 3.3.8、Python 2.7 缺一不可GDAL 不是一个单纯 pip 能解决的问题它底层依赖 C 编译产物和一堆动态链接库。在 Win7 64 位平台上装 Python 2.7 版 GDAL需要先明确环境里有哪些东西、各自起什么作用。下面列一份我最终跑通时的完整环境清单依赖项版本作用备注操作系统Windows 7 64 位基础平台路径和命令均以 64 位为准Visual Studio2010提供 nmake 和 C 编译环境源码编译方案必需MSI 方案不强制GDAL core1.9.2核心 C 库提供 gdalinfo 等工具1.11.0 也可但 1.9.2 资料更全GEOS3.3.8几何运算依赖库装完 GDAL 后需把对应 DLL 所在目录加入 PathPython2.7运行脚本环境注意位数必须和 GDAL 一致64 位 Python 配 64 位 GDALSWIG2.10.0生成 Python 绑定代码仅源码编译方案需要这里有个容易被忽略的点GDAL 的 MSI 安装包和源码包是两套东西。官方提供的 MSI 是预编译好的二进制装上就能用源码包里带的是 swig/python 目录需要自己执行 nmake 编译生成 Python 扩展。两者不是替代关系而是两种完全不同的安装路径下文分别展开。GEOS 3.3.8 作为几何库主要服务于 GDAL 处理矢量几何时的方法调用只做栅格读写的场景不一定触发但既然整体环境要求里有它建议还是按清单装齐避免后续某个功能调不到库。2.2 版本选择为什么最后选了 GDAL 1.9.2 而不是 1.11.0GDAL 官方对 Windows 平台的老版本支持向来不算友好尤其是 Python 2.7 这个年代久远的版本新版本绑定代码对旧编译器兼容性差报错信息也往往不够直观。我在实际安装时先试了当时最新的 GDAL 1.11.0理论上同样可以用但重新配置过程中发现一个问题网上关于 1.11.0 的资料明显比 1.9.2 少遇到报错能查到的解决方案也少。最后我退回 1.9.2纯粹是因为这个版本在 Win7 Python 2.7 的场景下被踩过太多回几乎所有错误都能搜到现成答案。给一个可复用的版本选择逻辑先看 Python 版本2.7 就优先选 1.9.x如果 Python 版本更接近 3.x那 GDAL 版本要相应上调但 Python 2.7 配太新的 GDAL 很可能出现 swig 生成的绑定代码语法不兼容的问题。其次是看编译器VS2010 意味着 nmake 的版本是 10.00.30319.01这个环境下 GDAL 1.9.2 的 makefile 是验证过能走的换 VS2008 或 VS2012 都可能需要额外调整环境变量。最后才是功能需求GDAL 1.9.2 对绝大多数栅格格式和矢量格式的支持已经足够用没必要为了用新格式去冒安装风险。2.3 两条路线的取舍官方 MSI 直装和 swig 自编译哪个适合你官方给出了两种可选方案一是利用 core 代码自带的 swig/python 自己编译二是下载官方提供的 MSI 文件直接点击安装。两条路线我都完整实验过都成功但适合的人群完全不同。直接说结论如果你只是想快速在 Python 里用上 GDAL不想关心底层编译细节选 MSI 方案如果你想搞清楚 GDAL 的 Python 绑定是怎么生成的或者想改绑定代码选源码自编译方案。在实际工程中两种方案会直接影响后续的排错路径MSI 方案下 DLL 加载失败只需要查环境变量源码方案下失败还可能是 swig 版本问题、编译器版本问题、甚至 makefile 里的路径问题。对比项MSI 直装源码 swig 自编译安装耗时几分钟半小时到数小时依赖复杂度低高需要 VS2010 SWIG环境变量配置必须配 bin 到 Path同样必须配 bin 到 Path排错难度低中高适合场景快速跑通、生产环境部署学习源码结构、定制绑定风险点DLL 加载失败swig 缺失、Vcvarsall.bat 找不到中间如果拿不定主意我的建议是先走 MSI 方案把环境跑通再回头去折腾源码编译。这个顺序能帮你把一个变量环境配置和一个变量编译过程分开排查否则一旦出问题不知道是该怀疑 Path 配置还是该怀疑编译产物排查成本直接翻倍。这算是这次安装过程中最值得记住的一条经验。3. 路线一官方 MSI 直装 GDAL两步解决 DLL 环境3.1 下载与安装MSI 包版本必须对应 Python 2.7 的 64 位环境MSI 方案的思路很简单下载官方提供的 GDAL 安装包按引导安装完成再把安装目录下的 bin 文件夹加入系统 Path。高效的前提是版本选对MSI 文件名里通常会标注版本号和平台信息。以 1.9.2 为例安装包名称中应包含 x64 字样对应 64 位系统如果误装成 32 位版本随后在 64 位 Python 2.7 里 import gdal 时同样会报 DLL 加载失败而且报错信息几乎和路径问题一模一样非常容易混淆。这是一个很容易被忽视的点安装时多看一眼文件名能省掉后面一两个小时。安装过程本身很简单以管理员身份运行 MSI安装路径建议保持默认。对 1.9.2 来说默认安装目录为C:\Program Files\GDAL192。为什么不建议自定义路径因为后续所有教程和资料里的路径都以默认目录为例你一旦改了查资料时就要自己在心里换算一遍出错概率更大。GDAL 的 MSI 安装过程没有太多交互一路下一步即可装完先不要急着启动 Python先把环境变量配好否则必然会在 import 阶段撞上 DLL 问题。顺带说一句安装 MSI 之前确认 VS2010 和 GEOS 3.3.8 都已装好虽然 MSI 方案不依赖 VS2010但 GEOS 的 DLL 会被 GDAL 运行时调用缺少时会触发另一个 Dll load 失败。3.2 配置环境变量把 GDAL 的 bin 目录写进系统 Path这一步是整个 MSI 方案里最关键的配置项。强行忽略它也可以正常安装但跑到import gdal时就会触发当场翻车。操作路径是右键“计算机”选择“属性”点击“高级系统设置”在“高级”选项卡里点击“环境变量”在“系统变量”区域找到名为Path的变量点“编辑”在变量值末尾追加 GDAL 的 bin 目录。具体追加内容根据安装路径来默认情况下是C:\Program Files\GDAL192\bin也可以用命令行的方式追加。由于是在 Win7 上手动配置打开 cmd 直接执行下面的 setx效果等同setx Path %Path%;C:\Program Files\GDAL192\bin追加完 Path 后务必重开命令行窗口因为环境变量是进程启动时读取的旧窗口里改动的 Path 不会生效。这里需要说明一个细节为什么是 bin 目录而不其他因为 GDAL 的 Python 绑定模块在导入时需要通过动态链接方式找到gdal192.dll而 Windows 默认不会在当前目录或 Python 的 site-packages 目录下寻找 DLL只能靠系统 Path 中的目录。一旦找不到就会出现“找不到指定的模块”。把 bin 加进 Path就是告诉系统去哪里找gdal192.dll和其他相关 DLL这是 GDAL 安装中最基本也最容易被忽视的一步。3.3 验证导入from osgeo import gdal 一条命令判断成败环境变量配置完成后重新打开一个命令行窗口进入 Python 交互环境执行验证from osgeo import gdal print(gdal.VersionInfo())如果输出类似1910这样的版本号说明 GDAL 已经可以正常导入。需要注意旧版本 GDAL 的 Python 绑定同时支持import gdal和from osgeo import gdal两种写法但推荐统一用from osgeo import gdal因为后续版本已经逐步废弃顶层import gdal的方式。MSI 方案到这里就结束了总耗时不超过 10 分钟。不过看 gdalinfo 源码时能注意到GDAL core 的读取流程是打开数据源、获取驱动、读取栅格波段。如果你在后续使用中遇到“driver 未注册”或“无法识别格式”的问题多半是 GDAL_DATA 环境变量没有配置或配置错误这个不在本节范围内留在验证一章里展开。MSI 方案能以最少步骤跑通路径配置是唯一的坎跨过去就顺了。4. 路线二源码自编译 swig/python动手构建 Python 绑定4.1 用 X64 兼容命令提示符构建 GDAL core先给自己一个干净的编译环境源码方案的第一步是拿到一个正确的编译环境。GDAL 1.9.2 的源码包默认通过 nmake 构建而 nmake 不是一个独立可执行文件它依赖 Visual Studio 提供的一系列环境变量和工具链。直接打开普通的 cmd 窗口执行 nmake 会得到“不是内部或外部命令”的报错。正确做法是以管理员身份打开“开始”菜单依次进入“所有程序”找到 Microsoft Visual Studio 2010 目录下的 Visual Studio Tools然后打开“Visual Studio X64 兼容工具命令提示符”。这个工具会自动设置好 64 位编译相关的环境变量包括 nmake 的路径。注意这里一定要选 X64 兼容命令提示符而不是普通的命令提示符否则后续编译出来的 DLL 可能是 32 位的与 64 位 Python 2.7 不匹配最终还是会卡在 DLL 加载。打开正确的命令提示符后切到 GDAL 源码解压目录下的 swig 目录。以我的环境为例源码解压在C:\OGC\GDAL192\gdal-1.9.2所以执行cd C:\OGC\GDAL192\gdal-1.9.2\swig4.2 执行 nmake 生成 Python 绑定会遇到不太常见的一个问题进入 swig 目录后执行编译命令准备让 nmake 根据 makefile.vc 生成 Python 绑定代码nmake /f makefile.vc python这条命令的作用是调用 makefile.vc 中的 python 目标它会先去检测 swig.exe 是否存在然后执行 swig 命令生成gdalconst_wrap.c、gdal_wrap.c等绑定代码最后调用编译器把它们编译成_gdal.pyd。在这个场景下第一次执行大概率会在中间出现swig.exe 不是内部或外部命令的报错并伴随 nmake 的fatal error U1077退出。出现这个现象的原因很简单系统环境里没有安装 SWIG 工具。解决方式是下载 SWIG 2.10.0解压后将 swig.exe 所在的目录追加到系统 Path 环境变量中然后重开命令行窗口再次执行上面的 nmake 命令一般就能顺利通过这一步。SWIG 2.10.0 是兼容这套老环境的一个版本太新的 SWIG 生成代码可能依赖较新的 Python 特性反而不适合 Python 2.7。4.3 安装 Python 扩展时遇到 Vcvarsall.bat 找不到直接用环境变量绕过nmake 流程跑完后当前目录下会生成一个 python 子目录绑定代码和 setup.py 都在里面。切换到该目录并执行 Python 的构建与安装命令cd python python setup.py build python setup.py install构建到一半时大概率会出现unable to find Vcvarsall.bat的错误。这个报错的原因是 distutils 在查找 VS2008 的环境配置文件因为它默认认为 Python 2.7 是用 VS2008 编译的。而当前机器只装了 VS2010没有 VS2008所以找不到对应的 Vcvarsall.bat。网络上有建议改用 mingw 编译的我试验过在这个老 GDAL Python 2.7 组合下基本走不通会遇到格式兼容、缺少头文件等一系列问题。实际能直接绕过这个检查的办法是在命令行窗口手动设置一个环境变量set VS90COMNTOOLS%VS100COMNTOOLS%这条命令的作用是把 VS2010 的工具集路径临时伪装成 VS2008 的路径让 distutils 能正常找到编译器。注意这里用的是set而不是setx意思是只在当前命令行窗口生效不影响系统全局设置。执行完这条命令后重新执行python setup.py build python setup.py install这次 build 过程会输出大量编译信息中间夹杂很多 warning这是正常的不需要逐一处理。只要最终能看到Finished processing dependencies或类似字样说明绑定模块已经被复制到 Python 的 site-packages 目录下这一步就算过了。这里有个常见的误解看到屏幕上滚过一篇红色警告就以为失败了其实真正失败时 nmake 会直接报 U1077 中断而 build 阶段的多数报警是编译器对旧代码的兼容性提示不影响最终产物。4.4 编译完成也不能忽略的收尾配置bin 目录依然要进 Path源码编译完成后不要以为事情就结束了。编译出来的 Python 绑定模块_gdal.pyd只是 GDAL Python 层的壳真正执行读写操作的是gdal192.dll。此时在命令行里执行python -c from osgeo import gdal大概率仍会碰到那个熟悉的ImportError: DLL load failed: 找不到指定的模块。这不是编译失败了而是 Python 找不到底层 DLL。解决方式和 MSI 方案完全一致把 GDAL 编译安装目录下的 bin 目录加入系统 Path。无论哪种安装方式这一步都省不掉因为 Windows 的动态链接库搜索机制不认 Python 的 site-packages它只认系统 Path 里的目录。我把这一步放在最后讲是想强调一个容易忽略的细节源码方案虽然过程复杂但最终产生的问题和 MSI 方案是同一个排查方向不要跑偏。在配置 Path 时注意区分 GDAL core 的 bin 目录和 Python 安装目录下的 Scripts 目录两者职责完全不同前者管 DLL后者管可执行脚本需要分开追加。5. GDAL 安装避坑三个高频报错的现场重演5.1 错误一swig.exe 不是内部或外部命令也不是可运行的程序现象在 swig 目录下执行nmake /f makefile.vc python终端直接提示 swig.exe 不是内部或外部命令随后 nmake 报fatal error U1077退出构建中止。原因SWIG 工具根本没有安装或者安装了但没把可执行文件所在目录加入 Path。nmake 在执行 makefile.vc 时会调用 swig.exe 来解析.i接口文件并生成 C 包装代码这一步是整个 Python 绑定生成机制的起点缺失 swig 就等于断了源头。解决下载 SWIG 2.10.0解压后把 swig.exe 所在目录追加到系统 Path重开命令行窗口再次执行原命令。注意一定要重开窗口否则新追加的 Path 不会加载到当前进程。5.2 错误二unable to find Vcvarsall.bat现象执行python setup.py build时distutils 抛出unable to find Vcvarsall.bat构建无法继续。原因Python 2.7 的官方安装包是用 VS2008 编译的因此 distutils 在构建扩展模块时会优先查找 VS2008 的 Vcvarsall.bat。机器上只装了 VS2010 时根本没有 VS2008 的路径可查于是判定为找不到编译器。解决在命令行窗口执行set VS90COMNTOOLS%VS100COMNTOOLS%把 VS2010 的环境变量伪装成 VS2008。这个方案比换 mingw 靠谱得多我亲自试过 mingw 路线折腾半天依旧会出现各种库兼容问题。另外提醒一句如果你装了 VS2008这一步可以直接跳过。5.3 错误三ImportError: DLL load failed: 找不到指定的模块现象MSI 安装完成或源码编译完成在 Python 中执行import gdal抛出ImportError: DLL load failed: 找不到指定的模块堆栈中能看到 osgeo 包的swig_import_helper内部加载失败。原因这是整个安装过程中最容易让人心态炸裂的报错也是最常见的问题。核心原因就是 Python 在导入_gdal.pyd时需要动态加载gdal192.dll但这个 DLL 所在的 bin 目录没有在系统 Path 中所以系统找不到指定模块。小问题纠结老半天通常就是差这一步。解决把 GDAL 安装目录下的 bin 目录追加到系统 Path。MSI 默认路径追加C:\Program Files\GDAL192\bin源码编译场景则追加你编译产物所在的 bin 目录。追加后重启命令行窗口再执行from osgeo import gdal。如果依然报同样错误检查 Python 是否 64 位以及安装的 GDAL 是否也是 64 位版本位数不一致也会复现同一个错误。5.4 容易忽略的连带问题装了两个 GDAL命令就不知所踪了现象环境里同时存在 MSI 安装的 GDAL 和源码编译的 GDAL命令行执行 gdalinfo 时报错或版本对不上Python 里 import 的也可能不是你期待的那份。原因MSI 和源码编译各自会把文件复制到不同位置但都会往 Python 的 site-packages 写入同名包。Path 中前面的目录优先生效两个版本互相覆盖导入时拿到哪个完全取决于系统搜索顺序难排查到。解决只保留一条安装路线的产物删掉另一条。以 ms 为主先卸载 MSI 版再把源码编译版的相关目录从 Path 和环境变量中清理干净。如果不确定哪些文件残留可以在 Python 里查看实际加载路径一般写在osgeo包的__file__属性里。切记不要两个版本共存后续调试时完全分不清来源。6. 装完怎么验证跑通用 gdalinfo 和一段小脚本确认环境可用6.1 命令行三件套快速确认 DLL 与版本状态不依赖任何 IDE直接开一个 cmd依次执行三条命令确认基础环境健康。python -c from osgeo import gdal; print(gdal.VersionInfo())输出1910之类的版本号说明 Python 已能加载 GDAL。第二步gdalinfo --version这个命令确保命令行工具本身就绪且能拿到同一个版本的 GDAL 二进制。第三步python -c from osgeo.gdalconst import *; print(ok)确认 gdalconst 模块的绑定也是通的。这三条命令覆盖了 GDAL Python 绑定的完整调用链Python 找到绑定模块、绑定模块找到 DLL、命令行工具找到同一套二进制。三条都通过环境基本没有问题了。如果第一条过而第二条报错问题大概率出在系统 Path 里 GDAL 的 bin 目录没有配好如果第一条报错而第二条正常问题出在 Python 环境本身比如 32 位 Python 装了 64 位 GDAL。6.2 用 gdalinfo 读一张实际的栅格图最简单的落地验证环境变量验证通过只说明“库能加载”还不能说明“数据能读”。用 gdalinfo 读取一张真实的栅格文件才算跑通完整调用链路。gdalinfo E:\test_data\landsat8\LC08_L1TP_001001_20180601_B1.TIF输出中重点看几个信息Driver是否正常识别为 GTiffSize是否匹配图像真实尺寸Band 1下方的Type和NoData Value是否符合预期。如果报错Unable to open优先检查文件路径和文件名是否有中文GDAL 老版本在 Windows 上对中文路径支持并不稳定实际使用中建议把测试数据放到纯英文路径下比如E:\test_data\避开中文目录是最省事的习惯。这个验证方式比单纯 import 更接近实际业务场景数据能成功打开说明从 Python 绑定到底层驱动再到文件格式解析整条链路都是通的。6.3 留一个习惯每次换机器装机都强制走一遍三件套从那次安装之后我养成了一个习惯任何一台新机器装完 GDAL不管用的是 MSI 还是源码编译第一时间跑上面三件套而不是直接打开业务脚本。这个习惯帮我挡掉了不少换机后的低级问题。有一次在另一台 Win7 上import 正常但 gdalinfo 怎么都调不到版本最后检查出来是系统 Path 里同时存在两个版本的 bin新旧 DLL 互相干扰清理后才恢复。有了这套验证方法开发时至少能确定“环境没问题的前提”是成立的剩下排错就能放心地去找代码本身的毛病。这个组合的安装本身不难难的是版本选错、路径没配、位数不匹配这些细枝末节的纠缠。希望这份笔记能帮你少走一些弯路一次把 GDAL 在 Python 2.7 的 Win7 环境里装通。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
