83 lines
5.8 KiB
Markdown
83 lines
5.8 KiB
Markdown
# 反演剖面（dd_inversion_data）竖向字段 y / z / elevation 语义待业务确认
|
||
|
||
- 日期：2026-06-16
|
||
- 背景：桌面客户端在 3D 视图里把 ERT 反演剖面（`dd_inversion_data`）渲染成**竖直帘面**。水平方向已用 `lat/lon` 摆到真实测线位置（弯曲测线渲染为曲面，已验证）。**竖直方向用哪个字段、如何定位，目前不确定**，需业务/数据方确认。
|
||
- 数据来源：线上 `GET /business/dd/ert/inversion/rows/{dsObjectId}`。
|
||
|
||
---
|
||
|
||
## 1. 接口返回的竖向相关字段
|
||
|
||
`dd/ert/inversion/rows` 的 `data` 含：
|
||
- `x`：长度 `nx`，水平轴（距离？）。
|
||
- `y`：长度 `ny`，竖直轴（含义不明，见下）。
|
||
- `v`：`[ny][nx]` 电阻率值矩阵（不规则区大量 `null`）。
|
||
- `z`：`[ny][nx]`，逐格一个数（含义不明）。
|
||
- `elevation`：长度 `nx`，疑似每列地表高程。
|
||
- `lat` / `lon`：长度 `nx`，每列经纬度（已用于水平定位）。
|
||
- `vmin` / `vmax`、`sectionType` 等。
|
||
|
||
---
|
||
|
||
## 2. 核心问题：y / z / elevation 的范围与关系**跨数据集不一致**
|
||
|
||
抽样 4 条真实 `dd_inversion_data`（**全部 `sectionType=1`**，即不是"剖面类型不同"导致）：
|
||
|
||
| 数据集 | 项目 | x 范围 | **y 范围** | **z 范围** | **elevation 范围** | z/v 空值 |
|
||
|---|---|---|---|---|---|---|
|
||
| T251230002-M-2 | 地大华睿演示 | [200.0, 437.7] | **[-35.1, -1.1]** | [-101.5, -0.09] | [-35.0, -34.1] | 0 |
|
||
| T120526003-3 | 香港威立雅 | [2.9, 74.6] | **[13.1, 26.2]** | [2.1, 15.4] | [41.6, 51.0] | 1618/1900 |
|
||
| ERT1-WS | 演示（高密度+瞬变） | [0.2, 75.7] | **[9.8, 26.7]** | [0.1, 15.4] | [36.1, 37.9] | 14911/90000 |
|
||
| ert2-ws | 射洪垃圾填埋场 | [0.04, 235.4] | **[287.6, 353.4]** | [-10.1, -0.03] | [287.8, 292.8] | 0 |
|
||
|
||
**观察到的矛盾：**
|
||
1. `y` 的范围毫无统一规律：有负（-35~-1）、有小正（9~27）、有大正（287~353）。无法判断它是"深度（向下为正）"、"相对层号"、还是"绝对高程"。
|
||
2. `z` 同样无规律：有深负（-101.5）、有小正（0~15）、有小负（-10）。
|
||
3. `elevation` 看起来最像"地表高程"（随项目所在地不同：-34 / 41~51 / 36 / 288~293），但与 `y`、`z` 的换算关系**对不上**（例：射洪 `y`≈`elevation`≈287~353，而地大 `y`=-35~-1 远小于 `elevation`=-34）。
|
||
4. `z` 的空值数恰好等于 `v` 的空值数 → `z` 随"有无数据"分布（像是逐格的某个量）。
|
||
|
||
> 结论：仅凭数据无法可靠推断竖向模型，且**不同数据集疑似采用了不同的竖向约定/基准**（可能与上传来源/格式有关）。
|
||
|
||
---
|
||
|
||
## 3. 客户端做法演变
|
||
|
||
- **早期（已废弃）**：竖直 Z = `-y[j]`（把 `y` 当"深度向下"），平顶、不随地表。加真实地形底图后暴露问题：剖面整体沉到地下。
|
||
- **当前（2026-06-17）**：竖直 Z = `+y[j]`（把 `y` 当**真实高程**），与同样按真实高程渲染的地形底图同系对齐 → 剖面顶≈地表、露出地面（复刻原版观感）。详见 §6。
|
||
- 仍**未使用 `z` 和 `alt/elevation`**。
|
||
|
||
---
|
||
|
||
## 4. 请业务/数据方确认的问题
|
||
|
||
1. **`y` 是什么？** 深度（向下为正/为负？）、相对层号、还是绝对高程？为何不同数据集范围差异巨大（-35~-1 vs 287~353）？是否存在多套竖向基准？
|
||
2. **`z`（`[ny][nx]`）是什么？** 逐格的真实高程？深度？还是别的量（如反演网格的实际竖向坐标/褶皱面）？
|
||
3. **`elevation`（`[nx]`）是什么？** 每列地表高程吗？单位、基准（海拔/相对）？
|
||
4. **3D 剖面竖向应如何定位？**
|
||
- (A) 维持现状：平顶"距离×深度"面（与 2D 详情一致）；或
|
||
- (B) 跟随地表起伏：顶面按 `elevation`/`z` 摆到真实高程、随地形上下。
|
||
若选 (B)，请给出**用哪个字段、如何换算**（Z = ?(y, z, elevation)）。
|
||
5. **垂向单位与方向**：米？向上为正还是向下为正？
|
||
6. **不同数据集的竖向差异**是数据本身的真实差异，还是上传/解析造成的不一致（需后端修正）？
|
||
|
||
---
|
||
|
||
## 5. 影响
|
||
|
||
- 现状 (A) 已能正确渲染（与 2D 详情一致），可继续使用。
|
||
- 若业务要 (B) 地形跟随，需上面第 2/3/4 项的明确定义后，客户端按真实竖向模型实现（避免凭猜测导致渲染错误）。
|
||
|
||
---
|
||
|
||
## 6. 进展（2026-06-17）：原版 web 代码已部分解答，但仍有跨数据集风险
|
||
|
||
拿到原版 `commercial-admin` 代码（`dataView/threeMap/threeMap.vue` `addEntityToMap`）后确认其做法：
|
||
- **`data.y` = 真实高程**（不是深度）。原版 `originY = data.y[0]`、`localY = data.y - originY`（相对形状），剖面世界 Z = `originY + localY = data.y`，并用 **`alt`（测线每点地表高程）** 算坡度/地表偏移；地形用 Mapbox 真实 DEM。两者同在真实高程系 → 剖面顶≈地表、露出地面。
|
||
- **无垂直夸张**（`scale.y = 1`，真实比例）。
|
||
|
||
**客户端据此已改为 Z = `+y`（§3 当前），与原版完全一致**（实证：`threeMap.vue:676` `position.z = originY + zCorrection`，`originY = data.y[0]`，注释明说"剖面底部对应真实海拔 originY"，网格 `localY = data.y - originY`，`rotateX` 后竖向 = `data.y`）。
|
||
|
||
**原版的 `alt` 仅用于**：水平定位（`geo2pos` 取 `.x/.y`）+ 坡度补偿 `zCorrection`（而对应的 `rotateZ` 在 667 行被注释掉、实际不生效）。**原版并不用 alt 把剖面顶贴地表**——之前文档此处的"alt 贴地表"为臆测，已更正。
|
||
|
||
**⚠️ §2 表中 `y` 跨数据集不一致是数据层面问题，原版同样存在**：原版也按 `data.y` 摆放，对 `y≠真实高程` 的数据集（香港 `T120526003-3` `y`=13~26 而 `elevation`=41~51）一样会整体偏离地表。客户端与原版行为一致，非客户端 bug。若要纠正，属数据/业务侧（统一 `y` 的高程基准），非渲染侧凭 alt 推算。
|