★ FEATURED ARTICLE 简介这份资源面向需要在 Java 环境中处理地理空间数据的开发者定位为开箱即用的 GDAL 3.8.5 与 MapServer 8.0.1 的 x64 集成包可解决 Java 读取、解析、转换 TIFF 等栅格数据时依赖配置繁琐、原生库与绑定版本不匹配的问题适合已具备一定 GIS 基础、正在做地图服务或遥感数据处理的中级开发者。压缩包共 608 个文件约 57.98MB以 101 个 dll 与 83 个 exe 提供 GDAL、PROJ、MapServer 及各类格式驱动的运行库和命令行工具119 个 py 与 69 个 pyc 为配套 Python 脚本另有 4 个 jar 与 7 个 pyd 支撑 Java、Python 绑定74 个 csv 与 9 个 xsd 则是坐标系统、s57 要素等字典和校验文件。包内还附带 ECW、HDF4/5、FileGDB、NetCDF、MrSID、SZIP 等格式的许可说明便于确认商用与分发合规边界SDKShell.bat 可快速进入命令行环境验证驱动是否可用。目前已有 347 人学习下载可作为 Java 侧栅格解析与 Web 地图服务搭建的现成底座。1. 一次双击就失败的整合包上周帮某开发团队处理一个出图任务原有服务换成 MapServer还要先批量处理一批影像。负责人为了省事下载了 release-1928-x64-gdal-3-8-5-mapserver-8-0-1 这个整合包解压后双击 mapserv.exe窗口一闪就没了再敲 gdalinfo报找不到 proj.db坐标系全部变成 unknown。这套 GDAL 3.8.5 MapServer 8.0.1 的 x64 组合在 GIS 服务端极常见GDAL 负责裁剪、重投影、切瓦片MapServer 负责 WMS/WFS 发布Java 后端再通过 HTTP 把图取回业务页面。但它对目录结构、环境变量、Mapfile 的 CONFIG 块比老版本筛选得更严格——路径带空格、PROJ 数据目录没指、MS_MAP_PATTERN 没配任何一处都能让服务起不来。这篇笔记按实际安装顺序写一遍从解压到出第一张图中途失败的地方都留下记录。2. 环境准备x64 release 包的目录结构与环境变量清单动手之前先花十分钟确认环境。这类 Windows x64 整合包在构建时会把 GDAL、PROJ、GEOS、MapServer 的 exe 和 dll 全塞进同一个 bin好处是不用自己配依赖坏处是整个包只能放在一个固定路径上安装机器只要与该路径设置稍有冲突就会异常失败。相比 Linux 上用 conda 或 apt 分装的零散配置整合包减少依赖问题但引入路径约束。以下几点对这两类方案都成立。2.1 装机前先确认的三件事检查项要求常见出错点操作系统Windows x64建议 Server 2019 及以上或 Win10 21H2 以上32 位系统装 x64 包dll 全部加载失败运行库Visual C 2015-2022 Redistributable (x64)缺 vcruntime140_1.dll双击无任何提示解压路径全英文、无空格、无中文、非桌面/下载目录C:\Users\张三\Desktop\新建文件夹直接失败权限解压目录对服务账号可读可执行用 SYSTEM 跑 CGI目录只给了当前用户权限磁盘预留 4 GB 以上切瓦片时临时文件写满路径这条不是多余提醒而是最容易忽略的一点。GDAL 和 MapServer 内部有大量字符串拼接早期某些插件对空格和中文路径处理很脆弱.tif放中文目录里 gdalinfo 能读、MapServer 读不到的情况我见过不止一次。常见做法是把整个包固定解压到D:\gis\release-1928-x64之后所有配置都按这个根路径写不要中途移动——移动之后环境变量、Mapfile、Java 侧硬编码路径会同时失效。2.2 解压后先别双击目录里到底有什么把包解开第一件事是打开 bin 目录看看里面有什么这决定了后面怎么写配置。bin\gdal*.exe、mapserv.exe、projinfo.exe、各种 dll。必须进 PATHshare\gdal\gdalvrt.xsd、data\里的坐标系定义、驱动元数据。对应 GDAL_DATAshare\proj\proj.db就放在这里。对应 PROJ_LIB / PROJ_DATAshare\mapserver\或apps\示例 mapfile、字体列表 fonts.txtplugins\可选GDAL 的插件式驱动如部分数据库驱动需要时才配GDAL_DRIVER_PATH判断一个整合包是否完整有个不用启动服务的方法看share\proj\proj.db是否存在且体积正常几 MB 级别。proj.db缺失所有 EPSG 代码解析都会失败gdalinfo 输出里坐标参考系一栏是unknownMapServer 出图时投影变换直接报错。这是整合包最常被处理掉的文件之一被删除后很难从其他包补齐只能整体重新解压。2.3 三个必须设的环境变量以管理员身份打开 PowerShell按下面的脚本一次设完。注意SetEnvironmentVariable写的是 Machine 级当前已开的终端不会生效要新开窗口。$root D:\gis\release-1928-x64 # 1) PATH 追加 bin重复执行前先判断避免写重复项把 PATH 撑爆 $oldPath [Environment]::GetEnvironmentVariable(Path, Machine) if ($oldPath -notlike *$root\bin*) { [Environment]::SetEnvironmentVariable(Path, $oldPath;$root\bin, Machine) } # 2) GDAL 的辅助数据目录驱动配置和坐标系 WKT 都从这里读 [Environment]::SetEnvironmentVariable(GDAL_DATA, $root\share\gdal, Machine) # 3) PROJ 的 proj.db 目录3.8 同时认 PROJ_DATA 和 PROJ_LIB两个都写保险 [Environment]::SetEnvironmentVariable(PROJ_LIB, $root\share\proj, Machine) [Environment]::SetEnvironmentVariable(PROJ_DATA, $root\share\proj, Machine)参数说明$root就是解压根目录后面所有脚本都复用这个变量改路径只改这一行PATH 的判断条件是防止重复执行脚本时把同一条路径写入多次PATH 超过上限后系统行为会变得异常这属于典型的“越修越坏”GDAL_DATA只影响驱动与坐标系描述不影响数据本身指错了会在 gdalinfo 里看到一堆Unable to open ... .csv的警告PROJ_LIB和PROJ_DATA在 PROJ 9 之后有更名历史整合包内置的版本可能只认其中一个两个都设是最省心的做法。2.4 三条自检命令确认这不是个不完整的包环境变量设完新开一个命令行窗口挨个执行:: 版本号必须和标题里的 3.8.5 对上 gdalinfo --version :: 输出一段 PROJ 字符串能出结果说明 proj.db 正常 projinfo EPSG:4326 -o PROJ :: 列出 MapServer 版本与编译时启用的输入格式 mapserv -vgdalinfo --version输出GDAL 3.8.5, released ...才算对。如果输出的是别的版本号通常是机器上还装着别的 GIS 软件它的 bin 在 PATH 里排在前面——把本包的 bin 提到最前或者干脆把冲突软件从服务账号的 PATH 里摘掉。projinfo EPSG:4326 -o PROJ是最直接的坐标系数据库体检。输出里应该能看到projlonglat datumWGS84。如果报proj_create: no database context specified就是PROJ_LIB没指对或者proj.db被删了。mapserv -v正常会输出类似MapServer version 8.0.1 ...下面跟着一串INPUT格式列表重点看有没有GDAL、TIFF、PNG。没有 GDAL 这一项说明包是不带 GDAL 支持的简化构建后面的栅格图层全发布不了。三条命令都通环境这一关就算过了。任何一条报错先解决它再往下走不要抱着“先装完再说”的心态——后面 Mapfile 一报错你就分不清是环境问题还是配置问题。3. GDAL 3.8.5 落地从 PATH 到 Java 侧调用GDAL 在这套组合里承担数据预处理的角色实际很少单独跑大多是被 Java 服务或定时任务调用。3.8.5 相对老版本在 COG 驱动、多线程读、PROJ 9 的坐标系上补齐了不少gdal_translate -of COG生成云优化 GeoTIFF 已经是常规操作。这一节按“先在本机跑通、再让 Java 调得动”的顺序推进。3.1 让 gdalinfo 在任意目录跑起来PATH 设好之后随便找个目录验证一次别在自己的工作目录里验证——很多人是在 bin 目录下双击 cmd 测的当然能跑一换目录就露馅。:: 切到一个与安装目录无关的位置随便放个小 tif 或直接用公开的示例数据 cd /d D:\gis\work gdalinfo --formats | findstr /i COG GTiff这条命令列出所有支持COG和GTiff的驱动。--formats的输出里每一行末尾会标注rw读写或ro只读GTiff应该是rw。如果这步正常说明 bin 里的 dll 依赖完整。顺手再确认一下 GDAL 的数据目录有没有被正确加载:: 输出前几行看到大量 driver 元数据就说明 GDAL_DATA 生效了 gdalinfo --format GTiff | more正常应该输出 GTiff 驱动的创建选项、默认压缩等一长串信息。如果只输出一两行Format Details说明GDAL_DATA指向的目录里缺驱动描述文件功能不受影响但会丢掉一部分提示信息。3.2 坐标系解析proj.db 是整个包的关键文件GDAL 3.x 之后坐标系处理全交给 PROJ很多以前“能用”的写法现在会失效。最典型的是initepsg:4326这种老式 PROJ.4 字符串新版本里已经废弃正确用法是EPSG:4326或者完整的 WKT2。验证一下:: 读取影像的坐标系输出里 CRS 一行应该是 EPSG:4326 而不是 unknown gdalinfo D:\gis\work\demo.tif | findstr /i CRS ID AUTHORITY :: 直接做一次重投影输出 PROJ 4 字符串确认 proj.db 里查得到 projinfo EPSG:3857 -o PROJ -q第一行的输出里应该能看到ID[EPSG,4326]这类标识。第二行输出projmerc a6378137 ...。这两条都通说明坐标系库完整可用。这里有个容易忽略的情况如果影像本身没写坐标系gdalinfo 输出里是空的此时不要急着判断proj.db有问题。先用gdal_edit.py -a_srs EPSG:4326 demo.tif补上坐标系再测。区分“数据没带 CRS”和“环境解析不了 CRS”可以省下大量排查时间。3.3 Java 后端怎么接这套 GDAL三种方式与取舍Java 项目直接用 GDAL常见做法有三种按实施成本从低到高排第一种命令行调用。用ProcessBuilder调gdal_translate.exe、gdalwarp.exe最省事退出码就是结果日志直接从输出流读。适合定时批处理、预处理流水线。第二种走 HTTP 交给 MapServer。Java 侧只拼 WMS/WFS 请求不直接接触 GDAL出图和投影由 MapServer 完成。适合在线出图、需要动态样式变化的场景。第三种GDAL Java 绑定。需要自己用 SWIG 编译整合包里通常不带 jar。除非有大量需要复用 GDAL 对象的复杂逻辑否则不建议——编译环境、JNI 路径、dll 位数三样对不上一个就用不了。我一般选第一种代码量最小。示例// 把任意栅格转成 COG供 MapServer 直接读取避免运行时反复解压 public class GdalRunner { private static final String ROOT D:\\gis\\release-1928-x64; private static final String GDAL_TRANSLATE ROOT \\bin\\gdal_translate.exe; public static int toCog(Path src, Path dst) throws IOException, InterruptedException { ProcessBuilder pb new ProcessBuilder( GDAL_TRANSLATE, -of, COG, -co, COMPRESSDEFLATE, // 无损压缩影像类数据首选 -co, OVERVIEWSIGNORE_EXISTING, // 强制重建金字塔避免沿用错误概视图 -co, BIGTIFFIF_SAFER, // 超过 4GB 自动切 BigTIFF src.toString(), dst.toString()); pb.redirectErrorStream(true); // 把 stderr 并到 stdout否则日志会缺一半 // 服务进程的环境变量未必继承系统 PATH关键变量显式注入更稳 pb.environment().put(GDAL_DATA, ROOT \\share\\gdal); pb.environment().put(PROJ_LIB, ROOT \\share\\proj); Process p pb.start(); try (BufferedReader r new BufferedReader( new InputStreamReader(p.getInputStream(), StandardCharsets.UTF_8))) { String line; while ((line r.readLine()) ! null) { System.out.println([gdal] line); } } return p.waitFor(); // 0 才算成功非 0 要按输出内容判断原因 } }逻辑说明ProcessBuilder的第一个参数必须是 exe 的绝对路径不要指望服务进程能找到 PATH——Windows 服务以 SYSTEM 启动时拿到的是另一套环境。redirectErrorStream(true)合并两个流是因为 gdal 的报错基本都走 stderr不合并的话日志里只剩空行。waitFor()返回的是退出码gdal_translate成功返回 0失败返回非 0但失败原因只写在输出里所以一定要把流读完再判断。参数说明-of COG指定输出格式为云优化 GeoTIFF内部是有序瓦片加内嵌概视图MapServer 读取时按需解压比普通 GTiff 快不少COMPRESSDEFLATE是无损压缩影像数据别用JPEG除非能接受有损OVERVIEWSIGNORE_EXISTING在处理二手数据时很有用源文件里可能有分辨率不对的旧金字塔不重建会出现缩放后模糊BIGTIFFIF_SAFER让驱动自己判断超过阈值自动用 BigTIFF不加这个选项处理大影像会在中途报TIFFAppendToStrip错误。3.4 Python 绑定与插件目录可选但值得确认整合包有时附带 Python 绑定有时没有。检查方法很简单:: 有输出说明装了 Python 绑定没有就跳过不影响主体功能 python -c from osgeo import gdal; print(gdal.__version__)如果报ModuleNotFoundError不必强求。批处理逻辑用命令行拼也能写反而是把 Python 环境和 GIS 环境绑在一起以后升级一处要动两处。真需要的话注意 Python 的位数必须和 dll 一致64 位 Python 配 32 位 GDAL 会直接崩这个错误信息非常难懂。GDAL_DRIVER_PATH只在需要额外插件时设置普通 GTiff、PNG、Shapefile 这些内置驱动不需要。设错这个变量会让 GDAL 去一个空目录找驱动反而丢失部分格式支持不确定就别设。4. MapServer 8.0.1 配置CONFIG 块与 MS_MAP_PATTERNGDAL 那部分通了接着装 MapServer。8.0 相比 7.x 最大的变化是安全模型的收紧其中 Mapfile 必须带 CONFIG 块是必须遵守的规则并非建议老项目原地升级 8.0 时最常见的现象就是服务能起、请求全 500。4.1 CGI 部署mapserv.exe 的位置和被调用方式整合包里的mapserv.exe是 CGI 程序不是常驻服务这是新手最容易误解的一点。它由 Web 服务器IIS、Apache、NginxFastCGI在每次请求时拉起一个进程读环境变量和查询串返回图片或 XML然后退出。IIS 下的大致步骤建一个应用目录如D:\gis\www\mapserv把mapserv.exe和它依赖的 dll 一起放进去在 IIS 里给这个目录开“处理程序映射”添加 CGI 模块可执行文件指向mapserv.exe应用程序池的“启用 32 位应用程序”必须设为 False给应用池账号授予该目录的读取和执行权限。:: 先不经过 Web 服务器直接在命令行验证 CGI 能跑 cd /d D:\gis\www\mapserv mapserv -v mapserv QUERY_STRINGmapD:/gis/map/demo.maprequestGetCapabilitiesserviceWMS第二条命令会把 XML 直接输出到控制台。这一步能过、浏览器里过不了问题一定在 Web 服务器那一侧权限、处理程序映射、CGI 超时跟 Mapfile 无关。反过来命令行就报错那先修 Mapfile。提示mapserv不传QUERY_STRING时会输出一段短提示这不是报错只能说明程序本身能启动。4.2 8.0 的安全默认值CONFIG 块不能省MapServer 8.0 引入了加密密钥与路径白名单机制。Mapfile 顶部没有 CONFIG 块时8.0 会直接拒绝加载或者给出警告后按最保守策略执行表现就是所有请求都返回空白图或者msSetErrorString之类的内部错误。MAP # 8.0 必需用于加密连接串没有它加载时会告警 CONFIG MS_ENCRYPTION_KEY a-long-random-string-here # 限制通过 map 参数能访问的路径正则匹配防止任意文件读取 CONFIG MS_MAP_PATTERN ^D:/gis/map/.*$ NAME demo STATUS ON SIZE 800 600 EXTENT -180 -90 180 90 UNITS DD IMAGECOLOR 255 255 255 SHAPEPATH D:/gis/data WEB # 临时文件目录必须存在且服务账号可写 IMAGEPATH D:/gis/tmp/ IMAGEURL /tmp/ METADATA ows_title Demo WMS ows_enable_request * wms_srs EPSG:4326 EPSG:3857 END END PROJECTION initepsg:4326 END LAYER NAME imagery TYPE RASTER STATUS ON DATA demo_cog.tif PROJECTION initepsg:4326 END METADATA wms_title Imagery END END END逻辑说明CONFIG块必须写在 MAP 开头放在其他关键字之后会被忽略MS_ENCRYPTION_KEY只在要用加密连接串时才真正参与运算但 8.0 要求它存在随便给一串固定值即可别用短串MS_MAP_PATTERN是正则匹配的是map参数的完整值注意 Windows 下的盘符和斜杠写法写^D:/gis/map/.*$就只允许这个目录下的 mapfile。参数说明IMAGEPATH是服务端写临时图片的目录必须真实存在且可写很多“返回 500 但日志空白”的情况就是这里没权限IMAGEURL是浏览器能访问的 URL 前缀和IMAGEPATH不一定相同UNITS DD表示地图单位是经纬度如果数据是 Web 墨卡托就改成METERSows_enable_request *放开所有 OGC 请求只在内网或者前面有网关时这么写公网部署应显式列出GetCapabilities GetMap。4.3 第一个可发布的图层指向 GDAL 数据源LAYER里的DATA写相对路径时基准是SHAPEPATH。栅格图层直接指.tif就行MapServer 内部通过 GDAL 驱动读取所以前面 GDAL 那套环境必须先是通的——这也解释了为什么很多人先装 MapServer 后装 GDAL结果图层一直加载失败。验证顺序建议这样先gdalinfo确认 tif 能读、坐标系正确再mapserv命令行跑 GetCapabilities最后才切到浏览器。三层依次通过出问题能立刻定位在哪一层。样式部分栅格图层常用的控制项是BANDS、SCALETOKEN和PROCESSING。后者可以直接把 GDAL 的处理指令透传下去PROCESSING SCALEAUTO PROCESSING RESAMPLEBILINEARSCALEAUTO让 MapServer 按当前视窗的像元统计自动拉伸比手工写死SCALE0,255适应性强RESAMPLEBILINEAR在缩放时做双线性重采样视觉上比最近邻平滑代价是少量 CPU。4.4 Java 侧通过 WMS 取图Java 端只要拼 URL不需要任何 GIS 依赖库// 拼一个 WMS 1.3.0 的 GetMap 请求返回 PNG String base http://gis-host/mapserv?; String url base mapD:/gis/map/demo.map serviceWMSversion1.3.0requestGetMap layersimagerystyles // 1.3.0 中经纬度顺序是 lat,lon与 1.1.1 相反这是最常见的翻车点 crsEPSG:4326bbox30,110,35,115 width1024height1024 formatimage/pngtransparenttrue;参数说明crs在 1.1.1 里叫srs1.3.0 改成crs并且 bbox 顺序变成纬度在前两个版本混用会得到一张南北颠倒的图layers对应 Mapfile 里的LAYER NAME不是NAME属性之外的别的名字transparenttrue需要formatimage/png配合用image/jpeg时这个参数无效。Java 侧拼接 URL 时map的值要做一次 URL 编码尤其是路径里有冒号。有些 HTTP 客户端会自动处理有些不处理表现就是 MapServer 报“Map file path is not allowed”——这时先别怀疑MS_MAP_PATTERN先看一眼实际发出去的请求串。5. 排查五条踩坑记录每条都有代价下面这些坑都是我实际遇到过并花时间修过的。写出来是为了让你遇到同样现象时能直接对应不用从零开始猜。5.1 gdalinfo 报找不到 proj.db现象gdalinfo demo.tif能跑但 CRS 一栏是unknown同时输出proj_create: no database context specified。原因PROJ_LIB或PROJ_DATA没设、设错或者share\proj\proj.db在解压时被漏掉。也见过一种情况机器上装了别的 GIS 软件它注册的同名环境变量覆盖了系统级的设置用户变量的优先级高于系统变量。解决先echo %PROJ_LIB%看当前值再确认该目录下确实有proj.db。如果系统变量对、命令行里读出来不对去“用户变量”里删掉同名项。改完必须新开终端旧窗口读的还是老环境。5.2 mapserv.exe 双击一闪而过现象资源管理器里双击黑窗口闪一下消失什么都没留下。原因这不是故障。mapserv是 CGI 程序靠QUERY_STRING环境变量接收参数双击时没有参数处理完空请求就退出了。解决不要用双击测试。在 cmd 里 cd 到目录用mapserv -v或带完整QUERY_STRING的命令验证。真正要确认的是 Web 服务器能不能拉起它那属于 IIS 处理程序映射的问题。5.3 请求返回 500日志里只有一行 Map file path not allowed现象浏览器访问mapserv?map...返回 500MapServer 日志里只有一句路径不被允许。原因MapServer 8.0 的MS_MAP_PATTERN没配或配得太严。默认策略下map指向的路径不在白名单里就会被拒。另一个原因是路径写成了反斜杠D:\gis\map\demo.map正则里按正斜杠写的就匹配不上。解决在 Mapfile 顶部加CONFIG MS_MAP_PATTERN ^D:/gis/map/.*$同时把请求里的路径统一改成正斜杠。正则里的.*别省省了只能匹配目录本身。测试阶段可以把 pattern 放宽到.*先确认链路通通了再收紧。5.4 出图是空白但状态码是 200现象GetMap 返回一张全白的 PNGHTTP 200没有任何错误信息。原因三种可能——EXTENT和数据实际范围不重合LAYER的STATUS是OFFIMAGEPATH目录不存在导致中间文件写不出来某些配置下会静默返回空图。还有一种更隐蔽的PROJECTION写的是数据本身的坐标系但请求的crs与之不同而 MapServer 没有启用重投影直接裁了个空区域。解决先用gdalinfo拿到数据的真实范围和坐标系把EXTENT按它写确认LAYER STATUS ON手动建好IMAGEPATH目录并给写权限请求先用和数据一致的crs测一张通了再换别的坐标系验证重投影链路。5.5 图上中文标注变成方块现象加了标注的图层中文全变成方块或者问号。原因MapServer 依赖字体文件渲染文字默认字体集里通常只有西文字体另外 Mapfile 的编码声明缺失时标注字符串会被按单字节处理。解决把需要的中文字体如某个开源黑体放进包的字体目录在share\mapserver\fonts.txt或包内对应的字体列表文件里加一行FONT 字体别名引用这个别名而不是文件名。同时在MAP或LAYER级别加ENCODING UTF-8。字体列表文件改完要重启 Web 服务器CGI 进程每次新起但字体列表有缓存。6. 装完怎么验证从 GetCapabilities 到一张自己看得懂的图环境跑通、服务起来最后一步是完整验证一遍别只看“没报错”就交付。我习惯按下面这个顺序走四步全过才算装完。步骤命令/操作通过标准1. 环境自检gdalinfo --versionmapserv -v版本号与包一致输入格式里有 GDAL2. 数据自检gdalinfo demo_cog.tif有 CRS、有范围、有波段数3. 服务自检命令行带QUERY_STRING跑 GetCapabilities输出 XMLLayer里有目标图层名4. 出图自检浏览器 GetMap指定一个小 bbox图上能认出地物不是全白也不是全黑第 3 步有个小技巧把 GetCapabilities 的 XML 存成文件用编辑器搜一下图层名。图层没出现在 capabilities 里说明 Mapfile 里的LAYER块根本没被加载——大概率是END少写了一个或者STATUS拼错。这类结构错误mapserv不一定报错只是静默少一层。第 4 步出图之后再回头做一次坐标系交叉验证请求里用EPSG:3857数据是EPSG:4326看输出是否正常变形而不是偏移到海里。这一步能一次性把proj.db、Mapfile 的PROJECTION、请求参数顺序三处问题全暴露出来。:: 最后一条压测式验证连续请求 20 次看是否有偶发失败 for /l %i in (1,1,20) do curl -s -o nul -w %%{http_code} http://gis-host/mapserv?mapD:/gis/map/demo.mapserviceWMSversion1.3.0requestGetMaplayersimagerystylescrsEPSG:4326bbox30,110,35,115width512height512formatimage/png输出应该是一串连续的200。中间夹着500基本就是IMAGEPATH目录的并发写冲突或权限问题把临时目录换成每个应用池独立的一个问题就消失了。从那以后我每次部署这类整合包都强制走一遍“命令行 GetCapabilities → 小图 GetMap → 换坐标系再出一次”的三连不管多急都不跳。跳过这三步省下的十分钟通常会在联调阶段以两小时的形式还回来。这套 GDAL 3.8.5 加 MapServer 8.0.1 的组合本身不难难的是把路径、坐标系、CONFIG 块这些看不见的约束一次性对齐。按上面的顺序走基本能一次装通。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
