4.3 KiB
4.3 KiB
反演剖面(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. 客户端当前做法(供确认/纠正)
- 竖直坐标用
y作深度:每个格子 Z =-y[j](深度向下取负),未使用z和elevation。 - 这与二维"数据详情"反演图一致(详情图
ContourPlotItem也只用x、y画"距离 × 深度"矩形,不用z/elevation)。 - 即:3D 帘面 = 二维"距离×深度"剖面立起来 + 沿真实测线(lat/lon)弯曲,平顶、不随地表起伏。
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 项的明确定义后,客户端按真实竖向模型实现(避免凭猜测导致渲染错误)。