简介面向GIS开发、遥感影像处理和空间分析的开发者或研究者这套预编译好的GDAL 1.11库包省去了源码编译与依赖配置步骤解压后即可接入自己的项目快速获得栅格与矢量数据的读写处理能力。包体共241个文件压缩后约3.46MB类型涵盖C/C头文件、动态链接库、命令行可执行程序、数据定义表格与HTML文档lib供程序链接include暴露API声明bin附带GDAL/OGR命令行工具data存放坐标参考、投影参数及格式映射表html为离线参考手册。目前已有297人学习下载。以此为基础可以处理Shapefile、GeoTIFF、GeoJSON等常见格式执行裁剪、重投影、格式转换和矢量叠加等任务不仅适合正在学习GDAL接口的初学者对照目录结构理解库的组成也适合需要直接集成地理空间能力的项目开发者作为轻量级基础组件来使用大幅降低环境搭建成本。1. 已编译的 GDAL gdal111Windows 上最省心的栅格处理起步方式做遥感影像处理的人都知道Windows 上最难的第一步往往不是算法而是把 GDAL 跑起来。从源码编译得先喂齐 proj、geos、libtiff、sqlite3 这一串依赖库工具链版本稍有不匹配就是整晚的链接报错。已编译的 GDAL gdal111 恰恰绕开了这个泥潭GDAL 1.11 被维护者用特定编译器打包成现成的 dll、exe 和头文件你下载解压、配好环境变量就能直接开工。它适合三类人还在维护基于 1.x API 的老 C 工程的团队想在 Windows 本机快速做格式转换而不想碰 Linux 的影像从业者以及需要 SDK 做二次开发但不想承担源码编译成本的开发者。gdal111 确实不算新版本但对应老的工程资产它反而是最稳、最没有迁移风险的选项。这篇笔记从版本选型讲到下载部署再到命令行跑通和踩坑排查最后落到 C 与 Python 接入按着走基本一小时内能用起来。2. gdal111 的版本定位与选型为什么 1.11 还有人用怎么挑编译包2.1 gdal111 与 GDAL 2.x/3.x 的本质差异GDAL 1.11 是 1.x 系列的收尾版本。2013 年底发布 1.11.02016 年 11 月发布 1.11.5 之后主线就进入了 2.0 周期。在 API 层面1.11 还是经典的 GDALDataset / GDALRasterBand 架构栅格读取、格式驱动、坐标系统处理用的都是老一套 C 接口这恰恰是很多存量工程的编译基线。2.0 以后官方引入了不少接口调整老代码拿到 2.x 头文件下编译往往要改几十行GDAL 3.x 更是把 C API 和 PROJ 版本整体翻新。所以一个标注 gdal111 的预编译包本质上等于给你保存了一份“当时那个稳定 ABI”。从二进制看Windows 的 DLL 命名直接体现版本解压 gdal111 包bin 目录里的主库是 gdal111.dll配套的导入库是对应的 gdal_i.lib。老 C 项目只要拿到这套头文件和导入库编译链接基本能走通因为 1.x 的 C APIGDALAllRegister、GDALOpen、GDALClose 这一组在 1.11 各小版本间保持兼容。这一点比你自己去下载最新源码再来适配老工程要稳得多。我在维护项目时遇到过不止一次把老工程换成 GDAL 2.3 后原来能正常读写的 HFA 文件在细节上行为变了下游数值对不上排查起来非常被动。这就是版本资产带来的隐性成本。驱动覆盖上1.11 对传统栅格格式相当成熟。GeoTIFF、HFA.img、ENVI、VRT、NetCDF、HDF4/5取决于编译选项都是日常主力矢量侧有 ESRI Shapefile、GeoJSON、SQLite 等。它的缺口也很明确没有 GPKG 原生写入GPKG 驱动到 2.x 才完善、COG 优化读写缺失、WKT2 支持有限。如果你的输入输出集中在经典格式gdal111 完全罩得住如果新项目要接 GPKG、COG 这些就别选它直接上 GDAL 3.x 预编译包更合理。2.2 自编译的时间账为什么预编译包是务实选择Linux 下装 GDAL 几乎一条命令搞定Windows 压根不是一个生态。自编译 GDAL 1.11 要过的第一关是依赖集合PROJ那时还叫 PROJ4、GEOS、libtiff、libjpeg、libpng、libgeotiff、sqlite3、curl、expat、xerces-c 等。每个库都有兼容区间比如 libtiff 版本太新GDAL 1.11 的代码可能没适配官方发布页对每个版本给出明确依赖清单但在 Windows 上把一个一个源码包交给 CMake 编再用 MSVC 链接中途踩到“某个 lib 是 VS2013 编的我的工程是 VS2015”轻则警告重则 LNK2038 编译错误这种问题没有谁能一次避开里面玄学很多。我算过一笔时间账熟悉流程的工程师在 Windows 下从源码搭一套带常用格式TIFF/JPEG/PNG/GeoJSON/SQLite的 GDAL 1.11少说也要半天而且这半天只是“编出来”还没算调试数据路径的额外时间。预编译包把这半天直接省掉像 GIS Internals 这类专门维护预编译 GDAL 下载的站点会按小版本、VC 版本、位数拆分让你找到和老工程完全一致的组合。至于自己编译的实际收益除非你要改 GDAL 源码、打自定义补丁或者需要纯静态链接分发把 gdal111.dll 彻底编进 exe省去目标机器装运行时否则普通业务完全用不上。这里还要说一下“SDK 包”和“命令行包”的区别。命令行包只有 bin 和 data适合跑工具SDK 包额外带 include、lib、python 等目录适合做二次开发。下载时如果你打算写 C 或 Python 程序务必选带 SDK 的不然回头还要再下一次纯属浪费。2.3 预编译包的关键区段VC 版本、位数与驱动覆盖已编译的 GDAL gdal111 不是只有一种形态。同一份 1.11.5 源码配合不同编译器编出来就分成 VC9、VC10、VC11、VC12、VC14 等若干档。VC 编号对应 VS 版本VC9 是 VS2008VC10 是 VS2010VC11 是 VS2012VC12 是 VS2013VC14 是 VS2015 及后续兼容的 VC 运行时。选错编译器关联的包最典型的故障是运行时报“找不到 msvcp120.dll”或“找不到 vcruntime140.dll”。msvcp120 对应 VS2013 的运行时vcruntime140 对应 VS2015 之后二者不通用。下载前先看你机器装了哪个 Redistributable或者老工程当初用哪个 VS 编译两者匹配最稳。位数也要盯紧。x86 包编出来是 32 位 dllx64 包是 64 位 dll。如果你用 64 位 Python却把 32 位预编译包的 bin 放进 PATHimport osgeo 会加载失败反过来老 GIS 组件不少是 32 位进程里面再加载 32 位 gdal111.dll 就合适。经验是下载前先确认调用方的位数不要默认选 x64看机型定架构是常见的翻车原因。最后是驱动集合。预编译包的“核心驱动”和“全驱动”差别很大核心包只覆盖常见开源格式全驱动包会带 MrSID、ECW、JP2 商业扩展等闭源驱动。GIS Internals 把这些分开提供原因很简单闭源驱动涉及授权预编译者不能合在一个包里随意分发。要是你只做标准 GeoTIFF/JPEG/PNG 转换核心包足够一旦数据源里有 ECW 或 MrSID再去找对应扩展包。2.4 选型决策表我的建议组合使用场景推荐方案理由老 C 工程锁定 gdal111.dll选与项目 VS 匹配的 SDK 包头文件和导入库齐全API 对齐只跑命令行做格式转换核心包解压进 PATH占用小驱动够用数据源含 ECW/MrSID带扩展驱动的包注意授权核心包读不了闭源格式新项目、无历史包袱GDAL 3.x 预编译包1.11 的格式缺口在新场景会成问题Python 3.9 环境直接用 pip 轮子1.11 老绑定只覆盖旧 Python 版本这张表基本概括了我的选型逻辑先问自己有没有历史资产有就用 gdal111没有就直接拥抱新版本。很多团队从“所有机器统一装最新 GDAL”改回“每类工程锁一个版本”其实就是吃了兼容性教训后做的选择。预编译包在这里的作用不是提供新功能而是提供一个可复制的、稳定的运行时基线。3. 部署预编译 gdal111 到本机下载、配置与第一个影像命令3.1 下载前核对三件事VC 版本、CPU 位数、包类型GIS Internals 是业内常用的预编译 GDAL 下载站搜索 gdal111 一般就能直达它的 1.11 系列发布页。下载列表里条目很多GDAL 1.11.5、VS2013 x64、核心包或扩展包等。下手之前先把三个字段确定好。第一VC/Redistributable 版本。看你机器上已经装了哪个版本的 Visual C Redistributable在“控制面板 程序和功能”里能看到或者看你老工程当时用的 VS 年份。如果团队内部都是 VS2013 时代的库就选 VC12 对应的包避免运行时 DLL 对不上。第二CPU 位数。命令行工具本身无所谓但你要调用的 Python、要嵌入 gdal111 的 exe 是有位数的。确认方式很简单开一个命令行执行python -c import struct; print(struct.calcsize(P)*8)输出 64 就是 64 位 Python这个位数必须和下载的包一致。第三包类型。做二次开发选带 SDK 的版本多了 include、lib 目录只跑工具就选精简版即可。另外瞄一眼驱动集合页面描述里如果没有 “ECW”、“JPEG2000” 之类的关键词默认就是没有。3.2 解压部署与环境变量GDAL_DATA 不是可选项下载完成后解压到一个固定路径。我习惯用 C:\gdal111不放 Program Files 是为了避开权限问题也省得路径带空格引起的引号麻烦。解压后目录大致如下目录内容开发/运行时作用bingdal111.dll、gdalinfo.exe、gdal_translate.exe、gdalplugins/可执行文件和动态库必须进 PATHincludegdal.h、gdal_priv.h、ogr_api.h、cpl_port.hC/C 编译用头文件libgdal_i.lib 等导入库链接用datapcs.csv、gcs.csv、坐标系统定义等写 .prj 和做投影转换时读取python老版本 osgeo 绑定Python 调用时可加入路径部署时不是加个 PATH 就完事。GDAL_DATA 这个环境变量经常被忽略GDAL 在输出 .prj 文件、做投影转换时需要读取数据目录里的坐标系统定义。如果 GDAL_DATA 没设且不在默认位置常见症状是 gdal_translate 出来的结果没有 .prj或者某些投影转换直接报错。所以初始化脚本里最好把 PATH、GDAL_DATA、PROJ_LIB 一起设# 当前会话临时设置 $env:GDAL111_ROOT C:\gdal111 $env:PATH $env:GDAL111_ROOT\bin; $env:PATH $env:GDAL_DATA $env:GDAL111_ROOT\data $env:PROJ_LIB $env:GDAL111_ROOT\data这些变量的作用要分清PATH 是让系统找到 gdal111.dll 和 exeGDAL_DATA 告诉 GDAL 到哪读坐标系统数据文件PROJ_LIB 是给 PROJ 库用的1.11 系列对应的 PROJ 版本有些会读它设成同一个 data 目录不会出错。想全局生效就把它们写进“系统属性 环境变量”里想隔离多个版本就写一个 Set-Gdal111.ps1在需要时的终端里执行一下避免多版本 GDAL 打架。我后文会再提到这个脚本习惯。3.3 用 gdalinfo 验证版本、格式支持一次看清配置完先跑两个最基础的命令比任何自检脚本都直观gdalinfo --version gdalinfo --formats第一条会输出类似 “GDAL 1.11.5, released 2016/11/01” 的字符串确认你调用的确实是被 PATH 指向的那个 gdal111。第二条会打印所有已编译进该包的驱动格式数量通常有上百行。我主要看两个点前面是否有 GTiff、PNG、JPEG末尾有没有出现异常。如果有驱动 DLL 缺失某些格式会静默消失而不是报错所以只看到零星几个格式时多半是 bin\gdalplugins 下的驱动 DLL 被清理掉了而不是 GDAL 本身坏。这个验证步骤相当于给环境做一次体检。我的标准是gdalinfo --version 能输出、--formats 里包含 GTiff 和 JPEG、然后 gdal_translate 随便跑通一个小文件就认为部署合格。很多教程只让你看版本号其实格式列表更能反映这个预编译包是否完整这一步值得养成习惯。3.4 第一个转换命令gdal_translate 做金字塔友好的 TIF部署成功别急着处理大影像先拿一小块数据跑一次格式转换。常见做法是把一张大 TIF 压成 50% 尺寸、带 DEFLATE 压缩和 TILED 组织方式的缩略版gdal_translate -of GTiff -outsize 50% 50% -co COMPRESSDEFLATE -co TILEDYES C:\data\landsat_input.tif C:\data\landsat_half.tif参数逐一说清楚。-of GTiff指定输出格式写出来能避免依赖扩展名猜测-outsize 50% 50%分别控制输出影像的宽度和高度比例两个 50% 就是四分之一像素量-co是创建选项COMPRESSDEFLATE选的是无失真压缩算法对栅格数据压缩率通常不错TILEDYES让 TIFF 内部按瓦片块组织后续建金字塔、局部读取都会快很多。如果输入文件是 VRT这条命令同样能读因为 gdal_translate 对 GDAL 能打开的所有栅格格式都成立。跑完用 gdalinfo 检查输出gdalinfo C:\data\landsat_half.tif看到 Size 是输入的一半并且输出信息里出现 COMPRESSIONDEFLATE就证明这条链路没问题。此时环境变量、驱动注册、创建选项都已验证过后面写批处理脚本也更有底气。常见误用是把-outsize理解为面积缩放实际它是宽高各缩放 50%像素总量是原来的四分之一这点在估算输出大小时要算清楚不然磁盘空间容易预估偏差。4. 预编译 gdal111 常见问题排查五个高频翻车现场与解决路径4.1 现象命令一运行就报缺少 msvcp120.dll 或 vcruntime140.dll原因几乎都是预编译包的编译器运行时与系统没对上。VC9 包需要 VS2008 的 VC RedistributableVC12 包需要 VS2013 的VC14 包需要 VS2015 及之后兼容版运行时。64 位包配 32 位运行时一样救不回来位数必须一致。解决方法是到微软官网下载对应当年的 Visual C Redistributable 并安装装完重开终端。这里有个细微差别值得注意gdalinfo.exe 本身能跑起来不代表你的 C 工程也能链接这个包。exe 依赖的是 msvcp*.dll 和 vcruntime140.dll而你的工程如果是用另一套 VS 编译的链接 gdal_i.lib 时还可能出现运行时库冲突比如 “LNK2038: mismatch detected for _MSC_VER”。所以下载预编译包之前先定编译器版本比报错之后再去补运行时更省事。4.2 现象gdalinfo --version 有输出但打开特定文件报 Unable to open / No such file or directory文件确实存在却打不开原因通常有两个。一是文件名带中文或日文等非 ASCII 字符GDAL 1.11 在 Windows 上对 UTF-8 路径处理不完善内部用的是窄字符 API中文路径会找不到文件。解决方法是把文件放到纯英文目录下或者临时改成 ASCII 文件名处理完再改回来。二是驱动没注册比如你处理的是 JP2 文件但当前包没有带 JP2OpenJPEG 驱动GDAL 会直接报打不开。解决方法是先gdalinfo --formats看看驱动列表里有没有对应项没有就去换带该驱动的扩展包。这个现象还容易和权限问题混淆。如果文件放在 C:\Users\Administrator\Desktop 这种用户目录下且目录权限被收紧GDAL 可能连目录都枚举不到。我一般先把文件挪到 D:\tmp 这类简单的路径排除路径长度和权限影响再开始排查格式驱动问题。4.3 现象Python 里 import osgeo 失败或者 64 位程序加载 gdal111.dll 失败位数不一致是重灾区。你解压了 x86 的 gdal111却想在 64 位 Python 里用import 时 DLL 加载失败同时命令行 gdalinfo 因为是 32 位 exe却能正常跑。解决方法是确认 Python 位数下载对应位数的包。还有一个常被忽略的点Python 绑定版本。1.11 时代的绑定一般对应 Python 2.7 或 3.4 这类老版本如果你手头是 3.11osgeo 根本无法加载。所以对现代 Python直接用 pip install GDAL 拿官方轮子更现实只有你确实还在老 Python 环境里才值得用预编译包自带的那份 python 绑定。另一个藏在背后的原因是 PATH 里同时存在多个 GDAL。系统里装了 QGIS 或 OSGeo4W 时它自带一套新版本 GDAL 的 PATH 项。你在新终端里敲 gdalinfo 出来的是 gdal111但 osgeo 的 Python 绑定走的却是另一套 DLL两边的 GDAL_DATA 还不一样导致驱动列表和读写行为对不上。这种问题最难查因为它不报明显错误只是结果微妙地不对。我处理时会在 Python 里打印 gdal.file和 gdal.VersionInfo()先把实际加载路径确认了。4.4 现象C 项目链接成功但程序启动时报“找不到 gdal111.dll”这是典型的“编译期找得到运行期找不到”。VC 项目的运行库搜索顺序是 exe 所在目录、系统目录、PATH。编译时你正确指到了 include 和 gdal_i.lib但运行时 exe 旁边的 PATH 里没有 gdal111 的 bin 目录或者 gdal111.dll 没和 exe 放在一起。解决方法有两种把 bin 目录加进全局 PATH或者干脆在程序目录里放一份 gdal111.dll。如果程序里用了插件式驱动还要额外处理 GDAL_DRIVER_PATH。1.11 的驱动有些放在 bin\gdalplugins 下GDAL 自动注册驱动时会扫描该目录如果它在默认位置找不到某些格式会静默消失。你可以显式设置GDAL_DRIVER_PATHC:\gdal111\bin\gdalplugins把这一步写进应用启动逻辑里避免用户机器上 PATH 被其他软件抢先改掉。这个变量是很多人踩过坑之后才知道要配的属于典型的黑匣子问题。4.5 现象多版本 GDAL 混用转换结果时好时坏机器上同时装了 GDAL 2.x 的 Python 轮子和 gdal111 命令行PATH 里两个 bin 目录都在。你改了 A 包的配置命令行动态的却是 B 包的 DLL结果出现各种看似随机的问题某次转换写了 COG 选项但报错、某次投影似乎偏移、某次读取 GeoTIFF 时颜色解释丢失。这些不是 GDAL 本身不稳定而是多版本运行时互相覆盖。解决方法环境变量里只保留一个版本需要切换时用独立终端会话或者把每个版本的环境变量写成一个脚本使用前 source 对应文件。我习惯把 gdal111 的全部环境变量收敛到一个统一脚本里路径、GDAL_DATA、PROJ_LIB、GDAL_DRIVER_PATH 全都固定写死需要时在一个干净的终端里执行不用时就还原。批处理脚本如下# Use-Gdal111.ps1 $env:GDAL111_ROOT C:\gdal111 $env:PATH $env:GDAL111_ROOT\bin; $env:PATH $env:GDAL_DATA $env:GDAL111_ROOT\data $env:PROJ_LIB $env:GDAL111_ROOT\data $env:GDAL_DRIVER_PATH $env:GDAL111_ROOT\bin\gdalplugins这个做法的核心思路是让版本切换显式化不让系统偷偷决定用哪个 GDAL。多版本并存本身不是问题问题是隐式切换脚本化之后至少每次操作你心里清楚在调哪个版本。5. 把 gdal111 接进自己的程序C 链接与 Python 绑定的最小接法5.1 C 侧用 CMake 对预编译 SDK 做最小链接拿到 SDK 包的 include 和 lib 目录后CMake 里可以这样对接set(GDAL111_ROOT C:/gdal111 CACHE PATH gdal111 prebuilt root) add_executable(mytool main.cpp) target_include_directories(mytool PRIVATE ${GDAL111_ROOT}/include) target_link_libraries(mytool PRIVATE ${GDAL111_ROOT}/lib/gdal_i.lib)这段配置的逻辑include 目录提供 gdal.h 等头文件gdal_i.lib 是 1.11 预编译包里的导入库链接后运行时找的是 gdal111.dll。有一个细节容易被忽略不要同时链接 gdal.lib 和 gdal_i.lib两者指向的符号导出方式可能不一致链接器会挑其中一个后续行为不好预测。运行时把 bin 目录加进 PATH或者把 gdal111.dll 复制到 exe 旁边二选一。5.2 Python 侧老版本绑定的使用边界与轮子选择如果确实要在老 Python 里用这份绑定先把 osgeo 目录加进路径import sys sys.path.insert(0, rC:\gdal111\python\osgeo) from osgeo import gdal print(gdal.VersionInfo())这段代码的作用是让 Python 找到与 gdal111 配套的 osgeo 扩展。但 1.11 的绑定只能配合编译时的目标 Python 版本下载包里的 python 子目录通常会标注对应的 Python 版本先确认再动手。新版 Python 用户不要硬塞老绑定直接 install 官方维护的 GDAL 轮子底层是新的 3.x功能完整且没有运行时兼容问题。我在新环境里默认 pip 安装只有复现老项目时才切回 gdal111。这几年换过不少机器每次在新 Windows 上配环境第一件事就是把老项目的 gdal111 预编译包装好版本、位数、PATH 全部写进一个固定脚本。预编译包不是炫技它是把编译开销外包给维护者让你把时间花在真正要做的影像和地理处理上。这个习惯帮我省掉过很多次返工也希望以上的部署方法和避坑清单能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 12:06:40 · 阅读 1.2k 预编译 GDAL gdal111 在 Windows 上的部署、避坑与二次开发指南
简介面向GIS开发、遥感影像处理和空间分析的开发者或研究者这套预编译好的GDAL 1.11库包省去了源码编译与依赖配置步骤解压后即可接入自己的项目快速获得栅格与矢量数据的读写处理能力。包体共241个文件压缩后约3.46MB类型涵盖C/C头文件、动态链接库、命令行可执行程序、数据定义表格与HTML文档lib供程序链接include暴露API声明bin附带GDAL/OGR命令行工具data存放坐标参考、投影参数及格式映射表html为离线参考手册。目前已有297人学习下载。以此为基础可以处理Shapefile、GeoTIFF、GeoJSON等常见格式执行裁剪、重投影、格式转换和矢量叠加等任务不仅适合正在学习GDAL接口的初学者对照目录结构理解库的组成也适合需要直接集成地理空间能力的项目开发者作为轻量级基础组件来使用大幅降低环境搭建成本。1. 已编译的 GDAL gdal111Windows 上最省心的栅格处理起步方式做遥感影像处理的人都知道Windows 上最难的第一步往往不是算法而是把 GDAL 跑起来。从源码编译得先喂齐 proj、geos、libtiff、sqlite3 这一串依赖库工具链版本稍有不匹配就是整晚的链接报错。已编译的 GDAL gdal111 恰恰绕开了这个泥潭GDAL 1.11 被维护者用特定编译器打包成现成的 dll、exe 和头文件你下载解压、配好环境变量就能直接开工。它适合三类人还在维护基于 1.x API 的老 C 工程的团队想在 Windows 本机快速做格式转换而不想碰 Linux 的影像从业者以及需要 SDK 做二次开发但不想承担源码编译成本的开发者。gdal111 确实不算新版本但对应老的工程资产它反而是最稳、最没有迁移风险的选项。这篇笔记从版本选型讲到下载部署再到命令行跑通和踩坑排查最后落到 C 与 Python 接入按着走基本一小时内能用起来。2. gdal111 的版本定位与选型为什么 1.11 还有人用怎么挑编译包2.1 gdal111 与 GDAL 2.x/3.x 的本质差异GDAL 1.11 是 1.x 系列的收尾版本。2013 年底发布 1.11.02016 年 11 月发布 1.11.5 之后主线就进入了 2.0 周期。在 API 层面1.11 还是经典的 GDALDataset / GDALRasterBand 架构栅格读取、格式驱动、坐标系统处理用的都是老一套 C 接口这恰恰是很多存量工程的编译基线。2.0 以后官方引入了不少接口调整老代码拿到 2.x 头文件下编译往往要改几十行GDAL 3.x 更是把 C API 和 PROJ 版本整体翻新。所以一个标注 gdal111 的预编译包本质上等于给你保存了一份“当时那个稳定 ABI”。从二进制看Windows 的 DLL 命名直接体现版本解压 gdal111 包bin 目录里的主库是 gdal111.dll配套的导入库是对应的 gdal_i.lib。老 C 项目只要拿到这套头文件和导入库编译链接基本能走通因为 1.x 的 C APIGDALAllRegister、GDALOpen、GDALClose 这一组在 1.11 各小版本间保持兼容。这一点比你自己去下载最新源码再来适配老工程要稳得多。我在维护项目时遇到过不止一次把老工程换成 GDAL 2.3 后原来能正常读写的 HFA 文件在细节上行为变了下游数值对不上排查起来非常被动。这就是版本资产带来的隐性成本。驱动覆盖上1.11 对传统栅格格式相当成熟。GeoTIFF、HFA.img、ENVI、VRT、NetCDF、HDF4/5取决于编译选项都是日常主力矢量侧有 ESRI Shapefile、GeoJSON、SQLite 等。它的缺口也很明确没有 GPKG 原生写入GPKG 驱动到 2.x 才完善、COG 优化读写缺失、WKT2 支持有限。如果你的输入输出集中在经典格式gdal111 完全罩得住如果新项目要接 GPKG、COG 这些就别选它直接上 GDAL 3.x 预编译包更合理。2.2 自编译的时间账为什么预编译包是务实选择Linux 下装 GDAL 几乎一条命令搞定Windows 压根不是一个生态。自编译 GDAL 1.11 要过的第一关是依赖集合PROJ那时还叫 PROJ4、GEOS、libtiff、libjpeg、libpng、libgeotiff、sqlite3、curl、expat、xerces-c 等。每个库都有兼容区间比如 libtiff 版本太新GDAL 1.11 的代码可能没适配官方发布页对每个版本给出明确依赖清单但在 Windows 上把一个一个源码包交给 CMake 编再用 MSVC 链接中途踩到“某个 lib 是 VS2013 编的我的工程是 VS2015”轻则警告重则 LNK2038 编译错误这种问题没有谁能一次避开里面玄学很多。我算过一笔时间账熟悉流程的工程师在 Windows 下从源码搭一套带常用格式TIFF/JPEG/PNG/GeoJSON/SQLite的 GDAL 1.11少说也要半天而且这半天只是“编出来”还没算调试数据路径的额外时间。预编译包把这半天直接省掉像 GIS Internals 这类专门维护预编译 GDAL 下载的站点会按小版本、VC 版本、位数拆分让你找到和老工程完全一致的组合。至于自己编译的实际收益除非你要改 GDAL 源码、打自定义补丁或者需要纯静态链接分发把 gdal111.dll 彻底编进 exe省去目标机器装运行时否则普通业务完全用不上。这里还要说一下“SDK 包”和“命令行包”的区别。命令行包只有 bin 和 data适合跑工具SDK 包额外带 include、lib、python 等目录适合做二次开发。下载时如果你打算写 C 或 Python 程序务必选带 SDK 的不然回头还要再下一次纯属浪费。2.3 预编译包的关键区段VC 版本、位数与驱动覆盖已编译的 GDAL gdal111 不是只有一种形态。同一份 1.11.5 源码配合不同编译器编出来就分成 VC9、VC10、VC11、VC12、VC14 等若干档。VC 编号对应 VS 版本VC9 是 VS2008VC10 是 VS2010VC11 是 VS2012VC12 是 VS2013VC14 是 VS2015 及后续兼容的 VC 运行时。选错编译器关联的包最典型的故障是运行时报“找不到 msvcp120.dll”或“找不到 vcruntime140.dll”。msvcp120 对应 VS2013 的运行时vcruntime140 对应 VS2015 之后二者不通用。下载前先看你机器装了哪个 Redistributable或者老工程当初用哪个 VS 编译两者匹配最稳。位数也要盯紧。x86 包编出来是 32 位 dllx64 包是 64 位 dll。如果你用 64 位 Python却把 32 位预编译包的 bin 放进 PATHimport osgeo 会加载失败反过来老 GIS 组件不少是 32 位进程里面再加载 32 位 gdal111.dll 就合适。经验是下载前先确认调用方的位数不要默认选 x64看机型定架构是常见的翻车原因。最后是驱动集合。预编译包的“核心驱动”和“全驱动”差别很大核心包只覆盖常见开源格式全驱动包会带 MrSID、ECW、JP2 商业扩展等闭源驱动。GIS Internals 把这些分开提供原因很简单闭源驱动涉及授权预编译者不能合在一个包里随意分发。要是你只做标准 GeoTIFF/JPEG/PNG 转换核心包足够一旦数据源里有 ECW 或 MrSID再去找对应扩展包。2.4 选型决策表我的建议组合使用场景推荐方案理由老 C 工程锁定 gdal111.dll选与项目 VS 匹配的 SDK 包头文件和导入库齐全API 对齐只跑命令行做格式转换核心包解压进 PATH占用小驱动够用数据源含 ECW/MrSID带扩展驱动的包注意授权核心包读不了闭源格式新项目、无历史包袱GDAL 3.x 预编译包1.11 的格式缺口在新场景会成问题Python 3.9 环境直接用 pip 轮子1.11 老绑定只覆盖旧 Python 版本这张表基本概括了我的选型逻辑先问自己有没有历史资产有就用 gdal111没有就直接拥抱新版本。很多团队从“所有机器统一装最新 GDAL”改回“每类工程锁一个版本”其实就是吃了兼容性教训后做的选择。预编译包在这里的作用不是提供新功能而是提供一个可复制的、稳定的运行时基线。3. 部署预编译 gdal111 到本机下载、配置与第一个影像命令3.1 下载前核对三件事VC 版本、CPU 位数、包类型GIS Internals 是业内常用的预编译 GDAL 下载站搜索 gdal111 一般就能直达它的 1.11 系列发布页。下载列表里条目很多GDAL 1.11.5、VS2013 x64、核心包或扩展包等。下手之前先把三个字段确定好。第一VC/Redistributable 版本。看你机器上已经装了哪个版本的 Visual C Redistributable在“控制面板 程序和功能”里能看到或者看你老工程当时用的 VS 年份。如果团队内部都是 VS2013 时代的库就选 VC12 对应的包避免运行时 DLL 对不上。第二CPU 位数。命令行工具本身无所谓但你要调用的 Python、要嵌入 gdal111 的 exe 是有位数的。确认方式很简单开一个命令行执行python -c import struct; print(struct.calcsize(P)*8)输出 64 就是 64 位 Python这个位数必须和下载的包一致。第三包类型。做二次开发选带 SDK 的版本多了 include、lib 目录只跑工具就选精简版即可。另外瞄一眼驱动集合页面描述里如果没有 “ECW”、“JPEG2000” 之类的关键词默认就是没有。3.2 解压部署与环境变量GDAL_DATA 不是可选项下载完成后解压到一个固定路径。我习惯用 C:\gdal111不放 Program Files 是为了避开权限问题也省得路径带空格引起的引号麻烦。解压后目录大致如下目录内容开发/运行时作用bingdal111.dll、gdalinfo.exe、gdal_translate.exe、gdalplugins/可执行文件和动态库必须进 PATHincludegdal.h、gdal_priv.h、ogr_api.h、cpl_port.hC/C 编译用头文件libgdal_i.lib 等导入库链接用datapcs.csv、gcs.csv、坐标系统定义等写 .prj 和做投影转换时读取python老版本 osgeo 绑定Python 调用时可加入路径部署时不是加个 PATH 就完事。GDAL_DATA 这个环境变量经常被忽略GDAL 在输出 .prj 文件、做投影转换时需要读取数据目录里的坐标系统定义。如果 GDAL_DATA 没设且不在默认位置常见症状是 gdal_translate 出来的结果没有 .prj或者某些投影转换直接报错。所以初始化脚本里最好把 PATH、GDAL_DATA、PROJ_LIB 一起设# 当前会话临时设置 $env:GDAL111_ROOT C:\gdal111 $env:PATH $env:GDAL111_ROOT\bin; $env:PATH $env:GDAL_DATA $env:GDAL111_ROOT\data $env:PROJ_LIB $env:GDAL111_ROOT\data这些变量的作用要分清PATH 是让系统找到 gdal111.dll 和 exeGDAL_DATA 告诉 GDAL 到哪读坐标系统数据文件PROJ_LIB 是给 PROJ 库用的1.11 系列对应的 PROJ 版本有些会读它设成同一个 data 目录不会出错。想全局生效就把它们写进“系统属性 环境变量”里想隔离多个版本就写一个 Set-Gdal111.ps1在需要时的终端里执行一下避免多版本 GDAL 打架。我后文会再提到这个脚本习惯。3.3 用 gdalinfo 验证版本、格式支持一次看清配置完先跑两个最基础的命令比任何自检脚本都直观gdalinfo --version gdalinfo --formats第一条会输出类似 “GDAL 1.11.5, released 2016/11/01” 的字符串确认你调用的确实是被 PATH 指向的那个 gdal111。第二条会打印所有已编译进该包的驱动格式数量通常有上百行。我主要看两个点前面是否有 GTiff、PNG、JPEG末尾有没有出现异常。如果有驱动 DLL 缺失某些格式会静默消失而不是报错所以只看到零星几个格式时多半是 bin\gdalplugins 下的驱动 DLL 被清理掉了而不是 GDAL 本身坏。这个验证步骤相当于给环境做一次体检。我的标准是gdalinfo --version 能输出、--formats 里包含 GTiff 和 JPEG、然后 gdal_translate 随便跑通一个小文件就认为部署合格。很多教程只让你看版本号其实格式列表更能反映这个预编译包是否完整这一步值得养成习惯。3.4 第一个转换命令gdal_translate 做金字塔友好的 TIF部署成功别急着处理大影像先拿一小块数据跑一次格式转换。常见做法是把一张大 TIF 压成 50% 尺寸、带 DEFLATE 压缩和 TILED 组织方式的缩略版gdal_translate -of GTiff -outsize 50% 50% -co COMPRESSDEFLATE -co TILEDYES C:\data\landsat_input.tif C:\data\landsat_half.tif参数逐一说清楚。-of GTiff指定输出格式写出来能避免依赖扩展名猜测-outsize 50% 50%分别控制输出影像的宽度和高度比例两个 50% 就是四分之一像素量-co是创建选项COMPRESSDEFLATE选的是无失真压缩算法对栅格数据压缩率通常不错TILEDYES让 TIFF 内部按瓦片块组织后续建金字塔、局部读取都会快很多。如果输入文件是 VRT这条命令同样能读因为 gdal_translate 对 GDAL 能打开的所有栅格格式都成立。跑完用 gdalinfo 检查输出gdalinfo C:\data\landsat_half.tif看到 Size 是输入的一半并且输出信息里出现 COMPRESSIONDEFLATE就证明这条链路没问题。此时环境变量、驱动注册、创建选项都已验证过后面写批处理脚本也更有底气。常见误用是把-outsize理解为面积缩放实际它是宽高各缩放 50%像素总量是原来的四分之一这点在估算输出大小时要算清楚不然磁盘空间容易预估偏差。4. 预编译 gdal111 常见问题排查五个高频翻车现场与解决路径4.1 现象命令一运行就报缺少 msvcp120.dll 或 vcruntime140.dll原因几乎都是预编译包的编译器运行时与系统没对上。VC9 包需要 VS2008 的 VC RedistributableVC12 包需要 VS2013 的VC14 包需要 VS2015 及之后兼容版运行时。64 位包配 32 位运行时一样救不回来位数必须一致。解决方法是到微软官网下载对应当年的 Visual C Redistributable 并安装装完重开终端。这里有个细微差别值得注意gdalinfo.exe 本身能跑起来不代表你的 C 工程也能链接这个包。exe 依赖的是 msvcp*.dll 和 vcruntime140.dll而你的工程如果是用另一套 VS 编译的链接 gdal_i.lib 时还可能出现运行时库冲突比如 “LNK2038: mismatch detected for _MSC_VER”。所以下载预编译包之前先定编译器版本比报错之后再去补运行时更省事。4.2 现象gdalinfo --version 有输出但打开特定文件报 Unable to open / No such file or directory文件确实存在却打不开原因通常有两个。一是文件名带中文或日文等非 ASCII 字符GDAL 1.11 在 Windows 上对 UTF-8 路径处理不完善内部用的是窄字符 API中文路径会找不到文件。解决方法是把文件放到纯英文目录下或者临时改成 ASCII 文件名处理完再改回来。二是驱动没注册比如你处理的是 JP2 文件但当前包没有带 JP2OpenJPEG 驱动GDAL 会直接报打不开。解决方法是先gdalinfo --formats看看驱动列表里有没有对应项没有就去换带该驱动的扩展包。这个现象还容易和权限问题混淆。如果文件放在 C:\Users\Administrator\Desktop 这种用户目录下且目录权限被收紧GDAL 可能连目录都枚举不到。我一般先把文件挪到 D:\tmp 这类简单的路径排除路径长度和权限影响再开始排查格式驱动问题。4.3 现象Python 里 import osgeo 失败或者 64 位程序加载 gdal111.dll 失败位数不一致是重灾区。你解压了 x86 的 gdal111却想在 64 位 Python 里用import 时 DLL 加载失败同时命令行 gdalinfo 因为是 32 位 exe却能正常跑。解决方法是确认 Python 位数下载对应位数的包。还有一个常被忽略的点Python 绑定版本。1.11 时代的绑定一般对应 Python 2.7 或 3.4 这类老版本如果你手头是 3.11osgeo 根本无法加载。所以对现代 Python直接用 pip install GDAL 拿官方轮子更现实只有你确实还在老 Python 环境里才值得用预编译包自带的那份 python 绑定。另一个藏在背后的原因是 PATH 里同时存在多个 GDAL。系统里装了 QGIS 或 OSGeo4W 时它自带一套新版本 GDAL 的 PATH 项。你在新终端里敲 gdalinfo 出来的是 gdal111但 osgeo 的 Python 绑定走的却是另一套 DLL两边的 GDAL_DATA 还不一样导致驱动列表和读写行为对不上。这种问题最难查因为它不报明显错误只是结果微妙地不对。我处理时会在 Python 里打印 gdal.file和 gdal.VersionInfo()先把实际加载路径确认了。4.4 现象C 项目链接成功但程序启动时报“找不到 gdal111.dll”这是典型的“编译期找得到运行期找不到”。VC 项目的运行库搜索顺序是 exe 所在目录、系统目录、PATH。编译时你正确指到了 include 和 gdal_i.lib但运行时 exe 旁边的 PATH 里没有 gdal111 的 bin 目录或者 gdal111.dll 没和 exe 放在一起。解决方法有两种把 bin 目录加进全局 PATH或者干脆在程序目录里放一份 gdal111.dll。如果程序里用了插件式驱动还要额外处理 GDAL_DRIVER_PATH。1.11 的驱动有些放在 bin\gdalplugins 下GDAL 自动注册驱动时会扫描该目录如果它在默认位置找不到某些格式会静默消失。你可以显式设置GDAL_DRIVER_PATHC:\gdal111\bin\gdalplugins把这一步写进应用启动逻辑里避免用户机器上 PATH 被其他软件抢先改掉。这个变量是很多人踩过坑之后才知道要配的属于典型的黑匣子问题。4.5 现象多版本 GDAL 混用转换结果时好时坏机器上同时装了 GDAL 2.x 的 Python 轮子和 gdal111 命令行PATH 里两个 bin 目录都在。你改了 A 包的配置命令行动态的却是 B 包的 DLL结果出现各种看似随机的问题某次转换写了 COG 选项但报错、某次投影似乎偏移、某次读取 GeoTIFF 时颜色解释丢失。这些不是 GDAL 本身不稳定而是多版本运行时互相覆盖。解决方法环境变量里只保留一个版本需要切换时用独立终端会话或者把每个版本的环境变量写成一个脚本使用前 source 对应文件。我习惯把 gdal111 的全部环境变量收敛到一个统一脚本里路径、GDAL_DATA、PROJ_LIB、GDAL_DRIVER_PATH 全都固定写死需要时在一个干净的终端里执行不用时就还原。批处理脚本如下# Use-Gdal111.ps1 $env:GDAL111_ROOT C:\gdal111 $env:PATH $env:GDAL111_ROOT\bin; $env:PATH $env:GDAL_DATA $env:GDAL111_ROOT\data $env:PROJ_LIB $env:GDAL111_ROOT\data $env:GDAL_DRIVER_PATH $env:GDAL111_ROOT\bin\gdalplugins这个做法的核心思路是让版本切换显式化不让系统偷偷决定用哪个 GDAL。多版本并存本身不是问题问题是隐式切换脚本化之后至少每次操作你心里清楚在调哪个版本。5. 把 gdal111 接进自己的程序C 链接与 Python 绑定的最小接法5.1 C 侧用 CMake 对预编译 SDK 做最小链接拿到 SDK 包的 include 和 lib 目录后CMake 里可以这样对接set(GDAL111_ROOT C:/gdal111 CACHE PATH gdal111 prebuilt root) add_executable(mytool main.cpp) target_include_directories(mytool PRIVATE ${GDAL111_ROOT}/include) target_link_libraries(mytool PRIVATE ${GDAL111_ROOT}/lib/gdal_i.lib)这段配置的逻辑include 目录提供 gdal.h 等头文件gdal_i.lib 是 1.11 预编译包里的导入库链接后运行时找的是 gdal111.dll。有一个细节容易被忽略不要同时链接 gdal.lib 和 gdal_i.lib两者指向的符号导出方式可能不一致链接器会挑其中一个后续行为不好预测。运行时把 bin 目录加进 PATH或者把 gdal111.dll 复制到 exe 旁边二选一。5.2 Python 侧老版本绑定的使用边界与轮子选择如果确实要在老 Python 里用这份绑定先把 osgeo 目录加进路径import sys sys.path.insert(0, rC:\gdal111\python\osgeo) from osgeo import gdal print(gdal.VersionInfo())这段代码的作用是让 Python 找到与 gdal111 配套的 osgeo 扩展。但 1.11 的绑定只能配合编译时的目标 Python 版本下载包里的 python 子目录通常会标注对应的 Python 版本先确认再动手。新版 Python 用户不要硬塞老绑定直接 install 官方维护的 GDAL 轮子底层是新的 3.x功能完整且没有运行时兼容问题。我在新环境里默认 pip 安装只有复现老项目时才切回 gdal111。这几年换过不少机器每次在新 Windows 上配环境第一件事就是把老项目的 gdal111 预编译包装好版本、位数、PATH 全部写进一个固定脚本。预编译包不是炫技它是把编译开销外包给维护者让你把时间花在真正要做的影像和地理处理上。这个习惯帮我省掉过很多次返工也希望以上的部署方法和避坑清单能帮到你。本文还有配套的精品资源点击获取