企业官网建设流程全解析

简介：本资源为GDAL 3.0.0在Windows 10平台使用Visual Studio 2019编译的静态库压缩包，面向从事GIS开发、遥感数据处理与地图服务的C++开发者，解决动态库版本匹配与运行时依赖问题。包内共340个文件，以114个html文档、104个C++头文件、35个gfs投影定义文件、24个exe工具及若干csv、xsd、xml、wkt等配置与数据文件为主，压缩包约140.38MB，目录结构完整，便于按模块查阅。资源已集成PROJ坐标转换库与SQLite3轻量数据库，静态链接方式可直接嵌入应用程序，避免运行时库冲突。已有640人学习下载，适合需要处理栅格数据读取、坐标投影变换、元数据存储及VRT虚拟文件操作的开发者，可快速搭建本地地理空间数据处理环境，简化编译配置流程，提升GIS项目开发效率。

1. 从一份 GDAL_BUILD(release).rar 说起：为什么我劝你先别急着解压

如果你正在搜 GDAL 怎么安装、PROJ 怎么配、SQLITE3 要不要单独装，那你大概率已经踩进了 GIS 环境搭建里最经典的那个坑：GDAL 本身能装，但一跑坐标转换就报 PROJ 数据库找不到，一读 GeoPackage 就提示 SQLite 驱动缺失。这份 GDAL_BUILD(release).rar 就是冲着这个场景来的——它把 GDAL、PROJ、SQLITE3 三件套的编译产物打包在一起，省掉你从源码逐个编译的折腾。但我要先说清楚：拿到压缩包不等于装好了，解压只是第一步，环境变量、PROJ_LIB 指向、SQLite 动态库路径这三处只要错一个，后面全是玄学报错。这篇笔记按我实际部署的顺序走一遍，适合刚接触 GIS 开发、需要在 Windows 或 Linux 上把 GDAL 跑起来的人，也适合装过但被 PROJ 和 SQLITE3 折腾过的老手对照排查。

2. 装之前先对账：GDAL、PROJ、SQLITE3 的版本与依赖关系

2.1 三个组件到底谁依赖谁

很多人以为 GDAL 是一个独立工具，装完就能用。实际上 GDAL 是一个胶水层，它自己不实现坐标转换，也不自己实现空间数据的底层存储。坐标转换靠 PROJ，矢量数据的 SQLite 驱动靠 SQLITE3。三者的依赖关系是：GDAL 编译时链接 PROJ 和 SQLITE3，运行时动态加载对应的库文件。

这意味着两件事。第一，你机器上如果已经有一个旧版 PROJ，GDAL 可能链接到那个旧版，然后坐标转换结果偏差几十米，你还以为是数据问题。第二，SQLITE3 的版本如果和 GDAL 编译时用的不一致，读 GeoPackage 时会直接报SQLite driver not available，而不是给你一个温和的警告。

我一般会在解压后先做一次版本对账，确认压缩包里的三个组件是配套的。常见做法是看压缩包内的目录结构，通常会有bin、lib、include、share四个目录，share下面放的是 PROJ 的数据库文件proj.db。

2.2 版本对照表与目录结构

下面这张表是我从这份 release 包里实际看到的目录布局，不同构建方式可能略有差异，但核心文件位置一致：

提示：如果你拿到的包里没有share/proj.db，那 PROJ 一定跑不起来。这个文件不是可选的，它是 PROJ 6 以后所有坐标转换的数据源。

2.3 环境变量该设哪几个

在 Windows 上，我一般会设三个环境变量。第一个是PATH，把bin目录加进去，让命令行能找到 gdalinfo 和 proj。第二个是PROJ_LIB，指向share目录，让 PROJ 能找到 proj.db。第三个是GDAL_DATA，指向share/gdal，让 GDAL 能找到坐标系统和基准面的定义文件。

在 Linux 上，除了PATH，还需要设LD_LIBRARY_PATH指向lib目录，否则运行时会报找不到 libgdal.so。PROJ_LIB和GDAL_DATA同样要设。

