简介Python 2.7在Win7 64位平台上安装GDAL常因Visual Studio版本、GEOS依赖及环境变量配置不当而频繁报错。这份实操经验文档面向需要在Python环境中调用GDAL的地理数据处理初学者完整记录了作者从编译core代码到安装官方msi的两种路径。文档基于GDAL 1.9.2实测系统梳理了安装环境准备、两种方案优劣对比、具体编译命令及排错过程尤其针对swig.exe未安装、Vcvarsall.bat缺失、DLL load failed等典型错误给出了可落地解决方案并强调将gdal安装目录下的bin加入环境变量这一关键操作。资源为单个docx文件压缩包约95KB内容按安装步骤和问题附录组织便于按需查阅。已有628人学习适合希望避开重复踩坑、快速完成同平台GDAL部署的开发者。1. GDAL 在 Python 2.7 与 Win7 64 位上的安装老环境里第一个绕不过去的坎很多人觉得 GDAL 安装是件小事直到他们接手一台仍跑着 Windows 7 64 位、只装了 Python 2.7 的生产机器。这个组合放在今天像古董但在测绘、遥感、国土行业的旧脚本里大量存在装 GDAL 是这类环境里第一个绕不过去的坎。它有两种装法要么下官方 MSI 点两下装完要么拉 GDAL core 源码用自带的 swig/python 自己编译。两条路我都完整走通过都不算难但各自的报错会让你感觉在跟黑匣子搏斗。这篇文章把两条路线、五个高频报错和装完后的验证方法写清楚适合正被 Python2.7 老环境折磨、又必须补上 GDAL 能力的人也适合第一次碰 GDAL 但手头只有旧机器的新手照着复现。2. 两条路线怎么选MSI 直装与源码编译的前置条件对比2.1 前置环境VS2010、GEOS 与 Python 2.7 各自扮演什么角色在双击任何安装包之前先把这台机器的底子摸清楚。我用的环境是 Win 7 64 位装了 Visual Studio 2010、GEOS 3.3.8、GDAL 1.9.2也试过 1.11.0和 Python 2.7。这套组合今天看着老但在很多单位的办公内网里仍然常见大量生产脚本还跑在 Python 2.7 上GDAL 是其中绕不开的依赖。Python 2.7 是目标运行时必须装建议装在默认的 C:\Program Files (x86)\Python27 下后面找 site-packages、调 PATH 都省事。Visual Studio 2010 只在走源码编译路线时需要GDAL 1.9.2 的 makefile.vc 是按 VC10 工具链写的机器里有 VC 编译器nmake 才能把 Python 绑定编出来。如果选 MSI 直装VS2010 可以不装这也是很多人选 MSI 的直接原因。GEOS 3.3.8 是 GDAL 的几何计算依赖负责多边形相交、缓冲区这类空间运算。Windows 上官方二进制包通常已经把 GEOS 静态编进去了走源码编译时才需要单独确认它的位置否则 configure 阶段会报找不到 GEOS。GDAL 版本上我试过 1.9.2 和 1.11.0两条路线都能走通最后留了 1.9.2。理由很朴素资料多网上提问帖几乎都拿这个版本做例子出问题好查。如果你手头项目不依赖新驱动或新格式老版本反而是最大的后悔药——稳定、文档全、踩坑记录一搜就有。1.11.0 我也验证过同样能装只是当时参考资料少遇到怪问题时排查慢不建议新手拿它起步。动手前先做三个确认每个都能省掉后面半小时的排错Python -c import platform; print(platform.architecture()[0])输出是 64bit说明当前解释器是 64 位下面所有步骤按 64 位方案走如果输出 32bit位数全变了别直接抄这篇的命令。第二个确认是 VS2010 的 x64 兼容工具命令提示符能正常打开这一步卡住说明 VS 安装时没勾上 x64 编译组件源码编译路线还没开始就结束了。第三个确认是 GDAL core 解压完整解压后目录下能看到 gcore、apps、swig 三个子目录缺一个都不行。2.2 MSI 与源码编译一张表看清两条路的差异两条路我都完整跑过一遍先上结论再讲操作。MSI 是典型的三分钟快装源码编译是折腾但能让你看清 GDAL 底层的路。这个选择直接影响你接下来一小时是喝茶还是修 bug所以先别急着下命令。对比项MSI 直装源码编译core swig/python时间成本约 35 分钟约 12 小时含排错前置要求只需 Python 2.7VS2010 GEOS Python 2.7对 GDAL 的控制官方编译选项不可改可改 makefile 和编译参数常见翻车点DLL 加载失败swig 缺失、Vcvarsall.bat 找不到、DLL 加载失败额外收获一个能用的包理解 gdal 的底层读取流程我的建议是如果只是要在 Python 里调用 GDAL 读栅格、做投影转换直接走 MSI省下的时间够你写一个影像批量处理的脚本。如果你想搞清 gdal 内部结构或者要改某个编译选项比如裁剪掉用不到的驱动来减小体积就走源码编译。原项目里我两个方案都实验了都能成功源码编译那次收获更大因为报错逼着我看了一遍 apps 目录下的 gdalinfo.cpp把 gdal 读取数据的流程从 open 到 read 完整摸了一遍。这里补一句选型边界MSI 路线要求官方恰好有匹配 Python 2.7 且 64 位的包。老版本 GDAL 的 msi 里 Python 绑定按主版本区分装的时候注意选对位数32 位包装进 64 位 Python后面 import 必炸。如果官方包与本地 Python 版本或系统位数不匹配源码编译就是唯一出路所以这条线无论如何都值得会。你要是手头是 Python 3.x 的机器就别走这套老流程了直接装新版 wheel 更省事。3. 源码编译路线core swig/python 从环境变量到 Python 包落地的完整步骤3.1 打开对的门以管理员身份启动 VS2010 x64 兼容工具命令提示符源码编译第一步不是解压是找到对的命令行环境。GDAL 的 makefile.vc 在编译时会调用 cl.exe、nmake.exe 这些工具它们不在普通 cmd 的 PATH 里必须通过 Visual Studio 自带的「命令提示符」进入。我踩过的坑是直接点开始菜单里的普通命令提示符结果连 nmake 都找不到报错内容是「不是内部或外部命令」。正确做法开始 所有程序 Microsoft Visual Studio 2010 Visual Tools Visual Studio X64 兼容工具命令提示符右键「以管理员身份运行」。为什么要 X64因为这是 64 位平台我们要编的是 64 位 Python 扩展用 x86 工具链编出来的 _gdal.pyd 载入 64 位 Python 会直接拒绝加载。管理员权限给后面文件写入少添麻烦尤其是解压目录在 C:\OGC\ 这种系统盘路径下普通权限可能写不进去。打开后先切到 GDAL core 解压目录的 swig 目录。以解压到 C:\OGC\GDAL192\gdal-1.9.2\ 为例cd C:\OGC\GDAL192\gdal-1.9.2\swig这个目录里躺着一堆 .i 文件它们是 SWIG 的接口定义文件作用是告诉 SWIG 怎么把 gdal 的 C 接口暴露成 Python 接口。切进来后可以先看一眼同级的 ..\gcore\gdal_version.h 在不在确认解压完整再往下走缺文件的话后面 nmake 会报一堆莫名其妙的 include 错误。3.2 第一道命令nmake /f makefile.vc python 与 swig.exe 报错现场环境就绪后在 swig 目录下执行编译 Python 绑定的第一道命令nmake /f makefile.vc python这条命令的逻辑分三步先删掉可能存在的 setup.ini 避免脏配置再把 GDAL_RELEASE_NAME 写进 setup.ini最后调用 swig.exe 把 gdal 接口文件转成 C 包装代码。后面两步都会往终端打日志看到 swig.exe 字样出现就说明走到关键步骤了。我第一次执行到这里直接报错swig.exe 不是内部或外部命令也不是可运行的程序或批处理文件。 NMAKE : fatal error U1077: swig.exe: 返回代码0x1 Stop.原因很直白机器上没装 swig.exe或者装了但没在 PATH 里。nmake 在命令行里找不到这个程序包装代码生成全部中断。这不是 GDAL 的问题是编译链少了一环。解决下载 SWIG 2.10.0当时适合 GDAL 1.9 系列的稳定版解压后把含 swig.exe 的目录加进系统环境变量 Path。我一般解压到 C:\swig\然后把 C:\swig; 追加到 Path 末尾。加完务必重开命令提示符窗口环境变量不会在已打开的窗口里实时生效。重开后回到 swig 目录再跑一次 nmake /f makefile.vc python这步顺利的话会自动生成 extensions/gdalconst_wrap.c 等文件。3.3 换目录再编setup.py build 前先做一次 VS90COMNTOOLS 映射swig 这步通过后需要进到 swig/python 子目录用 distutils 完成 Python 包构建cd C:\OGC\GDAL192\gdal-1.9.2\swig\python Python setup.py build Python setup.py install这是第二个高频报错的现场。Python 2.7 的 distutils 在定位编译器时习惯去找 VS2008 的环境变量 VS90COMNTOOLS而这台机器上只有 VS2010 的 VS100COMNTOOLS于是报unable to find Vcvarsall.bat网上有建议改用 mingw 编译的我实验后失败了不推荐继续试。真正省事的方案是在同一个命令行窗口里做一次环境变量映射set VS90COMNTOOLS%VS100COMNTOOLS%原理是 Python 2.7 的 distutils 按版本号硬编码去找 VS90COMNTOOLS对应 VC9也就是 VS2008而 GDAL 1.9.2 的 makefile 是按 VS2010 的 VC10 写的。把 VS100COMNTOOLS 的值赋给 VS90COMNTOOLSdistutils 就能找到 vcvarsall.bat进而完成 cl.exe 的路径配置。这是权宜之计但对这个场景就是最有效的解。设完变量后重新执行Python setup.py build Python setup.py install这个阶段会刷出大量编译输出里面 warning 远比 error 多终端滚动得飞快。判据只有一条看到 error 关键字才停下处理warning 一律忽略。build 会先把扩展模块编译到 build 目录install 再把 gdal.py、osgeo 包等文件复制到 Python2.7 的 site-packages 下。3.4 编译安装完成后缺的那条 PATHgdal192.dll 与 import gdal走到这里Python 包文件已经躺在 site-packages 里了但立刻 import gdal 十有八九会看到 ImportError: DLL load failed。这一步的原理和解决我在第 4 章和第 5 章展开先说结论把 GDAL core 安装目录下的 bin 目录加进 PATH让 Python 能在运行时定位 gdal192.dll。set PATHC:\Program Files\GDAL192\bin;%PATH%然后开一个全新窗口验证Python -c from osgeo import gdal; print(gdal.VersionInfo())如果打印出类似 1920 的版本号源码编译路线就真正走完了。这条线的价值不只是得到一个包nmake 和 setup.py 跑完后你至少亲眼看到了 SWIG 如何把 C 接口变成 Python 扩展的全过程后面接任何需要自编译的 Python 扩展都会心里有底。提示验证用的命令行窗口必须重开。set 和 setx 改的环境变量不会影响已打开的窗口这点最容易让人误判安装失败。4. MSI 直装路线官方包能省事但 DLL 加载失败躲不掉4.1 版本对口64 位 Python 2.7 该选哪个 GDAL 包如果你不想碰编译MSI 是唯一需要掌握的路线。它不需要 VS2010、不需要 SWIG、不需要看懂 makefile下载后一路 Next 就行。但省事的前提是版本对口这里有两个坑第一个是 Python 主版本要对GDAL 的 Python 绑定按 Python 2 / 3 区分必须选 2.7 对应的包第二个是系统位数要对这是一台 64 位机Python 也是 64 位就得选 64 位版本的 GDAL msi。选错位数的典型症状是安装过程一切正常import 时直接报 DLL load failed因为 32 位扩展根本进不了 64 位进程。安装时注意看 msi 的安装目录。GDAL 的 msi 默认装到 C:\Program Files\GDAL192 这类路径Python 绑定会一并放进 Python27\Lib\site-packages。如果你不想让 msi 动 Python 目录也可以手动把 osgeo 包复制过去但没必要保持默认最稳。装完顺手在开始菜单里找一下有没有 gdalinfo 快捷方式能找到说明 core 部分也注册好了。4.2 把 bin 目录塞进 Pathgdal192.dll 找不到模块的根因MSI 装完我第一件事就是开 Python 试 import gdal然后当场看到熟悉的错误ImportError: DLL load failed: 找不到指定的模块。这个错误在 MSI 路线上几乎必现因为它不是安装失败是运行时找不到依赖。原因要从 Windows 的 DLL 搜索顺序讲起。Python 的 osgeo 扩展模块 _gdal.pyd 在加载时依赖 gdal192.dllWindows 会先在本模块所在目录、系统目录里找找不到就沿着 PATH 环境变量搜索。gdal192.dll 位于 GDAL 安装目录的 bin 下这个目录默认不在 PATH 里于是加载失败。解决方法和源码编译路线的最后一步完全一样setx PATH %PATH%;C:\Program Files\GDAL192\binsetx 会把值永久写进用户级环境变量比 set 更持久。注意 setx 有长度限制约 1024 字符如果你系统 Path 已经很长建议在系统属性里手动编辑把 C:\Program Files\GDAL192\bin 追加进去。改完必须重开终端再验证Python -c from osgeo import gdal; print(gdal.__file__)能打印出 osgeo 包的路径说明 DLL 已经能被找到了。顺带提一个紧挨着的环境变量 GDAL_DATA。它指向 gdal-data 目录里面存着 epsg 数据库和坐标系描述文件。不设这个变量Open 简单栅格还能跑一旦涉及坐标转换或写入带投影的文件就会报找不到坐标系统的错。MSI 安装通常自带 gdal-data路径类似 C:\Program Files\GDAL192\gdal-data。建议一次把两个变量都配齐setx GDAL_DATA C:\Program Files\GDAL192\gdal-data这一小步就是整个 MSI 路线唯一的翻车点能踩到它说明你已经走到了最后离能用只差一条 PATH 和一个 GDAL_DATA。提示如果机器 Path 里已经堆了几十个路径别用 setx 拼字符串直接进系统属性手动画界面追加避免 setx 截断把原有变量搞坏。5. 安装避坑五个高频报错的现象、原因与解决一次完整安装下来我记录到的报错远远超过预期但翻来覆去就是这几个。每一条我都按「现象 → 原因 → 解决」写清楚照着排查能省下大半天。5.1 swig.exe 不是内部或外部命令现象在 swig 目录执行 nmake /f makefile.vc python终端提示 swig.exe 不是内部或外部命令nmake 以 U1077 错误中断。原因机器上没有安装 SWIG或安装了解压但没把 swig.exe 所在目录加进 PATH。nmake 是通过 PATH 查找可执行程序的找不到就只能中止。解决下载 SWIG 2.10.0解压到 C:\swig 后把 C:\swig 追加到系统环境变量 Path重开命令提示符再跑。判断是否生效可以先敲 swig -version 确认能打印版本。5.2 unable to find Vcvarsall.bat现象进入 swig/python 目录执行 Python setup.py build 时distutils 报 unable to find Vcvarsall.bat整个 build 流程直接结束。原因Python 2.7 是 VS2008 时代的产物distutils 编译扩展时硬编码去找 VS90COMNTOOLS 环境变量对应的 vcvarsall.bat机器上只有 VS2010提供的是 VS100COMNTOOLS对不上号。解决在当前命令行窗口执行 set VS90COMNTOOLS%VS100COMNTOOLS%让 Python 2.7 找到 vcvarsall.bat然后重新执行 build 和 install。不要改成系统级变量只在当前窗口设避免影响别的工程。5.3 ImportError: DLL load failed: 找不到指定的模块现象无论 MSI 还是源码编译路线安装步骤全部完成后import gdal 仍报 ImportError: DLL load failed: 找不到指定的模块traceback 里能定位到 osgeo 包加载 _gdal 扩展失败。原因_gdal.pyd 依赖 gdal192.dll但 gdal192.dll 所在的 bin 目录不在 PATH 里Windows 加载器搜不到这个动态库。注意这不是 Python 包的 site-packages 路径问题加 PYTHONPATH 没用。解决把 GDAL 安装目录的 bin 目录加进 PATH同时顺手把 GDAL_DATA 配好。改完后重开终端from osgeo import gdal 前先敲 gdal.VersionInfo() 验证。5.4 setup.py build 期间疯狂刷警告是失败了吗现象编译过程中终端快速滚动大量 warning比如 C4267 类型转换、C4996 函数弃用等新手容易以为编译失败直接 CtrlC 中断。原因GDAL 1.9.2 的 C 代码在 VC10 编译器下本来就会产生大量警告这是 MSVC 的严格检查在提醒潜在问题但多数是历史遗留不影响产物生成。解决判据只有一个——看到 error 再停。warning 刷屏时找个参照点swig/python 目录下持续生成 .c 和 .obj 文件build 目录在变大就是正常在编。等到最后出现 install 成功字样即可。5.5 import gdal 触发 deprecation_warn 或直接报错现象在老资料引导下用 import gdal 而不是 from osgeo import gdalPython 提示 deprecation_warn甚至在部分版本直接抛 traceback错误信息里指向 gdal.py 的 deprecation_warn 函数。原因GDAL 1.9 时代已经把命名空间从顶层 gdal 迁移到了 osgeo.gdalsite-packages 里的 gdal.py 只是一个兼容 shim负责调用 osgeo 并弹弃用警告。调用链绕了一层出错时定位也绕了一层。解决统一用 from osgeo import gdal 写代码。如果非要兼容新旧两套可以加 try/except 同时处理两条导入路径但新代码没必要这么干直接用 osgeo 全套就行。6. 装完别急着走用一条读取链路验证安装是否真的成功6.1 最小验证脚本打开一个栅格文件并打印元数据我习惯用一条最小读取链路验证整个安装不跑复杂的投影转换就打开一个 tif 把元数据和第一波段的数据读出来。这一步能同时验证 gdal 核心、DLL 加载、文件驱动注册三条链路。# -*- coding: utf-8 -*- from osgeo import gdal # 打开栅格第二个参数 0 表示只读 ds gdal.Open(E:/test/landsat8_sample.tif, 0) if ds is None: print(打开失败确认文件路径和驱动) else: print(尺寸: {} x {}.format(ds.RasterXSize, ds.RasterYSize)) print(波段数: {}.format(ds.RasterCount)) print(投影: {}.format(ds.GetProjection()[:80])) # 读取第一波段 band ds.GetRasterBand(1) print(数据类型: {}.format(gdal.GetDataTypeName(band.DataType))) print(最小值/最大值: {} / {}.format(band.ComputeRasterMinMax(False))) # 只读一块 10x10 的采样验证像元读取通路 block band.ReadAsArray(0, 0, 10, 10) print(左上角 10x10 统计: {}.format(block.mean())) ds None # 关闭数据集这里有三个关键参数值得说明gdal.Open 的第二个参数是访问模式0 表示只读、1 表示更新写GetRasterBand 的索引从 1 开始不是 0ReadAsArray 的前两个参数是行列起点后两个是读取窗口大小全部按像素坐标算。只要这份代码跑通说明 MSI 或源码编译的安装已经完全可用了。6.2 从 gdalinfo.cpp 看 GDAL 读取数据的主流程安装源码编译路线时我认真读了一遍 apps 目录下的 gdalinfo.cpp那是 GDAL 自带的图片信息工具源码代码量不大但把读取流程讲得很清楚。它的主线是先调用 GDALAllRegister 注册所有驱动再由 GDALOpen 打开目标文件驱动根据文件头的 magic 判断格式并把数据组织成数据集对象接着通过 GetRasterXSize、GetRasterBand 等接口取元数据和波段最后用 RasterIO 读像元。Python 绑定的接口几乎是一一对应的只是注册这步在 import gdal 时已经自动完成了。所以当你手头的栅格打开失败排错顺序就按这条链来先确认 import 能过再确认驱动注册Python 里不用手动调但可以用 gdal.GetDriverByName(GTiff) 检查再确认文件路径和访问权限最后才是文件本身损坏。从那以后我每次装完 GDAL 都强制走一遍 import gdal 加 ReadAsArray 的小脚本跑通了才敢把环境交付出去不再靠「安装过程没报错」来判断成功。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/23 17:23:27 · 阅读 1.2k GDAL在Python 2.7与Win7 64位上的安装：两条路线与五大报错排查
简介Python 2.7在Win7 64位平台上安装GDAL常因Visual Studio版本、GEOS依赖及环境变量配置不当而频繁报错。这份实操经验文档面向需要在Python环境中调用GDAL的地理数据处理初学者完整记录了作者从编译core代码到安装官方msi的两种路径。文档基于GDAL 1.9.2实测系统梳理了安装环境准备、两种方案优劣对比、具体编译命令及排错过程尤其针对swig.exe未安装、Vcvarsall.bat缺失、DLL load failed等典型错误给出了可落地解决方案并强调将gdal安装目录下的bin加入环境变量这一关键操作。资源为单个docx文件压缩包约95KB内容按安装步骤和问题附录组织便于按需查阅。已有628人学习适合希望避开重复踩坑、快速完成同平台GDAL部署的开发者。1. GDAL 在 Python 2.7 与 Win7 64 位上的安装老环境里第一个绕不过去的坎很多人觉得 GDAL 安装是件小事直到他们接手一台仍跑着 Windows 7 64 位、只装了 Python 2.7 的生产机器。这个组合放在今天像古董但在测绘、遥感、国土行业的旧脚本里大量存在装 GDAL 是这类环境里第一个绕不过去的坎。它有两种装法要么下官方 MSI 点两下装完要么拉 GDAL core 源码用自带的 swig/python 自己编译。两条路我都完整走通过都不算难但各自的报错会让你感觉在跟黑匣子搏斗。这篇文章把两条路线、五个高频报错和装完后的验证方法写清楚适合正被 Python2.7 老环境折磨、又必须补上 GDAL 能力的人也适合第一次碰 GDAL 但手头只有旧机器的新手照着复现。2. 两条路线怎么选MSI 直装与源码编译的前置条件对比2.1 前置环境VS2010、GEOS 与 Python 2.7 各自扮演什么角色在双击任何安装包之前先把这台机器的底子摸清楚。我用的环境是 Win 7 64 位装了 Visual Studio 2010、GEOS 3.3.8、GDAL 1.9.2也试过 1.11.0和 Python 2.7。这套组合今天看着老但在很多单位的办公内网里仍然常见大量生产脚本还跑在 Python 2.7 上GDAL 是其中绕不开的依赖。Python 2.7 是目标运行时必须装建议装在默认的 C:\Program Files (x86)\Python27 下后面找 site-packages、调 PATH 都省事。Visual Studio 2010 只在走源码编译路线时需要GDAL 1.9.2 的 makefile.vc 是按 VC10 工具链写的机器里有 VC 编译器nmake 才能把 Python 绑定编出来。如果选 MSI 直装VS2010 可以不装这也是很多人选 MSI 的直接原因。GEOS 3.3.8 是 GDAL 的几何计算依赖负责多边形相交、缓冲区这类空间运算。Windows 上官方二进制包通常已经把 GEOS 静态编进去了走源码编译时才需要单独确认它的位置否则 configure 阶段会报找不到 GEOS。GDAL 版本上我试过 1.9.2 和 1.11.0两条路线都能走通最后留了 1.9.2。理由很朴素资料多网上提问帖几乎都拿这个版本做例子出问题好查。如果你手头项目不依赖新驱动或新格式老版本反而是最大的后悔药——稳定、文档全、踩坑记录一搜就有。1.11.0 我也验证过同样能装只是当时参考资料少遇到怪问题时排查慢不建议新手拿它起步。动手前先做三个确认每个都能省掉后面半小时的排错Python -c import platform; print(platform.architecture()[0])输出是 64bit说明当前解释器是 64 位下面所有步骤按 64 位方案走如果输出 32bit位数全变了别直接抄这篇的命令。第二个确认是 VS2010 的 x64 兼容工具命令提示符能正常打开这一步卡住说明 VS 安装时没勾上 x64 编译组件源码编译路线还没开始就结束了。第三个确认是 GDAL core 解压完整解压后目录下能看到 gcore、apps、swig 三个子目录缺一个都不行。2.2 MSI 与源码编译一张表看清两条路的差异两条路我都完整跑过一遍先上结论再讲操作。MSI 是典型的三分钟快装源码编译是折腾但能让你看清 GDAL 底层的路。这个选择直接影响你接下来一小时是喝茶还是修 bug所以先别急着下命令。对比项MSI 直装源码编译core swig/python时间成本约 35 分钟约 12 小时含排错前置要求只需 Python 2.7VS2010 GEOS Python 2.7对 GDAL 的控制官方编译选项不可改可改 makefile 和编译参数常见翻车点DLL 加载失败swig 缺失、Vcvarsall.bat 找不到、DLL 加载失败额外收获一个能用的包理解 gdal 的底层读取流程我的建议是如果只是要在 Python 里调用 GDAL 读栅格、做投影转换直接走 MSI省下的时间够你写一个影像批量处理的脚本。如果你想搞清 gdal 内部结构或者要改某个编译选项比如裁剪掉用不到的驱动来减小体积就走源码编译。原项目里我两个方案都实验了都能成功源码编译那次收获更大因为报错逼着我看了一遍 apps 目录下的 gdalinfo.cpp把 gdal 读取数据的流程从 open 到 read 完整摸了一遍。这里补一句选型边界MSI 路线要求官方恰好有匹配 Python 2.7 且 64 位的包。老版本 GDAL 的 msi 里 Python 绑定按主版本区分装的时候注意选对位数32 位包装进 64 位 Python后面 import 必炸。如果官方包与本地 Python 版本或系统位数不匹配源码编译就是唯一出路所以这条线无论如何都值得会。你要是手头是 Python 3.x 的机器就别走这套老流程了直接装新版 wheel 更省事。3. 源码编译路线core swig/python 从环境变量到 Python 包落地的完整步骤3.1 打开对的门以管理员身份启动 VS2010 x64 兼容工具命令提示符源码编译第一步不是解压是找到对的命令行环境。GDAL 的 makefile.vc 在编译时会调用 cl.exe、nmake.exe 这些工具它们不在普通 cmd 的 PATH 里必须通过 Visual Studio 自带的「命令提示符」进入。我踩过的坑是直接点开始菜单里的普通命令提示符结果连 nmake 都找不到报错内容是「不是内部或外部命令」。正确做法开始 所有程序 Microsoft Visual Studio 2010 Visual Tools Visual Studio X64 兼容工具命令提示符右键「以管理员身份运行」。为什么要 X64因为这是 64 位平台我们要编的是 64 位 Python 扩展用 x86 工具链编出来的 _gdal.pyd 载入 64 位 Python 会直接拒绝加载。管理员权限给后面文件写入少添麻烦尤其是解压目录在 C:\OGC\ 这种系统盘路径下普通权限可能写不进去。打开后先切到 GDAL core 解压目录的 swig 目录。以解压到 C:\OGC\GDAL192\gdal-1.9.2\ 为例cd C:\OGC\GDAL192\gdal-1.9.2\swig这个目录里躺着一堆 .i 文件它们是 SWIG 的接口定义文件作用是告诉 SWIG 怎么把 gdal 的 C 接口暴露成 Python 接口。切进来后可以先看一眼同级的 ..\gcore\gdal_version.h 在不在确认解压完整再往下走缺文件的话后面 nmake 会报一堆莫名其妙的 include 错误。3.2 第一道命令nmake /f makefile.vc python 与 swig.exe 报错现场环境就绪后在 swig 目录下执行编译 Python 绑定的第一道命令nmake /f makefile.vc python这条命令的逻辑分三步先删掉可能存在的 setup.ini 避免脏配置再把 GDAL_RELEASE_NAME 写进 setup.ini最后调用 swig.exe 把 gdal 接口文件转成 C 包装代码。后面两步都会往终端打日志看到 swig.exe 字样出现就说明走到关键步骤了。我第一次执行到这里直接报错swig.exe 不是内部或外部命令也不是可运行的程序或批处理文件。 NMAKE : fatal error U1077: swig.exe: 返回代码0x1 Stop.原因很直白机器上没装 swig.exe或者装了但没在 PATH 里。nmake 在命令行里找不到这个程序包装代码生成全部中断。这不是 GDAL 的问题是编译链少了一环。解决下载 SWIG 2.10.0当时适合 GDAL 1.9 系列的稳定版解压后把含 swig.exe 的目录加进系统环境变量 Path。我一般解压到 C:\swig\然后把 C:\swig; 追加到 Path 末尾。加完务必重开命令提示符窗口环境变量不会在已打开的窗口里实时生效。重开后回到 swig 目录再跑一次 nmake /f makefile.vc python这步顺利的话会自动生成 extensions/gdalconst_wrap.c 等文件。3.3 换目录再编setup.py build 前先做一次 VS90COMNTOOLS 映射swig 这步通过后需要进到 swig/python 子目录用 distutils 完成 Python 包构建cd C:\OGC\GDAL192\gdal-1.9.2\swig\python Python setup.py build Python setup.py install这是第二个高频报错的现场。Python 2.7 的 distutils 在定位编译器时习惯去找 VS2008 的环境变量 VS90COMNTOOLS而这台机器上只有 VS2010 的 VS100COMNTOOLS于是报unable to find Vcvarsall.bat网上有建议改用 mingw 编译的我实验后失败了不推荐继续试。真正省事的方案是在同一个命令行窗口里做一次环境变量映射set VS90COMNTOOLS%VS100COMNTOOLS%原理是 Python 2.7 的 distutils 按版本号硬编码去找 VS90COMNTOOLS对应 VC9也就是 VS2008而 GDAL 1.9.2 的 makefile 是按 VS2010 的 VC10 写的。把 VS100COMNTOOLS 的值赋给 VS90COMNTOOLSdistutils 就能找到 vcvarsall.bat进而完成 cl.exe 的路径配置。这是权宜之计但对这个场景就是最有效的解。设完变量后重新执行Python setup.py build Python setup.py install这个阶段会刷出大量编译输出里面 warning 远比 error 多终端滚动得飞快。判据只有一条看到 error 关键字才停下处理warning 一律忽略。build 会先把扩展模块编译到 build 目录install 再把 gdal.py、osgeo 包等文件复制到 Python2.7 的 site-packages 下。3.4 编译安装完成后缺的那条 PATHgdal192.dll 与 import gdal走到这里Python 包文件已经躺在 site-packages 里了但立刻 import gdal 十有八九会看到 ImportError: DLL load failed。这一步的原理和解决我在第 4 章和第 5 章展开先说结论把 GDAL core 安装目录下的 bin 目录加进 PATH让 Python 能在运行时定位 gdal192.dll。set PATHC:\Program Files\GDAL192\bin;%PATH%然后开一个全新窗口验证Python -c from osgeo import gdal; print(gdal.VersionInfo())如果打印出类似 1920 的版本号源码编译路线就真正走完了。这条线的价值不只是得到一个包nmake 和 setup.py 跑完后你至少亲眼看到了 SWIG 如何把 C 接口变成 Python 扩展的全过程后面接任何需要自编译的 Python 扩展都会心里有底。提示验证用的命令行窗口必须重开。set 和 setx 改的环境变量不会影响已打开的窗口这点最容易让人误判安装失败。4. MSI 直装路线官方包能省事但 DLL 加载失败躲不掉4.1 版本对口64 位 Python 2.7 该选哪个 GDAL 包如果你不想碰编译MSI 是唯一需要掌握的路线。它不需要 VS2010、不需要 SWIG、不需要看懂 makefile下载后一路 Next 就行。但省事的前提是版本对口这里有两个坑第一个是 Python 主版本要对GDAL 的 Python 绑定按 Python 2 / 3 区分必须选 2.7 对应的包第二个是系统位数要对这是一台 64 位机Python 也是 64 位就得选 64 位版本的 GDAL msi。选错位数的典型症状是安装过程一切正常import 时直接报 DLL load failed因为 32 位扩展根本进不了 64 位进程。安装时注意看 msi 的安装目录。GDAL 的 msi 默认装到 C:\Program Files\GDAL192 这类路径Python 绑定会一并放进 Python27\Lib\site-packages。如果你不想让 msi 动 Python 目录也可以手动把 osgeo 包复制过去但没必要保持默认最稳。装完顺手在开始菜单里找一下有没有 gdalinfo 快捷方式能找到说明 core 部分也注册好了。4.2 把 bin 目录塞进 Pathgdal192.dll 找不到模块的根因MSI 装完我第一件事就是开 Python 试 import gdal然后当场看到熟悉的错误ImportError: DLL load failed: 找不到指定的模块。这个错误在 MSI 路线上几乎必现因为它不是安装失败是运行时找不到依赖。原因要从 Windows 的 DLL 搜索顺序讲起。Python 的 osgeo 扩展模块 _gdal.pyd 在加载时依赖 gdal192.dllWindows 会先在本模块所在目录、系统目录里找找不到就沿着 PATH 环境变量搜索。gdal192.dll 位于 GDAL 安装目录的 bin 下这个目录默认不在 PATH 里于是加载失败。解决方法和源码编译路线的最后一步完全一样setx PATH %PATH%;C:\Program Files\GDAL192\binsetx 会把值永久写进用户级环境变量比 set 更持久。注意 setx 有长度限制约 1024 字符如果你系统 Path 已经很长建议在系统属性里手动编辑把 C:\Program Files\GDAL192\bin 追加进去。改完必须重开终端再验证Python -c from osgeo import gdal; print(gdal.__file__)能打印出 osgeo 包的路径说明 DLL 已经能被找到了。顺带提一个紧挨着的环境变量 GDAL_DATA。它指向 gdal-data 目录里面存着 epsg 数据库和坐标系描述文件。不设这个变量Open 简单栅格还能跑一旦涉及坐标转换或写入带投影的文件就会报找不到坐标系统的错。MSI 安装通常自带 gdal-data路径类似 C:\Program Files\GDAL192\gdal-data。建议一次把两个变量都配齐setx GDAL_DATA C:\Program Files\GDAL192\gdal-data这一小步就是整个 MSI 路线唯一的翻车点能踩到它说明你已经走到了最后离能用只差一条 PATH 和一个 GDAL_DATA。提示如果机器 Path 里已经堆了几十个路径别用 setx 拼字符串直接进系统属性手动画界面追加避免 setx 截断把原有变量搞坏。5. 安装避坑五个高频报错的现象、原因与解决一次完整安装下来我记录到的报错远远超过预期但翻来覆去就是这几个。每一条我都按「现象 → 原因 → 解决」写清楚照着排查能省下大半天。5.1 swig.exe 不是内部或外部命令现象在 swig 目录执行 nmake /f makefile.vc python终端提示 swig.exe 不是内部或外部命令nmake 以 U1077 错误中断。原因机器上没有安装 SWIG或安装了解压但没把 swig.exe 所在目录加进 PATH。nmake 是通过 PATH 查找可执行程序的找不到就只能中止。解决下载 SWIG 2.10.0解压到 C:\swig 后把 C:\swig 追加到系统环境变量 Path重开命令提示符再跑。判断是否生效可以先敲 swig -version 确认能打印版本。5.2 unable to find Vcvarsall.bat现象进入 swig/python 目录执行 Python setup.py build 时distutils 报 unable to find Vcvarsall.bat整个 build 流程直接结束。原因Python 2.7 是 VS2008 时代的产物distutils 编译扩展时硬编码去找 VS90COMNTOOLS 环境变量对应的 vcvarsall.bat机器上只有 VS2010提供的是 VS100COMNTOOLS对不上号。解决在当前命令行窗口执行 set VS90COMNTOOLS%VS100COMNTOOLS%让 Python 2.7 找到 vcvarsall.bat然后重新执行 build 和 install。不要改成系统级变量只在当前窗口设避免影响别的工程。5.3 ImportError: DLL load failed: 找不到指定的模块现象无论 MSI 还是源码编译路线安装步骤全部完成后import gdal 仍报 ImportError: DLL load failed: 找不到指定的模块traceback 里能定位到 osgeo 包加载 _gdal 扩展失败。原因_gdal.pyd 依赖 gdal192.dll但 gdal192.dll 所在的 bin 目录不在 PATH 里Windows 加载器搜不到这个动态库。注意这不是 Python 包的 site-packages 路径问题加 PYTHONPATH 没用。解决把 GDAL 安装目录的 bin 目录加进 PATH同时顺手把 GDAL_DATA 配好。改完后重开终端from osgeo import gdal 前先敲 gdal.VersionInfo() 验证。5.4 setup.py build 期间疯狂刷警告是失败了吗现象编译过程中终端快速滚动大量 warning比如 C4267 类型转换、C4996 函数弃用等新手容易以为编译失败直接 CtrlC 中断。原因GDAL 1.9.2 的 C 代码在 VC10 编译器下本来就会产生大量警告这是 MSVC 的严格检查在提醒潜在问题但多数是历史遗留不影响产物生成。解决判据只有一个——看到 error 再停。warning 刷屏时找个参照点swig/python 目录下持续生成 .c 和 .obj 文件build 目录在变大就是正常在编。等到最后出现 install 成功字样即可。5.5 import gdal 触发 deprecation_warn 或直接报错现象在老资料引导下用 import gdal 而不是 from osgeo import gdalPython 提示 deprecation_warn甚至在部分版本直接抛 traceback错误信息里指向 gdal.py 的 deprecation_warn 函数。原因GDAL 1.9 时代已经把命名空间从顶层 gdal 迁移到了 osgeo.gdalsite-packages 里的 gdal.py 只是一个兼容 shim负责调用 osgeo 并弹弃用警告。调用链绕了一层出错时定位也绕了一层。解决统一用 from osgeo import gdal 写代码。如果非要兼容新旧两套可以加 try/except 同时处理两条导入路径但新代码没必要这么干直接用 osgeo 全套就行。6. 装完别急着走用一条读取链路验证安装是否真的成功6.1 最小验证脚本打开一个栅格文件并打印元数据我习惯用一条最小读取链路验证整个安装不跑复杂的投影转换就打开一个 tif 把元数据和第一波段的数据读出来。这一步能同时验证 gdal 核心、DLL 加载、文件驱动注册三条链路。# -*- coding: utf-8 -*- from osgeo import gdal # 打开栅格第二个参数 0 表示只读 ds gdal.Open(E:/test/landsat8_sample.tif, 0) if ds is None: print(打开失败确认文件路径和驱动) else: print(尺寸: {} x {}.format(ds.RasterXSize, ds.RasterYSize)) print(波段数: {}.format(ds.RasterCount)) print(投影: {}.format(ds.GetProjection()[:80])) # 读取第一波段 band ds.GetRasterBand(1) print(数据类型: {}.format(gdal.GetDataTypeName(band.DataType))) print(最小值/最大值: {} / {}.format(band.ComputeRasterMinMax(False))) # 只读一块 10x10 的采样验证像元读取通路 block band.ReadAsArray(0, 0, 10, 10) print(左上角 10x10 统计: {}.format(block.mean())) ds None # 关闭数据集这里有三个关键参数值得说明gdal.Open 的第二个参数是访问模式0 表示只读、1 表示更新写GetRasterBand 的索引从 1 开始不是 0ReadAsArray 的前两个参数是行列起点后两个是读取窗口大小全部按像素坐标算。只要这份代码跑通说明 MSI 或源码编译的安装已经完全可用了。6.2 从 gdalinfo.cpp 看 GDAL 读取数据的主流程安装源码编译路线时我认真读了一遍 apps 目录下的 gdalinfo.cpp那是 GDAL 自带的图片信息工具源码代码量不大但把读取流程讲得很清楚。它的主线是先调用 GDALAllRegister 注册所有驱动再由 GDALOpen 打开目标文件驱动根据文件头的 magic 判断格式并把数据组织成数据集对象接着通过 GetRasterXSize、GetRasterBand 等接口取元数据和波段最后用 RasterIO 读像元。Python 绑定的接口几乎是一一对应的只是注册这步在 import gdal 时已经自动完成了。所以当你手头的栅格打开失败排错顺序就按这条链来先确认 import 能过再确认驱动注册Python 里不用手动调但可以用 gdal.GetDriverByName(GTiff) 检查再确认文件路径和访问权限最后才是文件本身损坏。从那以后我每次装完 GDAL 都强制走一遍 import gdal 加 ReadAsArray 的小脚本跑通了才敢把环境交付出去不再靠「安装过程没报错」来判断成功。希望帮到你。本文还有配套的精品资源点击获取