简介GDAL 3.8.0 源码压缩包面向 Linux 下的地理空间开发者、运维人员及科研人员用于编译安装或分析 GDAL 的实现。该包为 3.8.0 版本完整源码树非预编译二进制便于自行配置与定制。GDAL 是采用 X/MIT 协议的开源栅格空间数据转换库配合 OGR 分支可同时支持栅格与矢量数据ArcGIS、Google Earth 等众多 GIS 产品均以其为基础。包内共 2000 个文件以 870 个 cpp 与 518 个 h 源码文件为主覆盖核心抽象数据模型、各类格式驱动及命令行工具203 个 txt 多为文档说明182 个 c 源文件参与底层编码123 个 py 脚本可用于测试与自动化处理另有 Java 绑定、Shell 脚本和 XML 配置等整个压缩包约 13.42 MB。目前已有 569 人学习下载。获得该包后可在 Linux 环境下按需编译生成 gdal_translate、gdalwarp 等官方工具并结合 OGR 矢量库完成空间数据读写同时通过阅读源码可深入理解栅格/矢量驱动、坐标参考等机制为二次开发或系统集成提供扎实基础。1. gdal-3.8.0.tar.gz一个源码包背后藏着三件事很多人拿到 gdal-3.8.0.tar.gz第一反应是解压、./configure、make、make install。但在我接触过的场景里这个流程能一次性走通的比例并不高不是 proj 没装就是 geos 版本不对好不容易编完又发现没有 Python 绑定、没有 Java jar。这不是编译步骤的问题而是在动手前少做了三件事。GDAL 是地理空间数据抽象库几乎所有主流 GIS 软件、遥感处理管线和 PostGIS 的空间扩展都绕不开它。tar.gz 形式意味着你可以完全控制编译选项而不是被动接受预编译二进制。它会带来三个实际收益一是按需裁剪驱动编出更轻的库二是让底层 PROJ、GEOS 与业务版本严格对齐避免隐性的坐标转换坑三是在离线或内网环境也能把依赖一次带全。这套编译链路适合 Linux 运维、GIS 开发、遥感数据工程师也适合正在为 “gdal” 和 “tar.gz” 这两个词发愁的入门者。2. 解压前的三件事校验压缩包、备齐依赖、圈定功能开关2.1 先用 sha256 和 tar -tzf 校验避免“解压到一半报错”的玄学拿到 gdal-3.8.0.tar.gz第一件事不是 configure而是校验文件完整性。tar.gz 在传输过程中被截断、被限速软件改了字节、或者镜像站同步了一半都会导致解压失败。更麻烦的是有些包解压能成功但里面的 configure 脚本早已损坏编译到一半才报莫名错误。这种问题最玄学因为它和你的环境无关。# 计算校验和和官方发布值比对 sha256sum gdal-3.8.0.tar.gz # 只列内容不真正解压确认顶层有 configure 存在 tar -tzf gdal-3.8.0.tar.gz | head -20sha256sum 用于计算校验和如果你从官方渠道拿到过发布时的哈希值直接比对能确定文件是否完整。tar -tzf 则列出压缩包内的文件清单而不解压我一般会先确认第一层目录里有没有 configure、GNUmakefile、README.md 这三位 “老朋友”。如果连 configure 都不在这个包多半是从某个临时链接下的半成品。为什么这一步放在最前因为后续的编译报错排查成本远高于这一步。一个完整的源码包解压后目录结构是规范且固定的任何 “少了一个目录”“多了一个空文件夹” 都值得警觉。我习惯把它作为压缩包的 “开机自检”。2.2 最小依赖清单把“dev”后缀一次装齐解压容易真正拦住人的是依赖。GDAL 源码编译需要两样东西编译器和依赖库。编译器好理解gcc、g、make 缺一不可依赖库则有个特殊规律——在 Debian/Ubuntu 体系里编译期需要的是带-dev后缀的开发包而不是只有运行库。这个坑我见过太多次apt list --installed | grep proj有输出但 configure 仍找不到头文件原因就是 libproj-dev 没装。类别包名Debian/Ubuntu说明基础编译build-essential包含 gcc、g、make坐标投影libproj-dev提供 proj 库和头文件几何拓扑libgeos-dev提供 GEOS 空间操作图像格式libtiff-dev、libjpeg-dev、libpng-dev栅格驱动依赖矢量数据库libsqlite3-dev提供空间索引与缓存网络访问libcurl4-openssl-devOGC API 等网络驱动Python 绑定python3-dev、python3-numpy编译 osgeo 模块必需Java 绑定default-jdk、ant生成 gdal.jar 必需# Debian / Ubuntu 一次性装齐编译依赖 sudo apt update sudo apt install -y build-essential libproj-dev libgeos-dev \ libtiff-dev libjpeg-dev libpng-dev libsqlite3-dev \ libcurl4-openssl-dev python3-dev python3-numpy default-jdk ant如果你是 CentOS、Rocky 或麒麟这类 Red Hat 系对应的包名略有不同gcc-c、proj-devel、geos-devel、libtiff-devel、libjpeg-devel、libpng-devel、sqlite-devel、libcurl-devel、python3-devel。核心逻辑一致缺什么就去找它对应的-dev或-devel包而不是只装运行库。安装顺序上我一般先装 proj 和 geos再装其他图像库。因为 GDAL 的 configure 会显式搜这两个库的版本号如果系统里有一个很老的 proj后续做 UTM 投影和 RPC 正射校正时会出现 EPSG 编码不识别的情况。GDAL 3.8.0 对 proj 的最低版本要求是 6.0这两个库的版本对齐比想象中更重要。2.3 用 configure --help 提前圈定“要什么、不要什么”依赖装完后先别急着./configure先看一眼这个版本到底给了你哪些开关。GDAL 的 configure 脚本是整个源码包的“信息中枢”它决定你编出来的库支持哪些驱动、走哪条构建路径、绑不绑定 Python 和 Java。先跑一下帮助文档再决定。# 只过滤自己关心的开关避免看一屏无关内容 ./configure --help | grep -E with-proj|with-geos|with-python|with-java|with-curl|without-pam|with-libtiff这个命令会把所有和 proj、geos、python、java、curl、tiff 相关的选项过滤出来。看到--with-projyes/no、--with-geosyes/no这类说明默认是自动探测只要系统装了对应开发包就能启用。看到--with-pythonyes/no、--with-javayes/no则说明绑定需要你明确表态。GDAL 3.8.0 默认并不打开所有语言绑定这常常让第一次用源码包的人误以为自己编出来的库里“少了东西”。我的实际做法是从所有默认 “yes” 的选项开始逐个确认哪些是业务需要的。做遥感影像处理TIFF、JPEG、PNG 必须保留要跑 RPC 正射校正和 UTM 投影proj 必须为 yes做矢量入库SQLite 必须保留不用的驱动一律--without-*关掉。这样编出来的体积能小三分之一configure 阶段也能提前发现依赖缺失而不是等 make 到一半才崩。如果你是在 Windows 上用 VS2022 配置 gdal依赖思路也是同一套只是 Windows 下通常走 CMake 或 vcpkgconfigure 脚本主要面向类 Unix 环境——选项思维一样先定需求再选开关。写到这里你会发现一个规律gdal-3.8.0.tar.gz 这类源码包本质上是一套“按需装配”的构建系统越早掌握它的依赖和开关后续的等待时间就越短。这也是源码编译对比预编译二进制的最大价值——你可以定制出一个刚好匹配业务形态的 GDAL。3. 从 configure 到 make install三个阶段的实用参数与验证3.1 configure 阶段我记了十年的几个参数带法依赖备好后configure 命令就是真正的开工信号。GDAL 3.8.0 的 configure 参数很多但真正需要在命令行里显式写出来的我认为只有下面这些./configure \ --prefix/usr/local/gdal-3.8.0 \ --with-projyes \ --with-geosyes \ --with-pythonyes \ --with-javayes \ --with-curlyes \ --with-libtiffyes \ --with-jpegyes \ --with-pngyes \ --without-pam \ --without-odbc这个命令里每一项都可以说是一个“闸门”。--prefix定义安装根目录我通常用一个带版本号的路径这样以后想切回旧版 GDAL 时只要改 PATH 和 LD_LIBRARY_PATH 即可比直接装进 /usr/local 好管理。--with-projyes和--with-geosyes是坐标能力的关键只有这里为 yes后面的gdaltransform和gdalwarp才能正确处理 UTM 和 RPC 正射校正。--with-pythonyes和--with-javayes决定了第 4 章要讲的两种语言绑定是否参与编译。--without-pam是我个人的习惯。PAM预编程的数据模型在自动化批处理中很少用关掉能少编一份依赖。--without-odbc同理如果业务里没有直接连数据库的需求ODBC 驱动完全可以裁掉。每多一个--without-*configure 时间、make 时间都会相应缩短。还有一个隐藏参数容易被忽略--with-proj-data。它用来指定 proj-data 数据文件。GDAL 3.8.0 在查询 EPSG 坐标系时依赖 proj.db 数据库如果这个文件没被找到坐标转换会直接报 “EPSG:32650 not found”。我见过有人在这里卡了一整天最后发现是 proj-data 没装全。提示configure 阶段提前指定 proj-data 路径能省掉后面很多坐标系的排查工作。3.2 make 和 make install并行度、权限与 DESTDIRconfigure 跑完后会生成 Makefile真正的编译阶段来了。常见做法是直接 make但我建议先看两个指标物理核数和可用内存。# 逻辑核数量 nproc # 内存总量与剩余量 free -hnproc 显示逻辑核数free -h 显示内存。我一般把并行数设为物理核数加 1比如一个 8 核 16 线程的机器用make -j4而不是make -j16。为什么GDAL 编译是重 CPU、重内存操作每个编译线程会吃掉几百 MB 到上 GB 内存。16 并行下去内存先崩然后触发 OOM整个 make 过程在最后关头被杀之前的等待全部白费。降并行度不是性能妥协是在给稳定性留余地。# 编译-j 后数字按物理内存调整 make -j4 # 安装到 configure 指定的前缀目录 make install # 刷新共享库缓存 ldconfig如果前缀路径是你自己有权限的目录比如 /opt 或 $HOME可以省掉 sudo。ldconfig 这一步很容易被漏掉GDAL 编译成功后运行时会去 ldconfig 缓存里找 libgdal.so缓存没更新就会报 “error while loading shared libraries”。跑一下ldconfig -v | grep gdal能过滤到 libgdal.so 的路径这步才算踏实。还有一个参数值得记住DESTDIR。它不改变 configure 里的 prefix但可以让安装落到临时目录方便后续打包分发# 安装到临时目录便于后续打成离线包 make install DESTDIR/tmp/gdal-pkg这个命令会把所有文件装到 /tmp/gdal-pkg/usr/local/gdal-3.8.0 下。对离线部署来说这是很实用的手段第 6 章还会用到它。代价是运行时需要关注所有绝对路径所以只是打包用的方式本地开发验证不建议走 DESTDIR。3.3 用 gdalinfo --version 验证安装没白装安装完成后第一件事不是兴奋地跑业务脚本而是做一次完整验证。GDAL 自带命令行工具足够验证编译结果。# 查看版本以及链接的 PROJ / GEOS 版本 /usr/local/gdal-3.8.0/bin/gdalinfo --version # 确认 GTiff 驱动是否编译进去 /usr/local/gdal-3.8.0/bin/gdalinfo --formats | grep -i GTiff # 确认 shapefile 矢量驱动是否存在 /usr/local/gdal-3.8.0/bin/ogrinfo --formats | grep -i ESRI Shapefilegdalinfo --version 会输出 GDAL 3.8.0 和它所链接的 GEOS、PROJ 版本号。如果这里显示的 PROJ 版本和你预期不符说明 configure 阶段可能没找到系统里真正的 proj而是捡了个旧的。gdalinfo --formats 列出所有编译进去的栅格驱动ogrinfo --formats 列出矢量驱动。这两个命令输出一长串名字里面有没有 GTiff、有没有 ESRI Shapefile直接反映你 configure 阶段的选择是否正确。如果没有现成测试数据我习惯创建一个最小 GTiff 来验证写驱动好不好使。下面这段 Python 需要用编译出来的 Python 绑定正好也能验证 osgeo 模块是否可用import numpy as np from osgeo import gdal, osr # 创建 64x64 的假栅格 arr np.zeros((64, 64), dtypenp.uint16) driver gdal.GetDriverByName(GTiff) out driver.Create(/tmp/test_utm.tif, 64, 64, 1, gdal.GDT_UInt16) out.GetRasterBand(1).WriteArray(arr) # 写入 UTM 50N 投影 sr osr.SpatialReference() sr.ImportFromEPSG(32650) out.SetProjection(sr.ExportToWkt()) out.FlushCache() print(write ok, gdal.VersionInfo())这段脚本干了两件事创建一张 64x64 的栅格对象然后给它写上 UTM 50NEPSG:32650投影。如果它最后能打印出 write ok 和 3.8.0说明 GTiff 驱动写栅格没问题、PROJ 坐标系统编码能被识别、Python 绑定也正常。这比单纯跑 gdalinfo --version 更接近真实业务链路。等这一步过了你才算真正把 gdal-3.8.0.tar.gz 变成一个可以依赖的空间计算库。4. Python 和 Java 两条主线让源码包对上你的语言4.1 Python 绑定用源码里的 swig 目录自编不做“张冠李戴”编译成功只能说明 C 库可用但大部分从业者的业务代码是 Python。这里有一个高频翻车系统 pip 里早就装了一个 gdal 包但它和源码编译的 libgdal.so 版本对不上结果就是from osgeo import gdal能导入一调用坐标转换就报符号找不到。这种现象在 GIS 圈子里很常见根因是 pip 的二进制包和本地源码库各管各的互为黑匣子。正确做法在 configure 阶段已经埋下伏笔--with-pythonyes会生成 osgeo 模块的构建入口也就是源码包里的swig/python目录。编译完 C 库后再单独把 Python 绑定编一遍。# 进入源码自带的 python 绑定目录 cd gdal-3.8.0/swig/python # 构建绑定模块 python3 setup.py build # 安装到当前 python 环境 python3 setup.py install这段命令会读取编译期的头文件路径生成与 libgdal.so 版本严格匹配的 osgeo 模块。setup.py build 执行的是本地构建setup.py install 把最终产物安装到当前 Python 环境的 site-packages 里。跑完后验证一下版本# 确认 osgeo 模块版本与源码版本一致 python3 -c from osgeo import gdal; print(gdal.VersionInfo())如果输出的是 3.8.0说明 Python 绑定和 C 库来自同一次编译不会再出现符号对不上的问题。这里有一个前提编译前python3-dev和numpy必须装好否则 setup.py 会在编译 extension 模块时报numpy/arrayobject.h: No such file or directory。这是 GDAL Python 绑定最常见的报错之一原因就是 numpy 的 C 头文件没在 include 路径里。如果业务对 Python 版本有强约束比如项目里锁定了某个虚拟环境建议用python3 setup.py install --prefix$VIRTUAL_ENV把绑定装到虚拟环境内而不是全局 site-packages。这样多环境多版本 GDAL 也可以共存不会互相污染。4.2 Java 绑定gdal.jar 要自己生成别去网上捡现成的另一个高频需求是 Java。搜索词里总有 “gdal jar 包”但我要泼一盆冷水网上流传的 gdal.jar 很多是拿别人编译好的环境打包的和你自己这台机器的 libgdal.so 不匹配。JNI 的底层逻辑决定了 gdal.jar 必须与 libgdal.so 严格对应否则运行时会抛UnsatisfiedLinkError或ClassNotFoundException。这不是玄学是 JNI 的符号表绑定。所以我在 Java 项目里一直坚持自己生成 jar。前提是 configure 阶段开了--with-javayes并且系统里有 JDK 和 ant。编译时进入源码包自带的 swig/java 目录# 指定 JDK 环境 export JAVA_HOME/usr/lib/jvm/default-java # 进入 java 绑定目录 cd gdal-3.8.0/swig/java # 用 ant 构建 gdal.jar 和 jni 库 ant buildant build 会读取源码包里的 build.xml把 Java 类编译成 gdal.jar并生成 JNI 的共享库文件通常是 libgdal.so 旁边的libgdaljni.so。之后部署时不只是 jar 要拷贝libgdaljni.so也必须和libgdal.so放在一起并且让 Java 的java.library.path包含它们。一个常见错误是只把 gdal.jar 丢进 Maven 仓库运行时报找不到 jni 库就是因为它没有把libgdaljni.so放到系统库路径里。还有一个容易被忽略的点JDK 版本。用 Java 8 编译出来的绑定文件换到 JDK 17 的运行环境上不一定能跑。如果你在用 “linux x64 的 java8 .tar.gz” 这类方式部署 JDK那 gdal 的 Java 绑定也要用同样位数的 JDK 和同样的编译目标。我们这边不少老项目锁定 Java 8所以编译机、运行机、JDK 版本必须三者一致否则 Class 版本冲突的坑早晚会踩。4.3 跑一次 RPC 正射校正和 UTM 投影验证整条链路前面提到的 RPC 正射校正和 UTM 投影是很多遥感从业者下载 gdal-3.8.0.tar.gz 的原始动机。RPC 是卫星影像自带的有理多项式系数gdalwarp 可以用它把影像从无定位的原始几何纠正到地图坐标系UTM 是通用横轴墨卡托投影国内很多项目要求结果落在这个投影下。这两个功能背后依赖的是 PROJ 库的地理网格和坐标变换算法所以在第 3 章 configure 时--with-projyes不是可选项而是必选项。验证命令比想象中简单只要有带 RPC 的一组影像和 DEM 就可以跑# 用 RPC 校正输入影像输出到 UTM 50N gdalwarp -t_srs EPSG:32650 -rpc \ -overwrite \ input_with_rpc.tif output_utm_50n.tif-t_srs EPSG:32650把输出投影定为 UTM 50N-rpc让 gdalwarp 使用影像内部 RPC 做控制-overwrite允许覆盖输出文件。如果这条命令能跑通且不报 “PROJ: proj operation not recognized”说明你的 GDAL、PROJ、RPC 链路是完整的。如果在这个阶段报 “PROJ: proj operation not recognized” 或者 “EPSG:32650 not found”大概率是 proj-data 没装全。GDAL 3.8.0 对坐标系的识别依赖 proj.db 数据库缺少它时所有 EPSG 编码都会失效。解决方法是提前装好 proj-data 包或手工指定环境变量。这部分问题我在第 5 章还会展开这里先记住一个原则坐标转换出问题先检查 proj 版本和 proj.db不要急着怀疑算法代码。5. 避坑gdal-3.8.0 编译现场的 5 条真实踩坑记录5.1 configure 说找不到 proj.h但 proj 明明装了现象./configure走到一半报错checking for proj.h... not found但输入apt list --installed | grep proj又能看到 proj 相关包。原因系统里装的是 libproj 运行库不是 libproj-dev。configure 阶段要的是头文件 proj.h而不是动态库。另一个可能是有多套 proj 共存configure 找到的是老版本的头文件路径。解决先安装开发包再重跑 configure。# 编译期需要的是 -dev 包不是运行库 sudo apt install libproj-dev如果你怕系统里有多个 proj 版本打架可以先看proj命令的版本。GDAL 3.8.0 需要 proj 6 以上如果proj命令本身返回一个老版本需要升级基础库而不是 GDAL 源码。5.2 make 时内存崩溃OOM killed现象make -j8跑到一半终端出现Killed或日志里能看到virtual memory exhausted: Cannot allocate memory。原因GDAL 的 C 模板编译非常吃内存并行编译线程数乘上单线程内存占用超过了可用内存上限。很多新手直接用make -j$(nproc)在 8 核机器上开了 8 个编译线程每个峰值占用超过 1GB内存直接被打爆。解决先看物理内存再决定并行度。# 查看物理内存总量 free -h # 保守设置并行编译数 make -j2我自己的习惯是内存只有 8GB 时用 -j216GB 时用 -j432GB 以上才敢放开。同时建议给临时目录和源码目录留足空间df -h /tmp确认一下因为编译过程会产生大量中间对象文件。5.3 make install 成功但运行时报找不到 libgdal.so现象所有构建步骤都成功但跑gdalinfo时系统提示error while loading shared libraries: libgdal.so: cannot open shared object file。原因make install 执行后ldconfig 缓存没有更新或者自定义--prefix的 lib 目录不在系统默认搜索路径里。解决先把 libgdal.so 所在目录确认出来再刷新缓存。# 找到 libgdal.so 位置 find / -name libgdal.so 2/dev/null # 刷新动态链接器缓存 sudo ldconfig如果用了类似--prefix/usr/local/gdal-3.8.0的自定义路径ldconfig 默认不会扫它。这时有两种办法把该目录写入/etc/ld.so.conf.d/gdal.conf再 ldconfig或者每次运行前设LD_LIBRARY_PATH/usr/local/gdal-3.8.0/lib。前者是持久方案后者适合快速验证。5.4 Python 里导入 osgeo 成功但一调用就报符号找不到现象from osgeo import gdal不报错但运行gdal.VersionInfo()或某个坐标函数时抛出undefined symbol: _ZN5OGRFeature...一类的错误。原因Python 绑定的版本和 libgdal.so 的版本不是来自同一次编译。如果你之前用pip install gdal装过旧版本pip 会把旧版 osgeo 模块放到 site-packages运行时它会尝试链接新版 libgdal.so符号表对不上于是炸掉。这类问题就是上面说的“黑匣子”——光看导入没问题一跑才暴露。解决把 Python 侧的旧 gdal 包清掉改用源码里的 swig/python 重新构建。# 卸载旧版 pip 包 pip uninstall -y gdal # 用源码目录重新构建绑定 cd gdal-3.8.0/swig/python python3 setup.py build python3 setup.py install编完后用python3 -c from osgeo import gdal; print(gdal.__file__)确认 osgeo 模块指向的是源码构建产物而不是 pip 残留。如果输出路径仍是旧 site-packages多半是构建时 Python 解释器路径选错需要--prefix强制指定当前环境。5.5 麒麟 V10 或离线服务器上RPC 正射校正报 EPSG 不可识别现象在一台能够正常联网的 Ubuntu 机器上编译好的 GDAL拷到麒麟 V10 或内网离线服务器后gdalwarp -t_srs EPSG:32650报EPSG:32650 not found。原因GDAL 查询坐标系编码靠的是 proj-data 数据文件它不会被打进 libgdal.so 里。离线机器上没有 proj-data或者环境变量PROJ_LIB指向了一个不存在的目录导致坐标系数据库找不到。这和代码逻辑无关纯粹是运行时数据缺失。解决在编译机或能联网的机器上找到 proj-data 的 tar.gz 包把它拷贝到目标机然后指定环境变量。# 指定 proj 数据目录 export PROJ_LIB/opt/proj-data # 再跑 RPC 校正 gdalwarp -t_srs EPSG:32650 -rpc input.tif output_utm.tif我建议直接把 proj-data 解压到 /opt/proj-data并在系统 profile 里写死这一行避免每次手工设置。翻过这个坑之后你会发现离线部署 GDAL 的真正难点不是编译过程而是把 proj 数据这种运行时资产想清楚。这个习惯让我后来在国产操作系统和云内网环境里部署 3.8.0 的源码包时少焦虑了非常多。6. 离线部署的最后一公里把 tar.gz 变成能交付的运行时源码编译完成的 GDAL最终要面临一个现实问题怎么部署到目标机器。常见做法是把整个安装目录打成 tar.gz而不是重新在目标机编译一遍。gdal-3.8.0.tar.gz 是源码你交付的应该是“运行时”。这里有一个我一直在用的打包方式用第 3 章提到的 DESTDIR。# 安装到临时目录不污染编译机环境 make install DESTDIR/tmp/gdal-runtime cd /tmp/gdal-runtime # 把运行时打成离线分发包 tar czf gdal-3.8.0-runtime.tar.gz usr/local/gdal-3.8.0执行后压缩包里是所有安装文件包含 bin、lib、include、share。把它拷到目标机解压到相同路径然后设置 PATH 和 LD_LIBRARY_PATH就能跑起来。如果你有 kubekey 这类工具管理内网集群可以把 tar.gz 作为软件制品推送到私有仓库目标节点拉取后做同样的路径展开没有这类工具的话用 scp 或移动介质拷贝效果也一样。核心是把路径规划好避免“二进制有、数据没有”的悲剧。目标机上验证的第一条命令我会用一个坐标变换来确认最新状态# 把经纬度坐标转换到 UTM 50N验证完整链路 echo 121.5 31.2 | gdaltransform -s_srs EPSG:4326 -t_srs EPSG:32650如果输出里出现 X、Y 坐标值说明 libgdal.so、proj.db、命令行工具全部正常。如果此时才想起没带 proj-data就会看到第 5.5 节里那个熟悉的报错。我吃过大亏早年部署 GDAL 时只拷了 bin 和 lib忘了 proj-data结果在客户现场看着 gdalwarp 报 “EPSG not found”只能红着脸重新传包。从那以后我每次离线交付都会做三件事确认 proj.db 路径、确认 LD_LIBRARY_PATH、跑一次经纬度到 UTM 的 gdaltransform。这套习惯也适用其它 tar.gz 工具链先验证运行链路再谈业务能省掉大量异地排查时间。希望帮到你。本文还有配套的精品资源点击获取