桌面 GIS 加入三维地球，不是把二维画布换成更炫的相机。GeoLibre 3.0.0 的发布记录显示，项目开始把 Cesium 作为可选的主渲染引擎，并为它补齐图层、交互、控件和数据格式支持。对于产品团队，这类升级的验收重点应从“能否切到 3D”转成“同一个项目在引擎切换后，数据、样式、范围和用户动作是否保持可解释的一致”。

这次版本改变了哪些能力边界

v3.0.0 于 2026 年 9 月 14 日发布，发布提交带有 GitHub 已验证签名。发布说明列出：Cesium 可成为主渲染引擎；GeoJSON 图层可在 3D globe 渲染；ArcGIS MapServer、WMTS 与影像叠加可在三维地球显示；还加入了原生 I3S、点云与 splat tileset 支持。

三维数据并不只来自单一格式。该版本还列出对 COG、raster PMTiles、MBTiles 和原生瓦片读取器的协议桥接，以及 Cesium ion asset by id 的支持。对项目迁移而言，这意味着图层来源更丰富，也意味着每种来源的坐标系、时间、样式、访问令牌和加载失败方式都可能不同。

交互层同样有实质变化：发布说明提到 Cesium 的要素拾取、弹窗和高亮，游标读数和可移动控件，以及多边形拉伸和真实三维高程。它还加入按要素符号、点图层聚类与批处理、地形剖面和 KML/CZML 动态场景支持。这些功能让二维项目拥有更接近三维数字孪生的表达，但不会自动保证原有筛选、时间滑块和属性联接语义完全一致。

核心机制：能力门控与渲染适配

双引擎的核心机制是把地图操作通过引擎能力层分派：同一份地理信息系统项目可以保留图层、空间分析参数与业务属性，但渲染、拾取、相机、地形和插件由当前引擎执行。能力门控必须在操作前判断支持范围，才能避免二维控件在三维场景静默失效。

双引擎最容易出错的地方

首先是空间范围。二维 Web Mercator 视图与地球相机的边界表达不同，跨反日期线、极区、三维 bbox 和地形遮挡都可能改变“当前视口”的含义。发布记录特意包含 3D bbox 归约和基于共享 helper 的 bounds 修复，说明范围计算不能只靠一次视觉检查。

其次是图层能力。v3.0.0 将插件的引擎支持显式声明，并按活动渲染器控制插件菜单；这提示团队不应让二维专属工具在三维模式里静默失效。应在 UI 中说明不支持、禁用入口或提供等效路径，而不是让用户在执行后才得到空结果。

第三是项目共享。发布说明警告本地文件图层在共享地图中会缺失，并修复了隐藏工具栏时恢复项目 terrain、分享时保留 Time Slider source 等问题。共享链接、离线数据、私有服务和 Cesium token 都要被看作单独的交付条件。

一套最小迁移验收

选择一份包含矢量、栅格、时间维度、弹窗和筛选器的代表项目。在二维与 Cesium 模式分别执行：加载项目、定位同一 AOI、打开相同图层、应用筛选、触发要素拾取、切换时间、导出截图或共享链接。记录每一步的预期和实际，包括可见要素数、属性、镜头范围、错误消息和网络请求。

测试资料应至少覆盖 GeoJSON、一个服务型图层和一个栅格来源。对于三维，增加带高程的面、点云或 3D Tiles；对于共享，使用一份本地文件和一份远程服务，确认系统不会把不可共享来源伪装成可公开项目。若业务用到插件，还应逐个验证声明的引擎能力和降级行为。

检查清单

  1. 引擎切换后，同一 AOI 的图层、筛选、时间与属性是否仍符合业务定义？
  2. 视口、bbox、反日期线和高程场景是否有可复现的边界测试？
  3. 不支持当前渲染器的插件是否被清楚禁用或替代？
  4. 本地文件、令牌服务和在线资产在分享后是否有明确可用性提示？
  5. 每类图层是否至少验证一次加载、拾取、样式、错误处理和性能基线？

结论

GeoLibre 3.0 的价值不只是把 Cesium 接进 GIS，而是把“渲染引擎”变成影响图层、控件、插件与共享链路的产品能力。团队应以同一项目的可见性、交互和数据语义为验收对象，再决定三维模式是否可以进入生产工作流。

参考来源