Fix D-InSAR pairing payload and center-distance controls

2026-05-10 21:42:24 +08:00
parent 3818f6e03e
commit 6893041a9f
11 changed files with 1089 additions and 44 deletions
@@ -0,0 +1,257 @@
+# Sentinel-1 D-InSAR Gamma / ISCE2 可行性评估
+
+日期：2026-05-10
+
+本文只评估设计，不涉及代码修改。重点回答：在不使用 ENVI + SARscape 核心的前提下，现有 D-InSAR 生产链路是否适合接入 Sentinel-1，Gamma/PyINT 与 ISCE2 两条路线的实际工作量和风险分别是什么。
+
+## 1. 结论
+
+Gamma/PyINT 路线适合优先做 Sentinel-1 D-InSAR。
+
+`D:\Code\PyINT` 中的专家代码对 Sentinel-1 支持比较完整，尤其是 Sentinel-1 TOPS/IW 的 ZIP 导入、精轨下载、burst 选择、TOPS burst 裁剪、ScanSAR/TOPS 配准、差分干涉、解缠、地理编码等流程。它不是只停留在文件名解析层面，而是已经围绕 GAMMA 命令组织了 Sentinel-1 的实际处理脚本。
+
+ISCE2 本身也能处理 Sentinel-1 TOPS 数据，但本项目当前接入的 ISCE2 托管链路是 `lt1_stripmap`，核心是 LT-1 stripmap 的 `stripmapApp.py` 流程，不是 Sentinel-1 TOPS 的 `topsApp.py` 流程。因此 ISCE2 的 Sentinel-1 能力不能直接等价为“当前系统里马上可用”。如果要做，属于新增一个 `s1_tops` 生产 profile，工作量明显大于复用 PyINT/Gamma 的 Sentinel-1 脚本。
+
+推荐顺序：
+
+1. 先做 `s1_gamma_dinsar` profile，复用 `D:\Code\PyINT` 的 Sentinel-1 Gamma 处理路线。
+2. 配对阶段保持轻量，只做同轨、同模式、同方向、同极化、覆盖重叠、时间基线等前置筛选。
+3. 真正的垂直基线、可处理性和失败原因交给 Gamma/PyINT 在 SLC/RSLC 生成后校验和回填。
+4. ISCE2 的 `s1_tops` profile 放到第二阶段，等 Gamma 路线跑通后再做。
+
+## 2. 本项目当前 D-InSAR 引擎状态
+
+### 2.1 PyINT/Gamma 当前是 LT-1 专用接入
+
+本项目现有 PyINT 托管入口主要围绕 `lt1_gamma_dinsar`：
+
+- `.env` 中当前 PyINT/Gamma D-InSAR 配置说明面向 LT-1。
+- `backend/app/services/pyint_engine.py` 当前只接受 `lt1_gamma_dinsar`。
+- `backend/app/pyint_pipeline/run_lt1_pyint_pipeline.py` 是 LT-1 专用 runner。
+- `backend/app/services/pyint_input_assets_service.py` 负责 LT-1 归档、LT-1 精轨和输入资产准备。
+
+这说明当前系统“接入 PyINT”不等于“已经接入 Sentinel-1 PyINT”。要支持 Sentinel-1，合理做法是新增一个 profile，而不是把 LT-1 profile 混改成多卫星逻辑。
+
+### 2.2 ISCE2 当前是 LT-1 stripmap 接入
+
+本项目现有 ISCE2 托管入口主要围绕 `lt1_stripmap`：
+
+- `.env` 中配置的是 `ISCE2_PROFILE=lt1_stripmap`。
+- 当前 pipeline 脚本是 `backend/app/isce2_pipeline/run_lt1_dinsar_pipeline.py`。
+- 当前使用的是 `stripmapApp.py`，不是 Sentinel-1 TOPS 常用的 `topsApp.py`。
+- WSL runtime registry 允许的 ISCE2 profile 目前也是 LT-1 stripmap 方向。
+
+因此，ISCE2 对 Sentinel-1 的支持在算法生态上成立，但在本项目现有托管实现里还没有落地。
+
+## 3. `D:\Code\PyINT` 对 Sentinel-1 的支持证据
+
+`D:\Code\PyINT` 的 README 和用户指南明确把 Sentinel-1 作为支持对象。代码中也存在成套 Sentinel-1 处理脚本：
+
+- `pyint/down2slc_sen.py`
+  Sentinel-1 ZIP 下载数据转 SLC。它会调用 `eof` 获取精轨，并通过 GAMMA 相关脚本读取 TOPS SLC。
+- `pyint/down2slc_sen_all.py`
+  批量发现 `DOWNLOAD/S1*.zip`，按日期调用 Sentinel-1 SLC 生成逻辑。
+- `pyint/slc_sen_cat.py`
+  老版本 Sentinel-1 SLC 导入与拼接逻辑，说明 PyINT 对多 swath / 多 burst / 多文件拼接有历史支持。
+- `pyint/extract_s1_bursts.py`
+  基于 master/slave 的 burst 参数，裁剪共同 burst 区间。
+- `pyint/coreg_s1_gamma.py`
+  使用 GAMMA `ScanSAR_coreg.py` 做 Sentinel-1 TOPS/ScanSAR 配准。
+- `pyint/raw2ifg_s1.py`
+  Sentinel-1 单对 D-InSAR 的一站式流程：下载数据转 SLC、burst 提取、DEM、配准、差分干涉、解缠、地理编码。
+- `pyint/select_pairs.py`
+  基于 GAMMA `base_calc` 计算基线并按 `max_tb`、`max_sb` 等约束选网。
+
+这批脚本说明 PyINT 的 Sentinel-1 支持不是临时拼出来的文件名适配，而是围绕 GAMMA Sentinel-1 TOPS 处理能力组织出的完整流程。
+
+## 4. Gamma/PyINT 接入方案
+
+### 4.1 新增 profile
+
+建议新增独立 profile：
+
+```text
+s1_gamma_dinsar
+```
+
+不要复用或扩展 `lt1_gamma_dinsar` 的内部假设。两者输入资产、轨道文件、SLC 生成方式、配准方式和模板字段都不同。
+
+最小改造对象：
+
+- 新增 Sentinel-1 输入资产准备逻辑。
+- 新增 Sentinel-1 PyINT runner，例如 `run_s1_pyint_pipeline.py`。
+- 生产引擎 registry 增加 `s1_gamma_dinsar`。
+- 任务 preflight 增加 Sentinel-1 ZIP、EOF、GAMMA 命令、模板字段检查。
+- 输出 catalog 增加 Sentinel-1 结果归档映射。
+
+### 4.2 输入数据约定
+
+PyINT 现有 Sentinel-1 脚本默认从：
+
+```text
+$SCRATCHDIR/<project>/DOWNLOAD/S1*.zip
+```
+
+发现数据。
+
+因此最省事、风险最低的约定是：系统管理 Sentinel-1 时尽量保留原始 `.zip` 产品，并在生产分发时把 master/slave 的 ZIP 放入 PyINT 项目的 `DOWNLOAD` 目录。
+
+如果数据池里只有解压后的 `.SAFE` 目录，当前 PyINT 脚本不能直接等价复用。可选方案有三个：
+
+1. 要求 Sentinel-1 生产任务必须绑定原始 ZIP。
+2. 在分发阶段把 `.SAFE` 目录重新打包成 ZIP。
+3. 改造 PyINT 的 Sentinel-1 导入脚本，让它直接接受 `.SAFE` 路径。
+
+推荐第 1 种。第 2 种会增加磁盘和时间成本，第 3 种会扩大对专家代码的修改面。
+
+### 4.3 单对 D-InSAR 最小流程
+
+对于本系统的 D-InSAR 配对任务，建议先做“系统选出一对，PyINT 处理这一对”，而不是马上做完整时序网。
+
+可控 runner 可以按以下顺序执行：
+
+1. 准备 `$SCRATCHDIR/<project>/DOWNLOAD`，放入 master/slave Sentinel-1 ZIP。
+2. 写入 `$TEMPLATEDIR/<project>.template`，包含 masterDate、slaveDate、swath、burst、look、轨道、DEM、网络参数等。
+3. 调用 `down2slc_sen.py <project> <masterDate>`。
+4. 调用 `down2slc_sen.py <project> <slaveDate>`。
+5. 调用 `extract_s1_bursts.py <project> <masterDate> <slaveDate>`。
+6. 调用 `generate_rdc_dem.py <project>` 或等价 DEM 生成步骤。
+7. 调用 `coreg_s1_gamma.py <project> <masterDate> <slaveDate>`。
+8. 调用 `diff_gamma.py <project> <masterDate> <slaveDate>`。
+9. 调用 `unwrap_gamma.py <project> <masterDate> <slaveDate>`。
+10. 调用 `geocode_gamma.py <project> <masterDate>-<slaveDate>`。
+
+也可以参考 `raw2ifg_s1.py` 作为端到端样板，但不建议生产系统直接无控制地调用全流程脚本。托管系统应该显式控制每一步、日志、失败原因、输出发布和清理策略。
+
+### 4.4 精轨处理
+
+PyINT 的 Sentinel-1 脚本会使用 `eof` / OPOD 目录获取精轨。系统前面已经设计了 Sentinel-1 精轨管理和分发逻辑，因此两者可以分工：
+
+- 数据管理层负责发现、缓存、匹配和可选分发 EOF。
+- PyINT runner 负责把 EOF 目录暴露给 PyINT/GAMMA。
+- preflight 负责确认 master/slave 覆盖时段都有可用 EOF。
+
+这样可以避免每次生产任务都临时联网下载精轨，也能保证任务可复现。
+
+## 5. ISCE2 接入方案
+
+ISCE2 Sentinel-1 TOPS 路线理论上可行，但本项目当前没有现成托管实现。
+
+如果做 ISCE2，需要新增：
+
+- `s1_tops` profile。
+- `topsApp.py` 路径配置，例如 `ISCE2_TOPS_APP`。
+- Sentinel-1 SAFE/ZIP 输入准备逻辑。
+- EOF 轨道文件挂载逻辑。
+- `topsApp.py` XML 生成器。
+- topsStack 或 topsApp 的执行脚本。
+- Sentinel-1 TOPS 输出目录识别、catalog 发布和日志解析。
+- 与 LT-1 `stripmapApp.py` profile 隔离的健康检查。
+
+这条路线的主要风险不是 ISCE2 不支持 Sentinel-1，而是当前系统的 ISCE2 封装抽象是为 LT-1 stripmap 写的。直接把 Sentinel-1 塞进现有 `lt1_stripmap` runner 会形成大量条件分支，后期维护会很差。
+
+如果要做，建议完全独立成 `s1_tops`，不要污染 LT-1 runner。
+
+## 6. 配对与基线策略
+
+Sentinel-1 的配对建议分为两层。
+
+第一层是系统内的轻量预筛选：
+
+- 同一 relative orbit。
+- 同一升降轨方向。
+- 同一 beam mode，例如 IW。
+- 极化兼容，例如 VV 对 VV、VH 对 VH。
+- 覆盖范围有足够重叠。
+- 时间基线在阈值内。
+- 产品级别满足生产要求，优先 SLC。
+- EOF 精轨可获得。
+
+第二层是处理引擎内的精确校验：
+
+- SLC/TOPS 导入是否成功。
+- master/slave 是否有共同 burst。
+- DEM 覆盖是否足够。
+- GAMMA `base_calc` 计算出的垂直基线是否超过阈值。
+- TOPS 配准质量是否达标。
+- 干涉、解缠、地理编码是否生成有效产物。
+
+这符合“配对是初级任务，不要太复杂”的目标。系统配对不应该冒充严密的 SAR 处理器；它只需要筛出大概率能跑的候选对。真正的物理基线和可处理性，由 GAMMA/ISCE2 在生成 SLC/RSLC 后确认。
+
+注意命名上应避免再把 footprint 质心距离叫作 `spatial_baseline_meters`。对 Sentinel-1 更合理的字段区分是：
+
+- `centroid_distance_meters`：覆盖 footprint 质心距离，只是几何覆盖近似指标。
+- `temporal_baseline_days`：时间基线。
+- `perpendicular_baseline_meters`：由处理引擎计算或轨道模型计算出的垂直基线。
+
+## 7. 工作量评估
+
+### Gamma/PyINT 优先路线
+
+前提：Sentinel-1 数据管理、ZIP 保留、EOF 匹配和分发机制已经具备。
+
+预计工作量：
+
+- 最小可用单对 D-InSAR：约 4 到 7 个工作日。
+- 加上稳定的前端配置、健康检查、日志归档、失败原因归类和输出发布：约 1 到 2 周。
+- 扩展到时序网、自动 burst 推荐、多 pair 网络：另算，不建议第一阶段做。
+
+主要风险：
+
+- 原始数据是否保留 ZIP。
+- WSL/GAMMA 环境中的 Sentinel-1 命令是否完整。
+- `eof` 工具和 OPOD 目录是否稳定。
+- PyINT 模板字段默认值是否适配当前项目。
+- 大量 ZIP、SLC、RSLC 中间产物带来的磁盘压力。
+
+### ISCE2 Sentinel-1 路线
+
+预计工作量：
+
+- 可用 demo：约 1 周。
+- 托管生产级接入：约 2 周或更长。
+
+主要风险：
+
+- 当前 `isce2_engine.py` 和 WSL registry 偏 LT-1 stripmap。
+- 需要新增 topsApp/topsStack 方向的 XML、输入资产和产物识别。
+- 输出结构和错误日志与当前 LT-1 ISCE2 产物不一致。
+- 对系统健康检查和 profile registry 的影响更大。
+
+## 8. 推荐实施路线
+
+第一阶段只做 Gamma/PyINT Sentinel-1 单对 D-InSAR：
+
+1. 完成 Sentinel-1 数据管理文档中的数据入库、元数据、EOF 匹配和分发约定。
+2. 新增 `s1_gamma_dinsar` profile。
+3. 新增 Sentinel-1 PyINT runner，显式调用 `D:\Code\PyINT` 中已存在的 Sentinel-1 脚本链。
+4. 生产任务只接受 master/slave 两景 SLC ZIP。
+5. 配对表只保存轻量预筛选指标和处理后回填的真实 `perpendicular_baseline_meters`。
+6. 跑通后再考虑自动 burst 推荐、多 pair 网络和 ISCE2 `s1_tops`。
+
+第二阶段再做 ISCE2 Sentinel-1：
+
+1. 新增 `s1_tops` profile。
+2. 使用 `topsApp.py` 或 topsStack，不复用 LT-1 stripmap runner。
+3. 与 Gamma 路线共享数据管理和 EOF 匹配能力。
+4. 输出 catalog 与生产日志保持同一前端体验。
+
+## 9. 验收标准
+
+Gamma/PyINT Sentinel-1 接入的第一阶段验收建议如下：
+
+- 同一对 Sentinel-1 ZIP 可以从任务分发目录进入 PyINT `DOWNLOAD`。
+- preflight 能明确报告 ZIP、EOF、DEM、GAMMA 命令和模板字段是否齐全。
+- master/slave 能成功生成 SLC。
+- 能识别共同 burst 并完成裁剪。
+- 能完成 TOPS 配准并生成 RSLC。
+- 能生成差分干涉图、解缠结果和地理编码结果。
+- 生产日志能展示每一步命令、耗时、退出码和失败原因。
+- 结果 catalog 能发布核心产物。
+- 配对记录能回填真实 `perpendicular_baseline_meters`，同时保留原始 `centroid_distance_meters`。
+
+## 10. 总体判断
+
+不使用 ENVI + SARscape 核心没有问题。对 Sentinel-1 D-InSAR 来说，本项目更应该优先利用 Gamma/PyINT 的专家代码路线。
+
+Gamma/PyINT 是“已有专家脚本，需要做系统托管适配”；ISCE2 是“算法生态支持，但本项目需要新增 tops profile”。所以第一阶段选择 Gamma/PyINT 更稳、更快，也更符合“配对不要做得过度复杂，但生产尽可能有精度”的目标。