insar-management-system-v2/docs/archive/SBAS_TASK_PATH_MODE_EVALUATION_20260406.md

SBAS 是否可复用现有 D-InSAR Task 路径生产模式

更新日期：2026-04-06

1. 结论

结论分两层：

• 可以复用“以标准输入目录作为生产入口”的模式
• 不能直接复用现有 D-InSAR 的 Task_x/master + slave 目录协议和 copy-ps-stack 实现

也就是说：

• 可以借用 D-InSAR 的生产思想
• 不能照搬 D-InSAR 的输入结构

2. 现有 D-InSAR 生产模式是什么

当前 D-InSAR 的 ISCE2 生产模式，本质上是：

1. 先把一对影像整理成标准任务目录
2. 每个任务目录固定包含：
   • master/
   • slave/
   • .dinsar_pair.json
3. 生产入口只接收一个 root_dir
4. 引擎自行扫描这个 root_dir
   • 要么它本身就是一个 task 目录
   • 要么它下面有多个 Task_* 子目录
5. 每个 task 目录独立产出一个 pair result

关键实现：

• backend/app/dinsar_engines/isce2_engine.py:314-361
  • validate_root_dir() 要求：
    • 单个 task 目录必须有 master 和 slave
    • 或父目录下有多个合法 Task_*
• backend/app/copier.py:178-218
  • D-InSAR 复制时会构建：
    • <dest>/<task_alias>/master
    • <dest>/<task_alias>/slave
    • .dinsar_pair.json
• backend/app/isce2_pipeline/run_lt1_dinsar_pipeline.py:262-298
  • pipeline 运行时明确按 master / slave 两景读取

所以这是一套“面向影像对”的输入协议。

3. 现有 PS/SBAS 选片算法能不能找出时序队列

可以，但当前更准确地说，它是：

• 一个“候选栈发现器”
• 还不是一个“生产级栈定义器”

现有实现：

• backend/app/services/spatial_service.py:414-481

当前逻辑会：

• 先选出与 AOI 初始重叠比例满足阈值的影像
• 按轨道方向分组
• 求每个方向的公共重叠区
• 再筛出对公共区覆盖比例满足阈值的影像
• 最终按日期排序返回

这对 SBAS 是有价值的，因为它已经能给出：

• 同轨方向
• 共享公共覆盖区
• 时间排序后的影像列表

但它当前还缺少若干生产级约束：

• 没有显式要求 has_orbit_data = True
• 没有显式要求相同 imaging_mode
• 没有显式要求相同 polarization
• 没有最小栈规模规则
• 没有最大时间间隔或参考影像策略
• 没有把结果固化为“一个稳定的 stack identity”

所以答案是：

• 用来找 SBAS 候选时序队列，可以
• 直接当生产入口，不够

4. 为什么 D-InSAR 的 task 路径模式不能原样套给 SBAS

4.1 D-InSAR 是二元输入，SBAS 是栈输入

D-InSAR 当前 pipeline 只解析两个角色：

• master
• slave

见：

• backend/app/isce2_pipeline/run_lt1_dinsar_pipeline.py:262-298

而 SBAS 至少需要：

• 一个有序场景集合
• 栈级别的公共参数
• 栈级别的参考日期
• 栈级别的输出目录约定

因此 SBAS 的输入目录协议必须是“stack contract”，不是“pair contract”。

4.2 当前 copy-ps-stack 是平铺复制，不会生成栈元数据

现有 PS 复制逻辑：

• backend/app/copier.py:45-115

它的行为是：

• 从 PsTaskItemORM.file_path 取路径
• 优先复制 original_path + "_envi_import"
• 否则复制原路径
• 直接平铺复制到 dest_dir/<basename>

它不会生成：

• 栈 manifest
• 日期排序
• 参考日期
• 轨道清单
• DEM / water mask / publish 约定

因此这套复制结果目前更像“把选中的影像搬过去”，不是“形成一个可投产的 SBAS 输入包”。

4.3 当前 PS 批次模型保存的信息不够

现有：

