insar-management-system-v2/docs/SENTINEL1_DINSAR_GAMMA_ISCE2_FEASIBILITY_20260510.md

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：

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 脚本默认从：

$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 更稳、更快，也更符合“配对不要做得过度复杂，但生产尽可能有精度”的目标。