★ FEATURED ARTICLE 简介在Windows 7 64位平台搭配Python 2.7安装GDAL是很多GIS脚本开发者和遥感数据学习者常遇到的麻烦事尤其会牵涉Visual Studio版本、GEOS依赖、环境变量与DLL引用等一连串坑。这份docx文档把完整过程整理成了可复用的排错笔记明确区分了两条路径一是基于GDAL core自带swig/python手工编译适合想了解底层构建流程的读者二是下载官方msi直接安装适合快速上手、以应用为主的用户。文中还交代了Visual Studio 2010、GEOS 3.3.8、Python 2.7等前置条件并针对swig.exe未找到、Vcvarsall.bat缺失、ImportError DLL load failed这类高频报错逐条给出了解决办法尤其是将gdal安装目录下的bin文件夹加入环境变量Path这一步能直接解决Python找不到gdal192.dll的问题。整份压缩包只有1个docx文件大小95KB内容集中、不掺杂质已有628人学习浏览。对正在搭建Python 2.7 GDAL环境的研究者来说这是一份能照着排查、少走弯路的实用参考资料。1. Win7 64位下给Python2.7装GDAL你踩的坑基本都在这一篇上周在一台Win7 64位机器上给Python 2.7配置GDAL折腾了整整两天才跑通。这个组合今天看起来有点老旧但接手老GIS项目的人大概率还得面对它。最折磨人的不是编译本身而是一个又一个“找不到”——swig.exe不是内部或外部命令、Vcvarsall.bat找不到、DLL load failed。其中DLL加载失败最玄学网上各式各样的说法都有实际上往往只是环境变量里少了一个bin目录。这篇笔记把我试过的两条路都完整走了一遍源码编译和官方MSI安装并且把每一步报错的现象、原因和解决方式拆开写。手里正卡在GDAL安装上的开发者照着做能省掉一晚上的排查时间。2. 装前准备环境清单与版本取舍在动手之前我先把环境清单列清楚Win7 64位、VS2010、GDAL 1.9.2、GEOS 3.3.8、Python 2.7。这套组合看似杂乱实际每条依赖都有自己的角色。把它们之间的关系理清后面的报错才不至于瞎找。2.1 依赖关系VS2010、GEOS和Python2.7各管什么VS2010不是Python包而是一个C编译环境。如果走源码编译路线GDAL的C核心库需要VC编译器来编如果走MSI安装路线其实根本不需要VS2010。但问题是Python 2.7的官方Windows安装包是用VS2008VC9编译的distutils在build扩展时默认去找VS2008的工具集这就为后面的Vcvarsall.bat报错埋下了伏笔。这一点知道就行下一章会专门处理。GEOS 3.3.8是GDAL做矢量几何计算时依赖的库。如果只是用GDAL读写栅格数据它不参与工作如果要编译包含矢量拓扑功能的完整GDAL配置依赖时会用到。我在实际操作中没单独安装GEOS的Python绑定因为GDAL自带了对GEOS的调用支持前提是编译时能找到GEOS开发库。Python 2.7是你的使用端。无论走哪条路线最终产物都是把GDAL封装成Python模块放到site-packages里供import。Python的位数特别重要Win7 64位系统上可以装32位Python也可以装64位Python两条路都没问题但GDAL的版本位数必须和Python一致否则就会出现典型的DLL加载失败。检查当前Python位数的方式是打开cmd执行python -c import platform; print(platform.architecture())输出形如“(32bit, WindowsPE)”或“(64bit, WindowsPE)”记下这个结果后续下载MSI或编译时都要对着它选。组件版本作用是否必须VS201010.0编译C核心库、提供nmake环境源码编译必须MSI方案可不装GDAL1.9.2栅格/矢量读写核心必须GEOS3.3.8矢量几何计算依赖涉及矢量功能编译时需要Python2.7运行环境、安装绑定模块必须2.2 版本选择GDAL 1.9.2还是GDAL 1.11.0原笔记里提到尝试过GDAL 1.11.0也确认过可以同法安装但最终用了1.9.2。这种“退回老版本”的做法在Windows老环境里非常常见。我的判断是1.9.2在Win7 Python 2.7这个组合下资料最齐报错时的解决方案一搜就有1.11.0虽然功能更新但安装流程本质上一样不存在“新版必须换装法”这种说法。如果是走MSI路线版本选择影响更大。官方历史版本的MSI安装包对应不同Python版本需要确认文件名里写的Python版本是2.7并且匹配之前查到的位数。有些MSI同时支持32/64位有些则分开了下载时特别注意。选错位数不会给你任何提示装完import才报错非常浪费时间。我个人的习惯是系统Python是2.7就优先用GDAL 1.9.2或1.11.0这种和它同一时代的版本避免用太老的稳定版或太新的开发版去跟Python 2.7的ABI硬凑。新版本不一定兼容2.7的C API别给自己找事。2.3 目录规划路径里别带空格统一放在英文目录安装GDAL的路径值得在开工前就定好。我把源码解压到C:\OGC\GDAL192\gdal-1.9.2这很关键。Windows下Program Files这类带空格的目录在普通资源管理器里很好用但一旦进入nmake、swig、setup.py这类命令行工具空格会被解析成参数字符串的分隔符轻则路径找不到重则编译到一半莫名其妙失败。C:\OGC\GDAL192\gdal-1.9.2C:\OGC是我习惯的地理数据工作目录你也可以换成自己的盘符但一定要保证全路径没有空格、没有中文。MSI方案虽然能装到默认的Program Files目录安装后我也建议把它加入Path时写成完整的短路径必要时用8.3短名或环境变量替代。另外VS2010本身带空格的路径是系统自动处理的使用它提供的命令提示符工具启动时环境变量已经封装好不会出问题。真正要小心的是你自己拷贝的压缩包、解压目录和后续设置的Path。3. 源码编译用SWIG把GDAL核心绑到Python 2.7如果你想知道GDAL到底是怎么把C能力暴露给Python的走一遍源码编译比看十篇原理文章都管用。这个过程会依次依赖VS2010、SWIG和Python2.7的distutils每一步都可能卡住但每一步卡住的原因都是固定的排查起来并不难。3.1 打开VS2010 X64兼容命令提示符首先不要直接在普通cmd窗口里敲nmake会提示找不到命令。必须以管理员身份打开“开始 所有程序 Visual Studio 2010 Visual Studio Tools Visual Studio X64兼容工具命令提示符”。这个入口会预置VC的路径环境让编译器、链接器和nmake程序维护工具都可用。打开后先切换到源码目录cd C:\OGC\GDAL192\gdal-1.9.2\swig这一步要在命令行里能看到“C:\OGC\GDAL192\gdal-1.9.2\swig”这样的提示符说明切换成功。如果提示路径不存在检查压缩包是否解压完整或者目录名是否写错gdal-1.9.2目录名必须与压缩包解压出来的实际名称一致。第一次敲nmake前确认swig目录下确实有makefile.vc这个文件。它是专门为VC编译器写的makefile里面描述了怎么用SWIG工具把gdal的C接口生成Python包装代码。3.2 安装SWIG 2.10.0并加入Path执行编译命令nmake /f makefile.vc python大概率你会撞见第一个错误swig.exe 不是内部或外部命令也不是可运行的程序或批处理文件。原因很简单机器上没有安装SWIG。SWIGSimplified Wrapper and Interface Generator负责读取gdal的接口文件生成Python和C之间的胶水层代码缺少它整个编译无从谈起。解决办法是下载swigwin-2.10.0Windows版解压到C:\swigwin-2.10.0然后把解压目录加入Pathset PATHC:\swigwin-2.10.0;%PATH%这行命令把SWIG的目录追加到现有Path最前面让命令行在搜索可执行文件时优先找到swig.exe。这里有一个很容易忽略的细节set PATH只对当前cmd窗口有效如果你嫌弃这个临时方案想一劳永逸就去“系统属性-高级-环境变量”在系统变量里编辑Path把C:\swigwin-2.10.0追加进去。改完后必须新开一个cmd窗口否则旧窗口读到的还是改动前的Path。加入Path后重新执行nmake /f makefile.vc python。这条命令会先清理没用的setup.ini再调用swig.exe生成gdalconst_wrap.c等一堆C源码最后调用VC编译器把它们编译成Python扩展的中间产物。看到控制台滚动输出“正在编译...”之类的信息就说明过了这一关。3.3 编译Python绑定nmake执行完毕后进入python子目录cd python此时目录下已经生成了setup.py这是给Python的distutils用的构建脚本。接下来执行python setup.py build这条命令读取setup.py找到依赖的gdal头文件和库文件把C扩展编译为.pyd文件。如果前面nmake步骤只生成了一半这里会报缺少某个.h或.lib需要回到swig目录重新nmake确认没有fatal error再回来。这里提个醒build过程中出现一排一排的warning是正常现象老GDAL代码配合新一点编译器各种deprecated警告见怪不怪。只要没有“error”字样就不要停下来折腾。过分关注警告反而浪费时间。3.4 解决Vcvarsall.bat找不到问题执行python setup.py build的另一个高频错误是unable to find Vcvarsall.bat这个坑的本质是版本错位。Python 2.7的distutils默认认为你是用VS2008VC9编译的Python所以它去检查环境变量VS90COMNTOOLS找VS2008的目录并读取vcvarsall.bat。而你的机器上装的是VS2010环境变量叫VS100COMNTOOLSVS90COMNTOOLS根本不存在。在同一个cmd窗口执行一行赋值set VS90COMNTOOLS%VS100COMNTOOLS%意思就是把VS2010的Tools目录路径借给VS90COMNTOOLS变量让distutils认为VS2008就装在同一位置。然后再跑build和installpython setup.py build python setup.py installinstall会把生成的osgeo文件夹和gdal.py复制到Python 2.7的site-packages目录同时把gdal-data所需的可选文件也一并处理。这一步之后理论上Python侧已经有GDAL模块了。3.5 DLL导出目录要进Path走到这里别急着庆祝打开Python尝试导入你会见到第二个大坑ImportError: DLL load failed: 找不到指定的模块原因不是Python模块没装好而是Python进程在导入osgeo._gdal时找不到依赖的gdal192.dll。GDAL编译时把生成的DLL放在bin目录而Python的site-packages里只有Python包装文件没有把DLL复制过去运行时只能靠系统的Path去搜索。解决办法是把包含gdal192.dll的bin目录加入Pathset PATHC:\OGC\GDAL192\bin;%PATH%更稳妥的说法是回到GDAL源码根目录找到实际输出的bin目录可能是Build\bin或gdal-1.9.2\bin以你机器上gdal192.dll实际所在位置为准把那个路径塞进Path。设置完后重新打开一个cmd窗口再执行python就能正常import了。这条配置不只对源码编译方案有效官方MSI方案安装完同样要面对它。所以我把DLL加载问题的排查单独放到了避坑章但这里先记住结论bin目录进PathGDAL才能被Python找到。4. MSI安装不编译也能跑最简单的方案源码编译适合想看原理、或者必须自定义编译选项的人。如果只是为了在Python 2.7里能读写栅格影像直接下载官方MSI安装包双击一路Next安装完配置好Path就好了。省下的时间拿来读几份报错排查文档比什么都值。4.1 找对版本GDAL MSI与Python 2.7位数一致MSI安装包是预编译好的二进制官方为不同Python版本和不同系统架构分别提供安装包。这里最关键的检查点就是Python位数。Win7 64位系统只是操作系统位数不代表Python一定是64位。如果Python装在“C:\Program Files (x86)\Python27”那明显是32位Python就必须选择32位x86的GDAL MSI。在下载和安装前用命令确认一下python -c import platform; print(platform.architecture()[0])输出“32bit”就选32位包输出“64bit”就选64位包。位数不匹配的症状和DLL缺失一模一样都是DLL load failed容易让人误判成Path配置问题白折腾很久。另外注意MSI文件名里一般会带完整版本号还要看它是否声明支持Python 2.7。老项目使用GDAL 1.9.2或1.11.0系列时这类包装兼容性做得好和那些需要自行编译的版本不同下载时优先选带exe或msi的官方渠道。4.2 安装MSI并记录安装目录双击MSI安装向导会要求选择组件和安装路径。默认路径往往是“C:\Program Files\GDAL192”带空格。前面提过带空格路径在命令行工具里容易出问题所以我会在向导里把安装位置改到纯英文目录例如C:\GDAL192安装过程很快它会自动布置好bin、lib、data和Python扩展目录。其中bin目录放着gdal192.dll、gdalinfo.exe等可执行文件Python扩展则直接安装到当前Python的site-packages里不需要再执行python setup.py install。这一步要注意MSI方案不需要VS2010也不需要SWIG如果之前因为源码编译装了一大堆东西也完全不影响MSI的使用两者可以共存只要环境变量Path里先后顺序别乱了就行。4.3 配置环境变量bin目录必须进PathMSI安装完成后直接打开Python执行python -c from osgeo import gdal不出意外还是会报DLL load failed。原因和源码编译方案完全相同Python加载GDAL模块时依赖的gdal192.dll在bin目录而这个目录默认不在Path里。官方安装包装到了位但没帮你把DLL搜索路径配好。配置Path的方式有两种。临时生效set PATHC:\GDAL192\bin;%PATH%这种只对当前cmd窗口有效适合顺手验证。长期生效则打开“系统属性-高级-环境变量”在系统变量的Path里新建填入C:\GDAL192\bin确定保存。注意修改系统Path后正在运行的所有cmd窗口都还保留旧环境必须新开一个cmd窗口再启动Python否则你连报错都已经看不到了。4.4 两种方案对比我装过几次GDAL把两条路线的差异整理成了一张表对比项源码编译方案MSI安装方案是否需要VS2010需要不需要是否需要SWIG需要自行安装不需要DLL位置编译输出bin目录安装目录binPython绑定安装方式setup.py installMSI自动安装排错难度较高较低适合场景需要自定义编译选项、想理解GDAL内部结构快速跑通、生产环境最小化安装结论很直接如果不是被编译选项卡住直接用MSI。两种方案都能成功和我的经验一致。我个人的习惯是先用MSI跑通业务真遇到需要裁剪功能时再回头编译核心库效率最高。5. 避坑从报错现象到解决方案的三次排查编译和安装过程中实际的报错其实就那么几个。把它们记住下次在任何Win7 64位机器上给Python 2.7配GDAL都能在几分钟内定位。下面按“现象-原因-解决”的顺序写我的排查记录。5.1 swig.exe不是内部或外部命令现象在swig目录里执行nmake /f makefile.vc python命令窗口返回“swig.exe 不是内部或外部命令也不是可运行的程序或批处理文件”随后NMAKE报告致命错误U1077退出码0x1。原因没有安装SWIG或SWIG解压了但没有把swig.exe所在目录加入Path命令行在系统搜索路径里找不到这个可执行文件。这是Windows上最普通的命令查找机制问题和GDAL本身的代码无关。解决下载swigwin-2.10.0解压为C:\swigwin-2.10.0确认目录下存在swig.exe然后执行set PATHC:\swigwin-2.10.0;%PATH%再重新执行nmake命令。如果是直接在新开cmd里操作或者已在系统变量中加入该路径不需要重复set。注意set PATH是临时增加目录如果之前的cmd窗口是在set之前启动的必须重新打开。5.2 unable to find Vcvarsall.bat现象执行python setup.py builddistutils报unable to find Vcvarsall.bat构建中止。原因Python 2.7在Windows上是用VS2008编译的setup.py里默认通过VS90COMNTOOLS这个环境变量去找VS2008的安装路径进而调用vcvarsall.bat初始化编译环境。机器上装的是VS2010对应的环境变量是VS100COMNTOOLS名称对不上distutils当然找不到该找的文件。解决在当前cmd窗口执行set VS90COMNTOOLS%VS100COMNTOOLS%把VS2010的工具目录路径临时赋予VS90COMNTOOLS让distutils在VS2008的名字下读到VS2010的路径。之后再执行python setup.py build。如果每次新开cmd都想要这行配置就把它加到系统环境变量里手动新建一个VS90COMNTOOLS值填写VS100COMNTOOLS完整路径。网上也有人推荐改用mingw绕过VC编译我在这个场景下试过失败率太高不推荐老老实实借环境变量最稳。5.3 ImportError: DLL load failed现象所有编译和安装步骤都成功但在Python里执行import gdal或from osgeo import gdal报“ImportError: DLL load failed: 找不到指定的模块”。错误信息可能指向osgeo/init.py里的swig_import_helper函数imp.load_module加载_gdal模块时最后失败。原因Python的扩展模块osgeo._gdal只是一个包装壳它真正依赖的gdal192.dll位于bin目录。如果bin目录不在Path里操作系统的DLL搜索机制找不到这个动态库于是抛出“找不到指定的模块”。很多人在这一步误以为是Python模块装错把site-packages翻个底朝天也解决不了问题。解决确认gdal192.dll的实际位置把该目录加入Path。我用的是MSI安装时指定的目录set PATHC:\GDAL192\bin;%PATH%源码编译方案则检查源码输出目录。加完Path后一定要新开一个cmd窗口再启动Python因为当前进程的环境变量不会自动刷新。重新执行import命令顺利通过就说明问题就在这。这是整套安装里最容易翻车、也最容易修好的一环。5.4 位数不匹配的坑现象按照上面所有方法设置好Path重新开窗口import gdal仍然报DLL load failed或者偶尔出现“不是有效的Win32应用程序”之类的加载错误。原因GDAL的位数与Python的位数不一致。Win7 64位系统上常见组合是32位Python和64位GDAL两边各自声称“已安装”但实际上互不认识。Python是32位进程加载64位DLL时直接失败并且错误信息很可能还是“找不到指定的模块”极具迷惑性。解决先查位数再选对应安装包。检查命令python -c import platform; print(platform.architecture())如果输出32bit就卸载当前GDAL重新安装x86版本的MSI如果输出64bit则安装64位版本。位数统一之后再做一遍5.3的Path检查。5.5 import gdal其实是一个过渡写法现象使用import gdal可以成功导入但调用某些属性时弹出DeprecationWarning或者在较新GDAL版本里直接报错。原因早期GDAL在Python里提供了gdal.py作为顶层兼容接口它内部会转向osgeo.gdal。随着版本演进官方推荐一律使用osgeo命名空间。老教程里的import gdal是那个年代的常见写法但新项目照抄会踩到弃用警告的雷。解决代码里统一写from osgeo import gdal如果需要显式注册驱动在GDAL 1.x常执行gdal.AllRegister()新版默认自动注册但显式调用也不会有副作用。看到网上老教程里写import gdal时替换成from osgeo import gdal再试试。6. 装完怎么验证最小栅格读出测试配置完成不等于能用验证的目标是让Python真正打开一个栅格文件并把元数据读出来。从那以后我每次给老机器配GDAL都会用同一套步骤走一遍五分钟内可以确认环境是否可靠。先验证环境变量和DLL的加载是否正常echo %PATH%检查输出里是否有GDAL bin目录。然后执行python -c from osgeo import gdal; print(gdal.VersionInfo())如果输出版本号例如192说明DLL加载成功GDAL核心库和Python模块已经接上了。如果这一步报ImportError回到避坑章重新排查Path和位数。找一个现成的tif文件用Python脚本读它的基本信息# -*- coding: utf-8 -*- from osgeo import gdal gdal.AllRegister() ds gdal.Open(rC:\OGC\test.tif) if ds is None: print(打开失败文件不存在或驱动不支持) else: print(影像宽: %d, 高: %d, 波段数: %d % ( ds.RasterXSize, ds.RasterYSize, ds.RasterCount)) band ds.GetRasterBand(1) print(波段1类型: %s % gdal.GetDataTypeName(band.DataType)) ds None这段脚本里的gdal.Open是核心调用任何GDAL版本都支持AllRegister在GDAL 1.x里负责注册所有驱动早期版本不执行的话可能打开某些格式失败。脚本执行成功并打印出宽高和波段数说明栅格读写链路跑通。这里注意脚本最后把ds设为None是主动关闭数据源防止文件句柄一直不释放。再确认模块到底装在哪里方便日后卸载或排查python -c import osgeo; print(osgeo.__file__)路径会指向类似Python27\Lib\site-packages\osgeo_init_.py的文件看到这个路径说明绑定确实被安装到了当前Python环境而不是别的地方。如果先后装过源码方案和MSI方案这个路径能帮你确认到底哪一层在生效。最后一步我用一个很小的技巧把验证脚本保存为check_gdal.py以后换机器或重装环境时直接运行一遍。从那以后每次给老机器配GDAL我都强制自己走完“echo PATH检查、VersionInfo打印、小影像读取”这三件事没有一次被隐藏问题坑过。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