# Linux 下设置环境变量，写入 ~/.bashrc 或 ~/.profile export PATH=/opt/gdal-build/bin:$PATH export LD_LIBRARY_PATH=/opt/gdal-build/lib:$LD_LIBRARY_PATH export PROJ_LIB=/opt/gdal-build/share export GDAL_DATA=/opt/gdal-build/share/gdal

这段配置的逻辑是：PATH决定命令能不能被找到，LD_LIBRARY_PATH决定动态库能不能被加载，PROJ_LIB和GDAL_DATA决定运行时数据文件能不能被定位。四个变量缺一个，对应的功能就会静默失效或直接报错。参数里的路径要换成你实际解压的目录，不要照抄。

3. 解压与部署：把 GDAL_BUILD(release).rar 落到正确的位置

3.1 解压位置的选择

我不建议把 GDAL 解压到桌面或者带中文和空格的路径下。血泪经验是，GDAL 的某些工具在处理路径时对空格和中文支持不好，尤其是调用 PROJ 做批量转换的时候，路径里有空格会导致参数解析错位。我一般会解压到一个短路径下，Windows 用C:\gdal，Linux 用/opt/gdal。

解压命令本身不复杂，但要注意保留目录结构。Windows 上用 7-Zip 或 WinRAR 解压时，确认勾选了“保留完整路径”。Linux 上用 unrar 或 7z 解压：

# Linux 下解压 rar 包到指定目录 mkdir -p /opt/gdal unrar x GDAL_BUILD\(release\).rar /opt/gdal/ # 如果没有 unrar，可以用 7z 7z x GDAL_BUILD\(release\).rar -o/opt/gdal/

解压完成后，先别急着设环境变量，用ls或dir确认一下目录结构是否完整。重点看bin、lib、share三个目录是否存在，share下面有没有proj.db。

3.2 Windows 下的部署步骤

Windows 下我一般会把解压后的目录放到C:\gdal，然后通过系统属性里的“环境变量”来配置。具体步骤是：右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 在“系统变量”里新建或编辑。

PATH里追加C:\gdal\bin。PROJ_LIB新建，值为C:\gdal\share。GDAL_DATA新建，值为C:\gdal\share\gdal。

设完之后一定要重新打开一个命令行窗口，因为环境变量只在新的进程里生效。然后在命令行里跑gdalinfo --version和proj，看能不能正常输出版本信息。

# Windows CMD 下验证环境变量是否生效 echo %PROJ_LIB% echo %GDAL_DATA% gdalinfo --version proj

如果echo %PROJ_LIB%输出的是%PROJ_LIB%本身，说明变量没设成功，检查是不是设到了“用户变量”而当前命令行是以管理员身份运行的。这种权限隔离导致的变量不生效，我踩过不止一次。

3.3 Linux 下的部署步骤

Linux 下我习惯把环境变量写进/etc/profile.d/gdal.sh，这样对所有用户生效，也方便以后迁移。文件内容就是前面那四行 export。写完记得source /etc/profile.d/gdal.sh或者重新登录。

# 创建全局环境变量文件 sudo tee /etc/profile.d/gdal.sh << 'EOF' export PATH=/opt/gdal/bin:$PATH export LD_LIBRARY_PATH=/opt/gdal/lib:$LD_LIBRARY_PATH export PROJ_LIB=/opt/gdal/share export GDAL_DATA=/opt/gdal/share/gdal EOF # 立即生效 source /etc/profile.d/gdal.sh

这里用tee而不是直接echo >>，是因为tee配合 heredoc 可以一次性写入多行，避免多次追加时把引号搞乱。LD_LIBRARY_PATH放在PATH后面追加，是为了不覆盖系统已有的库路径。

3.4 验证动态库链接是否正常

部署完最容易被忽略的一步是验证动态库链接。Linux 下用ldd看 gdal 的可执行文件链接到了哪些库：

# 检查 gdalinfo 的动态库依赖 ldd /opt/gdal/bin/gdalinfo | grep -E "gdal|proj|sqlite"

正常输出应该能看到libgdal.so、libproj.so、libsqlite3.so都指向你解压目录下的lib。如果某个库显示not found，说明LD_LIBRARY_PATH没设对，或者那个库文件在解压时丢失了。Windows 下可以用 Dependency Walker 或者dumpbin /dependents来看，但更简单的办法是直接跑gdalinfo --version，如果缺库会直接弹窗报错。

