gaozheng
/
geopro
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
geopro/docs/questions/2026-06-17-3D地球改造-现状与约束评估.md

7.2 KiB
Raw Blame History

3D 地球改造：当前实现方式、目标、问题/约束评估

  • 日期：2026-06-17
  • 目的：评估桌面客户端 VTK 三维视图从「平面局部坐标场景」改造为「3D 地球（对齐原版 web）」的可行性、影响范围与约束，供决策是否立项。
  • 说明：纯文字描述，不含代码。结论待 subagent 基于代码实测评审。

1. 原版（web）目标形态（已实地分析）

  • 原版 dataView 用 Three.js 3D 地球（容器 threeMap，单 WebGL canvas；__THREE__ 在，Cesium 加载但 cesium-widget 未用）。
  • 底图瓦片：Mapbox 卫星 XYZ（api.mapbox.com/v4/mapbox.satellite/{z}/{x}/{y}.webp）贴在球面。
  • 反演剖面等数据按真实经纬贴在弯曲球面上（竖直帘面），可从太空旋转/缩放飞到地面。
  • 需求表要求底图为「天地图」（与原版实际用 Mapbox 不一致）；天地图同样有卫星 WMTS（Web Mercator z/x/y），瓦片源可换、不影响"球 vs 平面"这一架构问题。

2. 当前桌面实现方式（文字描述）

渲染技术：桌面用 VTK（非 Three.js / 非 Cesium），是与 web 完全不同的另一套实现。

坐标系：局部切平面（不是地球球面）

  • 用 GeoLocalFrame：等距圆柱（equirectangular）近似，把经纬度投影成以某原点为中心的局部米平面（x=东、y=北，单位米）。这是一个小范围测区的平面近似，不是地心 ECEF 球面坐标。
  • 竖直方向 Z = 深度（向下为负），与经纬无关。
  • 原点最近改为"按首个真实剖面 lat/lon 中心就地重锚"，使局部坐标从 0 附近起。

各组件都建立在这个局部平面坐标系上：

  • 帘面（剖面）：每列经纬经 GeoLocalFrame 投到局部米平面，Z 取深度；整体是局部平面里的一面"墙"。
  • 切片交互：在体素/剖面上沿轴向/任意角度切片，基于局部直角坐标的平面/重采样。
  • 坐标轴：取场景局部包围盒造立方体坐标轴，刻度可反算回经纬度显示。
  • 相机预设：前/后/左/右/上/下 6 向 + Zoom/Fit，都假设局部直角坐标、Z 向上。
  • 拾取/选中：在局部坐标场景里按包围盒/距离判定。
  • 底图（我刚做的）：天地图瓦片平铺成一块平面地面（z=0），在局部坐标系里，不是球。

结论：当前是"以测区为中心的局部平面 3D 场景"，适合近距离审视单个剖面/切片；不是地球。spec 当初有意如此选择（VTK ≠ web 球，且三栏/切片在局部直角系才好实现）。

3. 目标：3D 地球（对齐原版）

  • 整个地球为球面（地心 ECEF / 椭球坐标），可从太空旋转、缩放飞到地面。
  • 卫星瓦片（天地图卫星）贴满球面，随缩放 LOD 加细。
  • 数据（帘面/切片/异常）按真实经纬贴在弯曲球面对应位置。
  • 相机为地球导航（轨道环绕 + 飞向目标），而非 6 向局部预设。

