5.8 KiB

Raw Blame History

反演剖面（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

观察到的矛盾：

y 的范围毫无统一规律：有负（-35~-1）、有小正（9~27）、有大正（287~353）。无法判断它是"深度（向下为正）"、"相对层号"、还是"绝对高程"。
z 同样无规律：有深负（-101.5）、有小正（0~15）、有小负（-10）。
elevation 看起来最像"地表高程"（随项目所在地不同：-34 / 41~51 / 36 / 288~293），但与 y、z 的换算关系对不上（例：射洪 y≈elevation≈287~353，而地大 y=-35~-1 远小于 elevation=-34）。
z 的空值数恰好等于 v 的空值数 → z 随"有无数据"分布（像是逐格的某个量）。

结论：仅凭数据无法可靠推断竖向模型，且不同数据集疑似采用了不同的竖向约定/基准（可能与上传来源/格式有关）。

3. 客户端做法演变

早期（已废弃）：竖直 Z = -y[j]（把 y 当"深度向下"），平顶、不随地表。加真实地形底图后暴露问题：剖面整体沉到地下。
当前（2026-06-17）：竖直 Z = +y[j]（把 y 当真实高程），与同样按真实高程渲染的地形底图同系对齐 → 剖面顶≈地表、露出地面（复刻原版观感）。详见 §6。
仍未使用 z 和 alt/elevation。

4. 请业务/数据方确认的问题

y 是什么？ 深度（向下为正/为负？）、相对层号、还是绝对高程？为何不同数据集范围差异巨大（-35~-1 vs 287~353）？是否存在多套竖向基准？
z（[ny][nx]）是什么？ 逐格的真实高程？深度？还是别的量（如反演网格的实际竖向坐标/褶皱面）？
elevation（[nx]）是什么？ 每列地表高程吗？单位、基准（海拔/相对）？
3D 剖面竖向应如何定位？
- (A) 维持现状：平顶"距离×深度"面（与 2D 详情一致）；或
- (B) 跟随地表起伏：顶面按 elevation/z 摆到真实高程、随地形上下。若选 (B)，请给出用哪个字段、如何换算（Z = ?(y, z, elevation)）。
垂向单位与方向：米？向上为正还是向下为正？
不同数据集的竖向差异是数据本身的真实差异，还是上传/解析造成的不一致（需后端修正）？

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 推算。

5.8 KiB Raw Blame History Unescape Escape