4. 配置 PROJ 与 SQLITE3：让坐标转换和 GeoPackage 真正可用

4.1 PROJ 的 proj.db 与网络资源

PROJ 6 以后，坐标转换的所有参数都存在proj.db这个 SQLite 数据库里。GDAL 调用 PROJ 做转换时，PROJ 会去PROJ_LIB指向的目录找proj.db。如果找不到，报错信息通常是proj_create: Cannot find proj.db。

我一般会先确认proj.db的存在和可读性：

# 确认 proj.db 存在且可读 ls -lh /opt/gdal/share/proj.db # 用 sqlite3 查看 proj.db 里的坐标系统数量 sqlite3 /opt/gdal/share/proj.db "SELECT COUNT(*) FROM crs_view;"

第二条命令如果输出了一个数字，说明proj.db是完整的，SQLITE3 也能正常工作。如果报unable to open database file，检查路径和权限。如果报no such table，说明proj.db版本和 PROJ 库版本不匹配，这种情况只能换配套的包。

注意：有些构建包会把proj.db放在share/proj子目录下，而不是直接放在share下。这时候PROJ_LIB要指向share/proj，而不是share。我遇到过两次，每次都要愣一下才想起来。

4.2 SQLITE3 驱动的加载与 GeoPackage 支持

GDAL 读 GeoPackage 依赖 SQLITE3 驱动。验证方法是找一个.gpkg文件，跑ogrinfo：

# 查看 GeoPackage 文件的图层信息 ogrinfo -so test.gpkg

如果报Unable to open datasource，先确认文件路径对不对，再确认 GDAL 编译时是否包含了 SQLite 驱动。可以用ogrinfo --formats来看支持的格式列表里有没有GPKG：

# 列出 GDAL 支持的所有矢量格式，过滤 GeoPackage ogrinfo --formats | grep -i gpkg

正常应该输出GPKG -raster,vector- (rw+vs): GeoPackage。如果没有这一行，说明这份 GDAL 构建时没有链接 SQLITE3，或者 SQLITE3 库版本不兼容。这种情况下，GeoPackage 相关的功能全部不可用，只能换一个包含 SQLite 驱动的构建包。

4.3 坐标转换的实测

配置完 PROJ 之后，我一般会用cs2cs做一次实测，把 WGS84 经纬度转成 Web Mercator：

# WGS84 转 Web Mercator (EPSG:3857) echo "116.397 39.909" | cs2cs +proj=longlat +datum=WGS84 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs

输出应该是两个以米为单位的坐标值。如果报proj_create: Cannot find proj.db，回到 4.1 检查PROJ_LIB。如果输出的是* * inf，说明转换参数有问题，通常是+nadgrids=@null这个参数没加，导致 PROJ 去找网格文件但找不到。

这个命令里的参数含义：+proj=longlat +datum=WGS84是源坐标系，+to后面是目标坐标系，+proj=merc表示墨卡托投影，+a和+b是椭球长半轴和短半轴，+lat_ts=0是标准纬线，+lon_0=0是中央经线，+x_0和+y_0是假东假北，+units=m是单位米，+nadgrids=@null表示不使用网格文件。

5. 避坑与排查：GDAL 环境搭建中最容易翻车的五个点

5.1 现象：gdalinfo 能跑，但 Python 里 import gdal 报错

原因：命令行工具和 Python 绑定走的是两套加载逻辑。命令行工具靠PATH和LD_LIBRARY_PATH，Python 的 GDAL 包靠PYTHONPATH和GDAL_LIBRARY_PATH。如果只配了命令行环境，Python 里找不到_gdal这个 C 扩展。

解决：确认 Python 的 GDAL 包版本和这份构建包的 GDAL 版本一致。然后在 Python 里显式指定库路径：

# 在 Python 里手动指定 GDAL 库路径 import os os.environ['GDAL_LIBRARY_PATH'] = r'C:\gdal\lib\gdal.dll' os.environ['PROJ_LIB'] = r'C:\gdal\share' from osgeo import gdal print(gdal.__version__)

如果还是报错，检查 Python 的位数和 GDAL 库的位数是否一致。32 位的 Python 加载不了 64 位的 gdal.dll，这个坑我见过太多次。

