geopro/docs/questions/2026-06-17-3D地球改造-现状与约束评估.md

90 lines
7.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 不一致);天地图同样有卫星 WMTSWeb 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. **【评审补充】地形 actorTerrainActor也全程局部系**DEM 顶点经 `frame.toLocal` 摆放 + 独立 EPSG 重投影/墨卡托纹理坐标,球面化都要重做。
4d. **【评审补充】纵向夸张(VE)散布三处**:帘面 `SetScale(1,1,ve)`、体素烤进 origin/spacing、地形 zScale。球面上"缩放 Z"无单一含义Z 是径向、方向逐点变),三处都要重定义。
4e. **【评审补充】2D 俯视测线模式Map2D**`applyTop2D + addSurveyLine` 也建在 z=0 局部平面,球面基准下要么单独保留平面投影、要么重新推导。
5. **小尺度上收益有限**:数据都在几百米的小测区;该尺度下地球曲率不可见——"飞到地面的地球"与"局部卫星平面"看到的卫星图基本一致。3D 地球真正多出的是"从太空看全球/转地球"的整体观感与"和原版一致"。
6. **与既有功能的冲突**:本轮已完成的三栏/帘面/切片/坐标轴/相机预设全部基于局部平面;改球面等于把这些重写或重新适配,回归风险高、且 GUI 不可由我自测。
---
## 5. 影响范围 / 工作量(定性)
- **底图本身**(瓦片源换天地图):小。
- **平面底图 → 局部卫星平面**:小(现成 TileBasemap 换源)。
- **平面场景 → 3D 地球****大重构**,触及坐标系 + 帘面/切片/轴/相机/拾取/底图全链,属重新立项分期,不宜并入当前轮次。
---
## 6. 决策建议
- 3D 地球是**根本性重构**(非底图增量);本地剖面尺度(几百米)下与"局部卫星平面"视觉收益差异有限;务实方案是"局部天地图卫星平面"3D 地球如确需"地球观感"则单独立项分期。
## 7. 评审结论opus 子代理 · 基于代码实测)
- §2 当前实现的 7 项描述(局部等距圆柱坐标、帘面/切片/坐标轴/相机/拾取/底图均依赖局部平面)**逐条经代码核实,全部准确**(与源码逐字吻合)。
- §4 "球=根本性重构"的判断**成立且偏保守**——文档**低估**了耦合面:另需重做 **地形 actor、体素 `vtkImageData` 轴对齐(最硬拦路虎,规则栅格无法贴球)、三处纵向夸张、2D 俯视模式**(已补入 §4b4e。无任何"夸大耦合"之处。
- 总体结论 **SOUND**3D 地球触及整条 3D 管线根基,非底图增量;局部卫星平面是务实折中;站点尺度曲率视觉可忽略。其中**体素/切片基于 vtkImageData 无法弯曲贴球**是最强佐证。