把道路、管线、资产点或 AI 提取的要素放入数字孪生，不能只看它们能否在三维场景出现。二维瓦片和 GeoJSON 在平面地图中足够时，强行三维化只会增加复杂度；但需要真实高程、跨层级流式加载和按要素查询时，矢量数据必须有新的空间、属性与分块契约。Cesium 对 3D Tiles 矢量支持的提案给出了一条可验证的迁移路径。

数据口径与可核验事实

Cesium 于 2026 年 6 月 29 日说明正为 3D Tiles 2.0 增加原生三维矢量点、线和面支持。该团队调研了 MVT、MapLibre Tiles 和 GeoJSON 等已有生态；它同时认为不少二维或 2.5D 情景仍适合继续使用 GeoJSON 与 MVT。提案中的 3D 需求包括点线面、三维坐标及对二维和 2.5D 的兼容、逐要素属性查询与样式、实时流式与 LOD，以及不以地球为参考的坐标和四叉树、八叉树、k-d tree、DGGS 等灵活分块方式。

该提案计划以 glTF 高效编码点线面，可选 Meshopt 和 Gzip 压缩；3DTILES_content_gltf_vector 识别矢量 tile 内容，KHR_mesh_primitive_restart 用于线和面拓扑，EXT_mesh_polygon 保留面拓扑及运行时三角化。Feature ID、属性和元数据将借助 EXT_mesh_features 与 EXT_structural_metadata。初始切片输入是 GeoJSON，Cesium ion 与自托管服务均在计划路径内；CesiumJS、Cesium for Unreal 已开始运行时实现，Mapbox Vector Tiles 也开始在 CesiumJS 中复用同一渲染管线。

核心机制

三维矢量切片的目的不是把每个 GeoJSON 要素变成三角网，而是把几何、语义属性和层级调度分开保留。坐标定义决定道路是贴地、架空还是地下；Feature ID 让查询和业务属性能回到原始要素；LOD 和分块决定大范围加载时客户端看到什么。缺任一项，三维显示都难以进入量测、巡检或资产分析流程。

GIS 应用场景与技术路径

先从一小块可回放 AOI 做迁移。冻结 GeoJSON 输入、坐标参考、高程基准、属性字典与许可；分别验证点、线、面要素数、关键属性、Feature ID 和几何范围。然后在近中远视距检查 LOD 切换、查询、样式、内存和加载时间。若场景只需要平面浏览，应保留 MVT/GeoJSON 路径；若要与 reality mesh、点云、BIM 或 AI 提取高程要素在真实三维空间中叠加，再进入 3D Tiles 试点。

风险与局限

这是一项正在形成的规范和实现路线，路线图与支持格式会随反馈演变。GPU 压缩、运行时三角化和 LOD 优化不保证源数据坐标、拓扑或属性正确；二维可视化同样不能因此被视为过时。生产部署前需分别验证标准版本、工具链、客户端版本、许可和性能。

检查清单

  • 是否记录输入 GeoJSON、CRS、高程基准、属性字典与版本？
  • 点线面、Feature ID、关键属性和几何范围是否可回读？
  • 是否分开验证二维/2.5D 与真正三维的业务需求？
  • LOD、查询、样式和性能是否在目标设备与网络下复测？
  • 是否保留从输入到 tileset 的参数、日志和回退路径？

结论

矢量进入 3D Tiles 的门槛是可追溯的空间语义与分块行为，不是一次成功渲染。先让坐标、属性、Feature ID 和 LOD 通过样本验收，GIS 团队才适合把大规模矢量交给三维流式服务。

资料来源