5.2 现象：坐标转换结果偏差几百米

原因：PROJ 找到了一个旧版的proj.db，而不是这份构建包里的。常见于机器上之前装过其他 GIS 软件，环境变量里残留了旧的PROJ_LIB指向。

解决：在命令行里echo $PROJ_LIB或echo %PROJ_LIB%，确认指向的是这份构建包的share目录。如果指向别处，把旧的变量删掉或者覆盖掉。Linux 下可以用which proj看实际调用的是哪个 proj。

5.3 现象：ogrinfo 读 GeoPackage 报 SQLite 错误

原因：SQLITE3 的动态库版本和 GDAL 编译时用的不一致。常见于系统里已经有一个 libsqlite3.so，LD_LIBRARY_PATH的优先级不够高，导致加载了系统版本。

解决：把这份构建包的lib目录放在LD_LIBRARY_PATH的最前面，确保优先加载自带的 SQLITE3。或者用ldd确认 gdal 实际链接的是哪个 sqlite3。

# 确认 gdal 实际加载的 sqlite3 路径 ldd /opt/gdal/bin/ogrinfo | grep sqlite

5.4 现象：Windows 下命令行能跑，但 QGIS 或 ArcGIS 里调用失败

原因：这些桌面软件有自己的环境变量加载机制，不会继承你命令行里设的PROJ_LIB和GDAL_DATA。它们通常会在自己的安装目录下找 PROJ 和 GDAL。

解决：如果要在桌面软件里用这份构建包，需要把share/proj.db和share/gdal复制到桌面软件对应的目录下，或者通过软件自己的设置界面指定路径。我一般不建议混用，桌面软件自带的 GDAL 通常已经配好了，除非版本太旧需要升级。

5.5 现象：解压后 bin 目录里没有 exe 文件

原因：有些 rar 包在压缩时把可执行文件放在了子目录里，或者压缩格式导致解压时丢失了文件属性。Linux 下还可能是解压后没有执行权限。

解决：先确认压缩包完整性，重新解压一次。Linux 下给 bin 目录下的文件加执行权限：

# 给 bin 目录下所有文件加执行权限 chmod +x /opt/gdal/bin/*

如果解压后确实没有 exe，那可能是这份构建包只包含了库文件，没有包含命令行工具。这种情况需要找包含完整工具的构建包。

6. 装完怎么验证：三条命令确认 GDAL 环境真正跑通

装完环境最怕的是“看起来能跑，实际一用就废”。我一般会走三条验证命令，从版本、坐标转换、数据读取三个层面确认环境是活的。

第一条，确认版本和编译信息：

gdalinfo --version gdalinfo --format GPKG

第一条输出 GDAL 版本号，第二条输出 GeoPackage 驱动的详细信息。如果第二条报Unable to find format，说明 SQLite 驱动没编译进去，前面 4.2 的检查要重做。

第二条，确认 PROJ 坐标转换链路：

echo "116.397 39.909" | cs2cs +proj=longlat +datum=WGS84 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs

输出两个数值，大约在12950000和4800000附近。如果输出* * inf或者报错，回到第 4 章检查PROJ_LIB和proj.db。

第三条，确认 SQLite3 和 GeoPackage 的实际读写：

# 创建一个测试用的 GeoPackage ogr2ogr -f GPKG test.gpkg /opt/gdal/share/gdal/point.geojson # 读回来看图层信息 ogrinfo -so test.gpkg

如果ogr2ogr报Unable to open datasource，说明 SQLite3 驱动有问题。如果创建成功但ogrinfo读不出来，检查文件权限和路径。

这三条命令走完，基本能覆盖 GDAL、PROJ、SQLITE3 三个组件的核心功能。我自己的习惯是，每次在新机器上部署完，这三条命令必须全绿才继续往下做项目。有一次偷懒只跑了gdalinfo --version就开始处理数据，结果批量转换到一半才发现 PROJ 的proj.db指向了一个旧版本，几百个文件的坐标全偏了，只能删掉重来。从那以后我每次部署完都强制走一遍这三条验证，不再省这一步。希望帮到你。

本文还有配套的精品资源，点击获取