简介本资源为自行编译的 GDAL 2.3.1 Windows 64 位版本压缩包面向从事 GIS、遥感影像处理与空间数据转换的开发者及研究人员。GDAL 是支持 GeoTIFF、JPEG、HDF4、HDF5、ECW、MrSID 等多种栅格与矢量格式的开源地理空间库自行编译便于按需选择编译选项与依赖配置。压缩包共 451 个文件约 54.57MB以 h 与 hpp 头文件、cmake 构建脚本、exe 可执行程序、dll 动态库、lib 导入库及 pdb 调试符号为主另含 pc 配置、json 与 txt 说明等覆盖开发、构建与调试所需组件。目前已有 137 人学习下载。读者可据此获得完整的头文件与库文件用于二次开发、格式转换与投影处理并借助示例程序与构建脚本快速搭建编译环境适合具备一定 C/C 与构建工具链基础的中高级用户参考。1. 为什么一个 gdal-2.3.1-x64-windows.zip 至今还有人翻出来用如果你在 Windows 上做遥感影像处理、GIS 数据转换或者给某个老系统补依赖大概率会在某个技术群里看到有人求gdal-2.3.1-x64-windows.zip。这不是怀旧而是现实很多存量项目锁死在 GDAL 2.x 的 API 上升级到 3.x 会触发一堆编译错误和坐标行为变化而 Windows 下自己从源码编译 GDAL 又是个出了名的体力活。这个压缩包本质上是一个预编译好的 64 位 Windows 二进制分发包解压后能得到gdalinfo.exe、gdal_translate.exe、ogr2ogr.exe等命令行工具以及供 C/C、Python 调用的动态库和头文件。它解决的核心问题是让你在 Windows 上不装编译环境也能直接调用 GDAL 做格式转换、投影变换、栅格裁剪。适合谁适合需要维护老管线的工程师、做离线数据处理的分析人员以及想快速验证 GDAL 行为再决定是否迁移的人。下面我按实际落地顺序把这个包怎么用、参数怎么设、坑在哪讲清楚。2. 解压之后先别急着写代码目录结构与运行环境确认拿到gdal-2.3.1-x64-windows.zip后第一件事不是打开 Python而是先确认这个包到底给了你什么。很多人翻车就翻在“解压完直接 import gdal”结果报DLL load failed然后开始怀疑人生。这一章先把目录结构、环境变量和最小验证命令跑通后面才谈得上写业务代码。2.1 典型目录布局与三个关键路径预编译的 Windows 包通常会把文件分成几个部分可执行文件、动态库、头文件、Python 绑定、数据目录。不同来源的打包方式略有差异但核心结构大同小异。解压后你一般会看到类似这样的层级gdal-2.3.1-x64-windows/ ├── bin/ # gdalinfo.exe、gdal_translate.exe、ogr2ogr.exe 等 ├── include/ # gdal.h、gdal_priv.h 等 C/C 头文件 ├── lib/ # gdal_i.lib 等导入库 ├── data/ # gdal-data、proj 参数文件 └── python/ # osgeo 包部分包会带这里有三个路径必须记住bin目录要进PATH否则命令行工具找不到依赖的 DLLdata目录要设成GDAL_DATA环境变量否则投影转换会报“无法找到 proj 定义”python目录要进PYTHONPATH否则from osgeo import gdal直接失败。我一般会在解压后立刻用 PowerShell 设临时变量验证确认没问题再写进系统环境变量。# 假设解压到 D:\tools\gdal-2.3.1-x64-windows $env:GDAL_HOME D:\tools\gdal-2.3.1-x64-windows $env:PATH $env:GDAL_HOME\bin; $env:PATH $env:GDAL_DATA $env:GDAL_HOME\data $env:PYTHONPATH $env:GDAL_HOME\python; $env:PYTHONPATH # 验证命令行工具是否可用 gdalinfo --version这段脚本的逻辑很直接先把解压根目录记成GDAL_HOME再把bin追加到PATH最前面保证优先调用这个版本的 DLL而不是系统里可能存在的其他 GDAL。GDAL_DATA指向数据目录PYTHONPATH指向 Python 绑定。参数上唯一要注意的是路径不要带中文和空格GDAL 2.3.1 对非 ASCII 路径的处理并不完善带空格有时会让gdal_translate的参数解析出问题。执行gdalinfo --version如果输出GDAL 2.3.1, released 2018/06/22说明环境基本通了。2.2 用 gdalinfo 做最小闭环验证环境变量设完不要急着上业务数据先拿一张小图跑gdalinfo。这一步的目的是确认栅格驱动、投影解析、数据读取三条链路都正常。随便找一张 GeoTIFF或者用gdal_translate从别的格式转一张出来。# 查看影像元信息确认驱动、尺寸、坐标系、波段数 gdalinfo demo.tif # 如果手上没有测试影像可以用 gdal_translate 从 PNG 造一个带坐标的 gdal_translate -of GTiff -a_srs EPSG:4326 -a_ullr 116.0 40.0 116.5 39.5 input.png demo.tifgdalinfo的输出里重点看三块Driver是不是GTiffSize is后面的行列数对不对Coordinate System is能不能解析出 EPSG 代码。如果坐标系显示为LOCAL_CS或者一堆proj参数说明GDAL_DATA没设对proj 定义没加载上。gdal_translate那条命令里-of GTiff指定输出格式-a_srs强制赋一个坐标系-a_ullr手动指定左上右下角地理坐标顺序是左上经度、左上纬度、右下经度、右下纬度。这个技巧在没有地理信息的图片上做快速验证特别顺手但注意-a_ullr只是赋坐标不做重投影别拿它当几何校正用。2.3 Python 绑定导入与版本核对命令行通了之后再验证 Python 绑定。GDAL 2.3.1 的 Python 绑定是osgeo包导入方式和 3.x 一样但内部 API 有差异。导入成功后第一件事是核对版本避免 Python 绑定的版本和 DLL 版本不一致——这种“混搭”是 Windows 下最隐蔽的坑之一。# 验证 Python 绑定是否指向当前解压的 GDAL from osgeo import gdal, ogr, osr print(GDAL version:, gdal.__version__) print(OGR version:, ogr.__version__) # 打开刚才生成的 demo.tif读取基本信息 ds gdal.Open(demo.tif, gdal.GA_ReadOnly) if ds is None: raise RuntimeError(打开失败检查路径和驱动) print(Raster size:, ds.RasterXSize, ds.RasterYSize) print(Projection:, ds.GetProjection()) print(Band count:, ds.RasterCount) # 读取第一个波段的前 10x10 像素 band ds.GetRasterBand(1) data band.ReadAsArray(0, 0, 10, 10) print(Sample data shape:, data.shape) ds None # 关闭数据集释放文件句柄这段代码的关键点在最后一行ds None。GDAL 的 Python 绑定依赖引用计数来关闭数据集如果不显式置空Windows 下文件句柄不会立即释放后续想覆盖写同一个文件就会报“文件被占用”。ReadAsArray的四个参数是起始列、起始行、列数、行数这里读的是左上角 10×10 区域。如果gdal.__version__输出不是 2.3.1说明PYTHONPATH里混进了别的 GDAL 包需要把顺序调对或者清理掉旧包。3. 用 gdal_translate 和 ogr2ogr 跑通格式转换与投影变换环境验证完接下来是实际业务里最高频的两类操作栅格格式转换和矢量数据转换。GDAL 2.3.1 自带的gdal_translate和ogr2ogr能覆盖大部分需求但参数组合多设错一个就可能导致输出数据范围不对或者属性丢失。这一章把常用参数和验证方法拆开讲。3.1 gdal_translate 的四个必调参数gdal_translate做栅格转换核心就四类参数输出格式、波段选择、数据类型、压缩方式。很多人只写-of就完事结果输出文件巨大或者波段顺序乱了。下面这条命令是一个比较完整的例子# 把输入影像转成 COG 风格的 GeoTIFF选前三个波段转成 Byte用 LZW 压缩 gdal_translate \ -of GTiff \ -b 1 -b 2 -b 3 \ -ot Byte \ -co COMPRESSLZW \ -co TILEDYES \ -co BIGTIFFIF_SAFER \ input.tif output.tif逐项说明-of GTiff指定输出驱动-b 1 -b 2 -b 3按顺序选波段注意顺序就是你写的顺序写反了会导致 RGB 错位-ot Byte把数据类型转成 8 位无符号适合做可视化输出但如果原始数据是 16 位反射率直接转 Byte 会截断需要配合-scale做拉伸-co COMPRESSLZW是无损压缩比 DEFLATE 快比 JPEG 安全-co TILEDYES生成分块存储后续做金字塔或者局部读取时性能差别很大-co BIGTIFFIF_SAFER让 GDAL 在文件可能超过 4GB 时自动用 BigTIFF避免写到一半失败。我一般还会加-co NUM_THREADSALL_CPUS加速压缩但 2.3.1 对多线程压缩的支持有限加了不一定生效得实测。3.2 ogr2ogr 做矢量转换时的坐标系陷阱矢量转换用ogr2ogr最常见的需求是把 Shapefile 转 GeoJSON或者做坐标系转换。这里最大的坑是-t_srs做重投影时如果没有指定-s_srsGDAL 会尝试从源数据读取坐标系但 Shapefile 的.prj文件经常缺失或者写得不规范导致重投影结果偏移几百米。# Shapefile 转 GeoJSON并重投影到 EPSG:3857 ogr2ogr \ -f GeoJSON \ -s_srs EPSG:4326 \ -t_srs EPSG:3857 \ -lco COORDINATE_PRECISION6 \ output.geojson \ input.shp-f GeoJSON指定输出格式-s_srs EPSG:4326显式声明源坐标系这一步在源数据坐标系不可靠时是必须的-t_srs EPSG:3857指定目标坐标系-lco COORDINATE_PRECISION6控制输出坐标的小数位数默认精度可能不够做 Web 地图时 6 位大约到分米级。如果转换后图形位置明显偏移先检查-s_srs是不是写对了再检查源数据的坐标值范围是不是经纬度。有个快速判断方法用ogrinfo -al -so input.shp看范围如果 X 范围在 -180 到 180 之间基本就是经纬度。3.3 转换结果怎么验证才算数转换完不能只看文件生成了就完事得验证三件事范围、坐标系、属性。栅格用gdalinfo看角点坐标和Coordinate System矢量用ogrinfo看Extent和Layer SRS。更稳妥的做法是用 Python 读回来做数值比对。from osgeo import gdal # 对比转换前后影像的范围和波段统计 src gdal.Open(input.tif) dst gdal.Open(output.tif) print(源范围:, src.GetGeoTransform()) print(目标范围:, dst.GetGeoTransform()) print(源波段数:, src.RasterCount, 目标波段数:, dst.RasterCount) # 读取目标影像第一个波段的统计值 band dst.GetRasterBand(1) stats band.GetStatistics(True, True) print(最小值/最大值/均值/标准差:, stats)GetGeoTransform()返回六个值左上角 X、X 方向分辨率、旋转项、左上角 Y、旋转项、Y 方向分辨率通常为负。转换前后如果分辨率变了说明可能触发了重采样需要确认是否符合预期。GetStatistics(True, True)的第一个参数表示允许近似统计第二个表示强制重新计算返回四个值。如果统计值全是 0 或者异常检查-ot和-scale是不是把数据压没了。4. 避坑GDAL 2.3.1 在 Windows 上的五类高频翻车这一章是我自己踩过和帮别人排查过的真实问题汇总每条按“现象 → 原因 → 解决”写。GDAL 2.3.1 在 Windows 上的坑大多集中在 DLL 加载、路径编码、坐标系解析和内存释放上跟 Linux 下的体验差别很大。4.1 现象import gdal 报 DLL load failed原因Python 找到的osgeo包和实际加载的gdal.dll版本不匹配或者bin目录没进PATH导致依赖的proj.dll、geos.dll找不到。Windows 的 DLL 搜索顺序是先当前目录再PATH如果系统里装过其他 GIS 软件很容易加载到错误版本。解决用where gdalinfo确认命令行调用的是哪个版本用 Python 的os.add_dll_directory3.8或者把bin目录加到PATH最前面如果还不行用 Dependency Walker 类的工具看gdal.dll到底缺哪个依赖。最稳妥的做法是把这个包解压到一个干净目录不要和别的 GIS 软件混装。4.2 现象投影转换结果偏移几百米原因GDAL_DATA没设或者指向了错误版本的数据目录导致 proj 参数文件加载失败GDAL 退化成用默认参数做转换。另一个常见原因是源数据坐标系声明错误比如把 CGCS2000 当成 WGS84 用。解决先echo %GDAL_DATA%确认路径存在且里面有proj相关文件再用gdalinfo看源数据的Coordinate System是否解析出 EPSG 代码如果源数据坐标系不确定用-s_srs显式指定。做高精度转换时注意 2.3.1 默认的 proj 版本较老某些新定义的坐标系可能不支持。4.3 现象中文路径下 gdal_translate 报错或输出为空原因GDAL 2.3.1 在 Windows 下对 UTF-8 路径的支持不完整命令行参数里的中文路径可能被按本地编码解析导致文件打不开。解决最直接的办法是路径全用英文和数字如果必须用中文路径在 Python 里用gdal.Open时传入 UTF-8 编码的路径并且确保 Python 的文件系统编码设置正确。命令行工具建议先cd到目标目录再用相对路径减少编码转换环节。4.4 现象写入 GeoTIFF 后文件被占用无法覆盖原因Python 里gdal.Open返回的数据集没有显式关闭引用计数没归零Windows 不允许删除或覆盖被占用的文件。解决每次用完数据集后执行ds None或者用with上下文管理需要自己封装。在循环里处理大量文件时建议把打开和关闭放在同一个函数里函数返回前置空。如果已经出现占用用handle.exe类工具找到占用进程或者重启 Python 进程。4.5 现象gdal_translate 转出来的文件比原文件大好几倍原因没有设置压缩参数默认输出未压缩的 GeoTIFF或者-ot把低比特数据转成了高比特比如把 1 位掩膜转成 Byte。解决加-co COMPRESSLZW或-co COMPRESSDEFLATE检查-ot是否必要如果只是做格式转换尽量保持原数据类型用-co PREDICTOR2对整型数据做预测压缩通常能再降 10% 到 30%。另外-co TILEDYES配合-co BLOCKXSIZE256 -co BLOCKYSIZE256能让后续读取更快但文件大小会略增。5. 进阶把 GDAL 2.3.1 封装成可复用的 Python 处理函数前面讲的都是单条命令和单次操作实际项目里你需要把 GDAL 调用封装成稳定的函数才能批量处理。这一章给一个可复用的封装思路包含错误处理、临时文件管理和批量转换的骨架。最后说一个我自己的习惯。5.1 一个带错误处理的栅格转换函数下面这个函数把gdal_translate的常用参数封装起来用subprocess调用命令行工具同时检查返回码和输出文件是否存在。相比直接用 Python 绑定命令行方式在批量处理时更稳因为每次调用都是独立进程不会因为一个文件出错影响后续。import subprocess import os import tempfile def translate_raster(src_path, dst_path, bandsNone, dtypeByte, compressLZW, extra_argsNone): 封装 gdal_translate做栅格格式转换。 src_path: 输入影像路径 dst_path: 输出影像路径 bands: 波段列表如 [1,2,3]None 表示全部 dtype: 输出数据类型如 Byte/UInt16/Float32 compress: 压缩方式LZW/DEFLATE/NONE extra_args: 其他参数列表 if not os.path.exists(src_path): raise FileNotFoundError(f输入文件不存在: {src_path}) cmd [gdal_translate, -of, GTiff, -ot, dtype, -co, fCOMPRESS{compress}, -co, TILEDYES] if bands: for b in bands: cmd.extend([-b, str(b)]) if extra_args: cmd.extend(extra_args) cmd.extend([src_path, dst_path]) # 捕获输出便于排查失败原因 result subprocess.run(cmd, capture_outputTrue, textTrue) if result.returncode ! 0: raise RuntimeError(f转换失败: {result.stderr}) if not os.path.exists(dst_path): raise RuntimeError(命令返回成功但输出文件不存在) return dst_path这个函数的关键设计点用subprocess.run而不是os.system能拿到标准错误输出capture_outputTrue把 GDAL 的报错信息抓下来排查时不用猜转换后检查输出文件是否存在防止 GDAL 返回 0 但实际没写成功的情况。bands参数用列表传入内部转成多个-b参数。extra_args留了口子需要加-scale或者-projwin时直接传列表进去。5.2 批量处理的临时文件与清理策略批量转换时我习惯先把输出写到临时目录全部成功后再移动到目标目录。这样做的好处是中途失败不会留下半成品文件重跑时不用手动清理。用tempfile.mkdtemp创建临时目录处理完用shutil.move移走最后shutil.rmtree清理。import shutil import tempfile from pathlib import Path def batch_translate(input_dir, output_dir, pattern*.tif): input_dir Path(input_dir) output_dir Path(output_dir) output_dir.mkdir(parentsTrue, exist_okTrue) tmp_dir Path(tempfile.mkdtemp(prefixgdal_batch_)) success, failed [], [] try: for src in input_dir.glob(pattern): dst_tmp tmp_dir / src.name try: translate_raster(str(src), str(dst_tmp)) success.append(src.name) except Exception as e: failed.append((src.name, str(e))) # 全部处理完再移动到目标目录 for name in success: shutil.move(str(tmp_dir / name), str(output_dir / name)) finally: shutil.rmtree(tmp_dir, ignore_errorsTrue) return success, failed这段代码里tempfile.mkdtemp创建的目录在系统临时区finally块保证无论成功失败都会清理。shutil.move在同一个磁盘分区内是原子操作跨分区会退化成复制加删除但至少不会出现半个文件。返回的success和failed列表可以直接写日志方便定位是哪个文件出了问题。5.3 我自己的一个习惯先跑单文件再上批量最后说个血泪经验。我早期做批量转换时喜欢直接写循环跑几百个文件结果参数设错几百个输出全是废的还得一个个删。后来养成习惯任何批量脚本先拿一个文件跑通用gdalinfo验证输出范围和波段统计确认无误再放开循环。这个习惯帮我省下的时间远比多写几行验证代码多。GDAL 2.3.1 虽然老但它的命令行工具和 Python 绑定在 Windows 上依然是做遥感批处理最省心的选择之一前提是你把环境、路径和参数这三件事管住。希望帮到你。本文还有配套的精品资源点击获取