• backend/app/models/orm.py:532-550
• backend/app/routers/task_batches.py:303-312

PsTaskItemORM 只保存：

• file_path
• satellite
• imaging_date
• polarization
• has_orbit_data

没有保存：

• orbit_direction
• imaging_mode
• 稳定 group_key
• 公共覆盖区
• 参考影像策略

这说明 PS 批次目前还是“输入快照”，不是“可直接投产的 stack contract”。

5. 哪部分可以直接复用

可以直接复用的，不少。

5.1 生产入口模式

复用思路：

• 一个 root_dir
• 引擎自己扫描这个目录
• 支持“单个 stack 目录”或“父目录下多个 stack 目录”

这点可以直接仿照：

• backend/app/dinsar_engines/isce2_engine.py:314-361

只是把目录判定从：

• master + slave

换成：

• stack_input_manifest.json 或 .ps_stack.json

5.2 作业提交模式

可以直接复用 D-InSAR 当前的：

• router 提交任务
• task_service.create_task()
• job_queue_service.create_job()
• worker 执行
• 返回单次运行状态

5.3 目录驱动执行

这部分思想也可以复用：

• 输入目录是唯一入口
• engine 不依赖前端临时状态
• 只要目录契约稳定，就可以重复运行

这对 SBAS 是对的。

6. SBAS 推荐的“task 路径模式”

建议做一个 SBAS 版输入目录协议，而不是复用 D-InSAR 的 Task_* 结构。

推荐：

Stack_<group_key>/
  stack_input_manifest.json
  scenes/
    20250118/
      source_scene.json
      <raw scene or link>
    20250315/
      source_scene.json
      <raw scene or link>
    20250510/
      source_scene.json
      <raw scene or link>
  inputs/
    dem/
  logs/

后续运行阶段再生成：

Stack_<group_key>/
  stack_input_manifest.json
  scenes/
  SLC/
  stack_work/
  publish/
  logs/

7. 推荐的 stack_input_manifest.json 最小字段

至少应包含：

• group_key
• batch_id
• mode
  • sbas
• direction
• reference_date
• stack_dates
• scene_count
• dem_path_windows
• dem_path_wsl
• orbit_pool_windows
• orbit_pool_wsl
• publish_dir_windows
• publish_dir_wsl
• water_mask_mode
• scenes[]
  • date
  • file_path
  • satellite
  • imaging_mode
  • polarization
  • orbit_direction
  • orbit_xml_path
  • has_orbit_data

这个文件对 SBAS 的作用，等价于 D-InSAR 里的 .dinsar_pair.json，但它描述的是一个栈，不是一对。

8. 物理复制要不要照搬 D-InSAR

不建议原样照搬。

原因：

• SBAS 常常是 5 景、10 景甚至更多
• 全量复制原始影像会放大 IO 和存储成本
• 你当前原始数据已经在 WSL 可见路径下，不一定需要再复制一遍

更合理的 Phase 1 做法：

• 保留“输入目录”概念
• 但目录里优先存：
  • manifest
  • sidecar metadata
  • 规范化链接或原路径引用
• 仅在必要时物化最小运行所需文件

也就是说：

• 推荐“目录驱动”
• 不推荐“全量复制驱动”

9. 最终判断

如果你的问题是：

• “现有匹配算法能不能找出 SBAS 需要的时序影像队列？”

答案是：

• 可以作为候选栈发现器
• 但还需要补生产级校验和栈固化

如果你的问题是：

• “能不能沿用 D-InSAR 生产时的输入 task 路径模式？”

答案是：

• 可以沿用这个模式的思想
• 不能沿用现有 D-InSAR 的具体目录协议和复制实现

最推荐的落地方式是：

1. 保留“目录作为生产入口”
2. 为 SBAS 定义独立的 Stack_* 输入契约
3. 用 stack_input_manifest.json 替代 .dinsar_pair.json
4. 用 stack-aware 的 prepare/materialize 步骤替代当前 copy-ps-stack 平铺复制

这样既能继承现有系统的生产模式，又不会把 SBAS 错套成二景 D-InSAR。