简介这是GDAL 2.3.1的Windows 64位自编译版本面向需要读取、写入和转换栅格/矢量地理空间数据的地理信息开发者与遥感分析人员。压缩包共451个文件、约54.57MB包含147个.h头文件、56个.hpp、19个DLL、18个.lib库文件以及49个.exe命令行工具另有CMake配置、pdb调试符号和C示例程序可兼顾开发、调试与日常处理。由于是自行编译包内bin、include、lib等目录结构较为完整能避免从源码搭建GDAL的繁琐流程方便直接嵌入Visual Studio等Windows开发环境也便于定制编译选项。已有135人学习浏览适合具备C/C或CMake基础、需要在GIS项目中快速集成GDAL能力的中高级开发者使用。 搞GIS和遥感的人电脑里多半都躺着一个叫gdal-2.3.1-x64-windows.zip的压缩包。这个包就是老牌开源地理空间数据抽象库GDALGeospatial Data Abstraction Library在Windows x64平台上的预编译发行版当年几乎是Windows上做地理数据处理的标准配置。别小看这个zip它集合了栅格数据读写、矢量数据转换、坐标投影变换的一整套命令行工具和动态链接库从简单地看一眼影像信息到批量把Shapefile喂给数据库再到把一堆分幅TIFF合并成一个大文件都是它在背后干活。这篇文章就围绕这一版zip把我这些年反复解压、配置、使用它踩过的坑和沉淀下来的经验完整梳理一遍适合刚接触GDAL的新手也适合需要维护老项目、跟旧版本绑定的开发者和数据处理人员。1. gdal-2.3.1-x64-windows.zip到底是什么1.1 2.3.1这个版本号意味着什么GDAL的版本策略是大版本加小修订2.3.1属于2.3系列的第一个修订版发布时间在2018年年中。当时的2.3分支吸收了不少重要更新GTiff驱动在读写性能和稳定性上做了一轮优化GeoPackage的读写已经比较成熟很多企业级GIS组件也是从这时候开始把GDAL作为底层数据处理引擎来依赖。现在虽然GDAL已经走到了3.x甚至更高但Windows下的C二次开发场景里2.3.1的ABI二进制接口是大量商业组件验证过的因此很多老项目、老系统的依赖树依然把它锁死。我经常被问一个问题为什么不用新版本答案很简单很多时候不是不想用而是不能用。你手头的某套商业测绘SDK、某个GIS插件、甚至公司内部封装的影像服务中间层可能都只跟某个特定的DLL版本对接过。升级GDAL意味着所有依赖它的组件都要重新编译、回归测试对于生产环境来说成本太高。gdal-2.3.1-x64-windows.zip这种预编译包存在的意义就是让这类老环境能够快速部署、快速复现而不是让每个程序员都从源码折腾一遍。1.2 x64 Windows包里到底装了些什么这个zip解压后通常能看到bin、share、include、lib这几类目录不同渠道分发的包会有些差异比如有的分发版会拆出plugins目录。bin下面放的是核心可执行文件gdalinfo、ogr2ogr、gdal_translate、gdalwarp、gdalbuildvrt、gdaldem都在这里同时还有一大堆以gdal开头的DLL和它们依赖的第三方库比如gdal203.dll2.3系列对应的动态库命名、geos.dll、proj.dll、curl.dll、sqlite3.dll等等。share里的gdal目录存放的是坐标系统和投影参数定义文件像epsg、gcs.csv、projop_wparm这些。include和lib则是给C/C开发者准备的头文件和导入库都在里边想做原生扩展就靠它们。很多新手拿到包之后只盯着bin里的exe看其实整个GDAL的运转离不开share目录下的参数文件这点在后面配环境变量的时候尤其关键。所以这个zip并不只是几个命令行工具而是一个完整的运行时生态缺了任何一块表现出来的症状可能都让人摸不着头脑。2. 安装部署从解压到命令行全局可用2.1 解压与目录规划的一些建议先说解压。不建议直接把zip拖到C盘根目录就完事更不建议解压到带中文和空格的路径里比如C:\Users\张三\我的工具\这种虽然大多数情况能跑但个别插件加载、脚本传参的时候会被路径搞出幺蛾子。我自己的习惯是把这类绿色软件统一放到一个约定目录比如C:\dev\libs\gdal-2.3.1所有依赖这个版本的工具都靠明确的路径去引用出问题也好排查。另外要注意如果你电脑上同时装了QGIS、Anaconda、ArcGIS这种自带GDAL的环境不同版本之间很容易互相干扰。经典的冲突场景是你先装了Anaconda里面带了一个GDAL 3.x然后为了老项目又把gdal-2.3.1的bin目录加到PATH最前面结果某个Python包导入时加载了不匹配的DLL直接崩溃。所以我的建议是这个zip的解压目录不要轻易往PATH前面排尽量用专门的环境变量隔离后面会细说。2.2 环境变量配置PATH、GDAL_DATA、GDAL_DRIVER_PATH要让gdalinfo这些命令在任何目录下都能直接敲出来需要配置环境变量。一共三个最核心的第一个是PATH把解压目录下的bin路径加进去第二个是GDAL_DATA指向share\gdal目录这个变量特别重要GDAL运行时需要读取epsg、gcs.csv这些坐标参数定义文件找不到的话会报Unable to open EPSG support file gcs.csv之类的错误第三个是GDAL_DRIVER_PATH如果你用的分发版带有plugins目录就把plugins路径指过去不带的话可以不管。配置的具体步骤是右键此电脑→属性→高级系统设置→环境变量在系统变量或用户变量里新增对应变量然后重新打开一个新的命令行窗口让配置生效。这里有个细节PATH修改后已经打开着的cmd和PowerShell窗口不会自动刷新新手经常配完环境变量发现还是提示找不到命令然后以为配置失败其实只是会话没刷新而已。我在不同机器上配置过几十次遇到最多的问题都是这类非技术原因造成的环境变量本身反而很少出错。2.3 快速验证安装是否成功怎么看配置完之后在命令行里输入gdalinfo --version如果看到类似GDAL 2.3.1, released 2018/xx/xx的输出说明基础安装没问题。再跑一条gdalinfo --formats能列出GDAL支持的所有栅格驱动后面带v的是默认打开带r的表示只读带w的表示支持写入带s的表示支持subdataset。你可以趁机看一眼GTiff、HFA、GeoPackage这些驱动是不是都在这样后面做格式转换的时候心里有数。如果这一步就报错先别急着怀疑命令没配好按第5节的问题排查表格逐项对一下。我见过最多的场景是用户把GDAL_DATA指错了位置或者把PATH里的路径拼成了带bin\bin的重复结构这种低级错误往往比版本兼容问题更磨人。总之验证这一步花不了两分钟但能帮你把后续所有问题的排查范围缩小一大半。3. 命令行工具实战高频场景一次讲透GDAL之所以能在GIS圈子里横着走靠的就是这几个命令行工具。下面我按平时出镜率从高到低讲一遍每个都会给具体的使用场景和参数解释都是可以直接复制去跑的实际用法。3.1 gdalinfo看数据的第一道工序拿到一景影像我第一件事永远是gdalinfo它能把数据的家底全部翻出来。最基础的用法是gdalinfo input.tif输出内容包括影像尺寸Size is 10980, 10980这种、波段数和数据类型Band 1 Block256x256 TypeByte这类、坐标系定义、地理范围、像元大小、金字塔信息以及原始影像自带的各种元数据。这些信息在后续做任何处理之前都必须清楚否则很容易把不该动的数据动了。gdalinfo有个容易被忽略的实用参数是-stats它会对每个波段做一次统计计算输出min、max、mean、stddev。在做影像预处理之前先跑一遍能快速判断数据有没有异常值比如某个波段最大值是65535而其他波段都在几百以内那基本可以断定有异常像元需要处理。还有一个-json参数2.3已经支持把输出整理成JSON格式方便脚本去解析。做自动化处理的时候不少人就是靠gdalinfo -json把影像的元数据抓出来存进数据库做管理的。3.2 ogr2ogr矢量格式转换与坐标变换ogr2ogr是矢量数据处理的主力它做的事情一句话概括读一个矢量文件经过各种处理写成另一个格式。最简单的场景是Shapefile转GeoPackageogr2ogr -f GPKG output.gpkg input.shp。如果想顺便做个坐标转换加上-t_srs参数ogr2ogr -f GeoJSON -t_srs EPSG:4326 output.geojson input.shp这一条命令就把数据从原来的投影坐标系转成WGS84经纬度了。做Web地图、数据共享、入库前预处理这条命令是使用频率最高的一条。ogr2ogr还有个很有用的特性是支持SQL查询过滤-sql SELECT * FROM input WHERE 字段 xxx能在转换的同时完成属性筛选。另一个常用参数是-nlt可以强制指定输出几何类型比如把三维线转成二维线-nlt LINESTRING。写数据库的时候-overwrite和-append这两个参数能控制是覆盖建表还是追加写入。说实话ogr2ogr的参数组合非常丰富我在这篇文章里没法全列出来但上面这几个是日常最绕不开的先把这些吃透应付大多数场景足够了。3.3 gdal_translate与gdalwarp裁剪、缩放与重投影gdal_translate最常用来做的是格式转换、裁剪和重采样。格式转换一个典型例子是gdal_translate -of JPEG -outsize 50% 50% big.tif preview.jpg给大影像生成一个缩略图这在做数据预览和快速质检时特别有用。裁剪则用-projwin参数指定左上角和右下角的坐标范围比如gdal_translate -projwin 120.0 30.0 121.0 29.0 input.tif output.tif注意这里的坐标顺序是左上角X、左上角Y、右下角X、右下角Y很多人第一次用会在这里栽跟头。gdalwarp负责的是更复杂的几何变换最核心的功能就是重投影。比如把WGS84的影像转到Web Mercatorgdalwarp -t_srs EPSG:3857 -r bilinear -co COMPRESSDEFLATE input.tif output.tif。-r参数指定重采样算法常用的是bilinear双线性和cubic三次卷积做分类影像要用near最邻近避免破坏类别值。gdalwarp还可以顺便做切片级别的并行处理-multi和-wo NUM_THREADSALL_CPUS在数据量大的时候能明显提速你别小看这两个参数处理整景的高分影像时能省出不少时间。从实际项目中总结出来的经验是在2.3.1里如果目的是创建金字塔并做Web发布建议先用gdal_translate加-co TILEDYES -co COMPRESSDEFLATE把影像转成内部瓦片化的GeoTIFF再用gdaladdo生成overviews。这样后续不管是给开源地图服务用还是自己写切片程序效率都会高不少。很多人拿到大影像直接gdalwarp一把梭结果后面的访问性能一塌糊涂根子就在于没有提前做好瓦片化和金字塔。4. Python开发环境里怎么接上这个包4.1 是用Python绑定还是直接调命令GDAL官方提供Python绑定但2.3.1这个时代Windows下的官方绑定基本要靠源码编译对大部分不搞编译的人来说不太友好。我常用的做法有两个如果是做原型验证和一次性数据处理直接用subprocess调命令行工具更省事比如用subprocess.run([gdalinfo, -json, filename])拿到JSON结构再进pandas做分析。如果是要写正式的批处理流程我更倾向于用与GDAL 2.3.x配套的rasterio版本1.0.x系列它内部封装的还是GDAL核心库但API更pythonic而且pip直接能装不需要自己编译。这里要特别提醒一点无论走哪条路都要确保命令行里那个GDAL和你Python环境里实际加载的GDAL是同一个版本或者至少不冲突。我就遇到过一台机器上gdalinfo是2.3.1但Python里的rasterio调的是GDAL 3.x结果用Python读某些老格式数据时行为完全不一样排查了半天才意识到是两个版本在打架。所以你在写任何代码之前先花一分钟确认一下两边的版本这笔时间花得特别值。4.2 一段可以直接跑的示例下面用subprocess方式写一个简单但完整的小例子读取一个影像的元数据并把投影信息打印出来。这种写法不依赖Python绑定的编译安装只要命令行里的gdalinfo能用这段代码就能跑。import subprocess import json def read_geotiff_meta(tif_path): result subprocess.run( [gdalinfo, -json, tif_path], capture_outputTrue, textTrue, encodingutf-8, errorsignore ) if result.returncode ! 0: raise RuntimeError(result.stderr) return json.loads(result.stdout) if __name__ __main__: meta read_geotiff_meta(demo.tif) print(meta[size]) print(meta[coordinateSystem][wkt]) print(meta[bands][0][statistics])这段代码的逻辑不复杂gdalinfo -json把元数据输出成JSONPython再用json模块解析。好处是处理过程完全不碰GDAL的Python对象也就避开了版本绑定的坑。正式项目里你可以把提取出来的地理变换参数、坐标系定义、波段统计统一落库做一个简单的影像台账系统后续所有数据文件都有据可查。5. 常见问题与排查技巧实录5.1 命令找不到PATH配置失效的三种情形遇到gdalinfo不是内部或外部命令这类提示不外乎三种原因一是PATH根本没配或者配完没开新窗口二是路径配错了比如解压目录是C:\dev\gdal-2.3.1结果把C:\dev\gdal-2.3.1\bin写成了不带bin的版本gdalinfo的exe在bin下这个最粗心也最常见三是当前shell用的不是同一个用户环境变量如果PATH加的是系统变量但当前cmd是以普通用户权限开的有时候会因为权限级别差异出现读取不到的情况这时候用管理员身份重新开一个窗口基本能解决。5.2 DLL加载失败The code execution cannot proceed这个错误是Windows用户最头疼的一类。打开gdalinfo的时候弹出The code execution cannot proceed because xxx.dll was not found或者直接报0xc000007b本质上都是DLL依赖没满足。0xc000007b这个错误码尤其坑人它往往不是DLL缺失而是DLL位数不匹配——比如你在64位系统里混用了32位的依赖库这种问题光看报错完全看不出来只能靠着对环境的熟悉去判断。排查思路是先用Dependency Walker或者Visual Studio自带的dumpbin工具检查exe依赖的DLL是否都在重点看bin目录下是不是缺了关键运行库。GDAL 2.3.1这个年代编译用的是VS2015/2017的工具集所以请把对应版本的Visual C Redistributable装好。另一个通用解法是找一个能用的环境做对照实验把正常机器上的bin目录整个拿过来覆盖一次如果问题消失说明是某个DLL文件损坏或版本不对重新解压zip就能解决。5.3 坐标参数文件报错GDAL_DATA没有生效运行gdalwarp或ogr2ogr做坐标转换时如果报Unable to open EPSG support file gcs.csv或类似提示基本就是GDAL_DATA指错了。Windows下手动设置的GDAL_DATA路径目录名里别带引号结尾不要多一个斜杠。设置完强烈建议在命令行里执行echo %GDAL_DATA%确认一下实际值再跑一次命令看看是否正常。另外我还碰到过一次神奇的情况GDAL_DATA明明配对了但程序依然报错。最后发现是程序内嵌了另一个GDAL运行时它使用的数据目录不是来自环境变量而是来自编译期写死的相对路径。这种情况就没办法靠环境变量解决只能修改程序配置或者把share\gdal目录复制到它预期的位置。所以说环境变量这套东西在纯命令行场景下最可靠一旦进了GUI程序或者第三方集成环境就要多留个心眼。5.4 中文路径和编码引发的花式报错中文路径是Windows下用GDAL最常见的隐形杀手。老版本GDAL在Windows上处理中文路径时如果文件名里有空格、中文甚至某些特殊字符很容易出现无法打开文件、写入失败这类问题而且报错信息有时候还挺误导人比如Access window out of range这种跟你路径毫无关系的提示。我自己的习惯是所有输入输出文件统一用英文命名目录结构也尽量纯英文。处理完的数据再在业务系统里关联中文名称数据文件和显示层彻底分开。如果是处理从别人那儿拿来的中文路径数据又必须保留中文名优先在Python脚本里用绝对路径和os.path拼接尽量让路径以标准编码传进去。另外2.3.1版本的命令行工具对UTF-8 BOM的处理并不总是友好所以我写批处理脚本时统一保存成UTF-8无BOM格式可以少掉很多莫名其妙的坑。说句实在话Windows环境下GDAL的路径问题比版本问题还常见把这些习惯养成之后能省下不少排查时间。6. 常见问题速查表与最后几句实在话错误现象可能原因解决办法提示gdalinfo不是内部或外部命令PATH未配置或未刷新重新配置PATH并新开命令行窗口The code execution cannot proceed...缺少VC运行时库安装VS2015-2017对应版本的VC Redistributable0xc000007b 错误DLL位数不匹配检查是否存在32位/64位混用Unable to open EPSG support file gcs.csvGDAL_DATA未设置或指向错误确认GDAL_DATA指向share\gdal中文路径文件打不开编码或路径兼容问题改用纯英文路径或在Python中用绝对路径处理这张表是我从大量实操和提问里提炼出来的基本覆盖了gdal-2.3.1-x64-windows.zip这套预编译包在Windows上90%的常见毛病。按表排查大部分问题都能在一刻钟之内定位。最后说点个人体会。我这些年经手过不少GDAL版本从1.11到3.x都用过但每当要维护老项目或者快速搭一套能用的环境时还是会下意识地翻出这个2.3.1的zip。它不新功能也不如后面的版本丰富可它稳而且文档多、案例多、踩坑记录多这对一个工程人员来说太重要了。如果你刚接触GDAL我建议就从这版开始把命令行工具玩熟再去追新版本的特性基础打得越牢后面越不容易被各种兼容问题带偏。本文还有配套的精品资源点击获取