4. 从"局部平面"到"3D 地球"的问题 / 约束（核心）

  1. 坐标系根本改变：局部切平面米 → 地心 ECEF（经纬高→三维笛卡尔球面坐标）。这不是"加个底图"，而是整个 3D 视图的坐标基准更换。

  2. 所有依赖局部坐标的组件都要重做：

    • 帘面定位（局部米 → 球面 ECEF 的竖直面）；
    • 切片几何与重采样（轴向/任意切片在球面坐标下的平面定义变复杂）；
    • 立方体坐标轴（球面上"立方体轴"语义不再适用，需换成经纬网/比例尺）；
    • 6 向相机预设（前/后/左/右/上/下在球面无固定意义，需改地球导航）；
    • 拾取/选中（球面坐标下判定）；
    • 纵向比例（垂向夸张）在球面上的语义与实现。

  3. VTK 无现成"瓦片地球"：Cesium/Three.js 有内建的 LOD 瓦片地球；VTK 没有。要自建：球面几何 + 多级瓦片调度 + 投影贴图 + (大气/光照)，工作量大。

  4. 数值精度：ECEF 坐标量级约 6.4×10⁶ 米，GPU 渲染管线的浮点矩阵在该量级有抖动（jitter）（数据数组本身已用双精度）。标准规避法是"相机相对原点偏移"——而当前的 GeoLocalFrame.reanchor（一切相对数据中心原点渲染）正是这种规避；即局部平面方案天然避开了球面会引入的精度问题（佐证务实方案）。

4b. 【评审补充，最硬的拦路虎】体素/切片基于 vtkImageData（轴对齐规则栅格）：三维体是 vtkImageData（SetOrigin/SetSpacing 轴对齐），切片工具对它重采样。vtkImageData 本质是轴对齐规则网格，无法弯曲贴到球面。这是真 3D 地球最根本的不兼容点，比"切片重采样变复杂"更强。

4c. 【评审补充】地形 actor（TerrainActor）也全程局部系：DEM 顶点经 frame.toLocal 摆放 + 独立 EPSG 重投影/墨卡托纹理坐标，球面化都要重做。

4d. 【评审补充】纵向夸张(VE)散布三处：帘面 SetScale(1,1,ve)、体素烤进 origin/spacing、地形 zScale。球面上"缩放 Z"无单一含义（Z 是径向、方向逐点变），三处都要重定义。

4e. 【评审补充】2D 俯视测线模式（Map2D）：applyTop2D + addSurveyLine 也建在 z=0 局部平面，球面基准下要么单独保留平面投影、要么重新推导。

  1. 小尺度上收益有限：数据都在几百米的小测区；该尺度下地球曲率不可见——"飞到地面的地球"与"局部卫星平面"看到的卫星图基本一致。3D 地球真正多出的是"从太空看全球/转地球"的整体观感与"和原版一致"。

  2. 与既有功能的冲突：本轮已完成的三栏/帘面/切片/坐标轴/相机预设全部基于局部平面；改球面等于把这些重写或重新适配，回归风险高、且 GUI 不可由我自测。

5. 影响范围 / 工作量（定性）

  • 底图本身（瓦片源换天地图）：小。
  • 平面底图 → 局部卫星平面：小（现成 TileBasemap 换源）。
  • 平面场景 → 3D 地球：大重构，触及坐标系 + 帘面/切片/轴/相机/拾取/底图全链，属重新立项分期，不宜并入当前轮次。

6. 决策建议

  • 3D 地球是根本性重构（非底图增量）；本地剖面尺度（几百米）下与"局部卫星平面"视觉收益差异有限；务实方案是"局部天地图卫星平面"，3D 地球如确需"地球观感"则单独立项分期。

7. 评审结论（opus 子代理 · 基于代码实测）

  • §2 当前实现的 7 项描述（局部等距圆柱坐标、帘面/切片/坐标轴/相机/拾取/底图均依赖局部平面）逐条经代码核实，全部准确（与源码逐字吻合）。
  • §4 "球=根本性重构"的判断成立且偏保守——文档低估了耦合面：另需重做 地形 actor、体素 vtkImageData 轴对齐(最硬拦路虎，规则栅格无法贴球)、三处纵向夸张、2D 俯视模式（已补入 §4b–4e）。无任何"夸大耦合"之处。
  • 总体结论 SOUND：3D 地球触及整条 3D 管线根基，非底图增量；局部卫星平面是务实折中；站点尺度曲率视觉可忽略。其中体素/切片基于 vtkImageData 无法弯曲贴球是最强佐证。