# InSAR 管理系统项目汇报

版本日期：2026-03-13

## 一、汇报目的

本文用于项目汇报和方案评审，重点说明三件事：

1. 当前 InSAR 管理系统的建设内容和系统价值。
2. 系统在 D-InSAR 生产侧已经形成的技术架构与扩展能力。
3. 如何将 LANDSAR 系统作为第三个 D-InSAR 生产核心嵌入本系统，以及这件事对采购方案的直接影响。

本文是单独汇报材料，强调整体把握、系统边界、实施路径和采购判断，不展开到底层代码细节。

## 二、项目总体定位

本项目不是单一的数据展示平台，而是一个面向 InSAR 业务的综合管理与生产支撑平台，核心目标是把“数据入库、生产组织、结果管理、运行监控、质量分析”放到同一套系统中统一管理。

从业务定位看，系统承担了以下角色：

1. 数据管理平台：统一管理雷达源数据、轨道数据、D-InSAR 结果、水体监测结果等。
2. 生产组织平台：支持配对、批次管理、任务下发、后台处理、结果回收。
3. 运维监控平台：支持健康检查、任务状态、日志、鉴权、许可证控制。
4. 分析辅助平台：支持 AI 质量分析、AI 诊断、统计看板、地图可视化。

因此，这个项目的价值不只是“能不能跑一次处理”，而是把整个业务流程固化为可持续运行的平台能力。

## 三、当前系统建设情况

### 3.1 技术架构

当前系统采用前后端分离架构：

1. 前端：React + Vite，使用 Leaflet 负责地图展示，Chart.js 负责统计图表，Zustand 负责状态管理。
2. 后端：FastAPI 提供 REST API，SQLAlchemy 负责 ORM，Pydantic 负责数据模型校验。
3. 数据库：PostgreSQL + PostGIS，用于业务数据存储和空间能力支撑。
4. 后台任务：独立 Job Worker 进程，负责执行扫描、生产、AI、解包等异步任务。
5. 部署入口：Nginx 负责前端静态资源和反向代理。
6. 外部能力：可选接入 ENVI/SARscape、ISCE2、Ollama 等外部组件。

### 3.2 主要功能模块

系统目前已经具备较完整的业务模块：

1. 雷达数据管理
   支持监控目录扫描、元数据解析、预览图生成、空间范围展示、检索和分页浏览。
2. 轨道数据管理
   支持轨道文件关联和本地轨道池同步，为生产链路提供基础输入。
3. 配对与批次管理
   支持 D-InSAR 配对策略、批量任务组织、批次项管理和后续复制导出。
4. D-InSAR 生产中心
   已经从单引擎思路升级为多引擎生产中心，支持统一查看引擎状态、提交任务、查看运行记录。
5. D-InSAR 结果管理
   支持结果扫描入库、地图展示、缓存、导出、AI 评分与人工标注。
6. AI 能力
   支持质量模型训练、质量预测、影像诊断、报告生成。
7. 水体监测
   已形成相对独立的处理链路和界面。
8. 运维与权限
   包含健康检查、任务管理、审计日志、用户管理、登录限流、许可证控制等。

### 3.3 当前系统成熟度判断

从工程状态看，项目已经不是原型阶段，而是进入“可持续扩展的平台阶段”：

1. 业务边界已明确。
2. 前后端结构已稳定。
3. 后台任务与数据库模型已成体系。
4. 多引擎 D-InSAR 生产框架已经搭起来。
5. 系统具备继续接入第三方生产核心的基础。

这意味着后续采购不应再按“买一个孤立的软件工具”来考虑，而应按“纳入统一生产平台的外部生产核心”来考虑。

## 四、系统运行主线

从全流程看，当前系统的主线可以概括为：

1. 数据进入系统
   扫描雷达目录、轨道目录、结果目录，完成入库和索引。
2. 用户在前端组织任务
   选择 AOI、筛选源数据、执行配对、形成批次、下发生产任务。
3. 后端进入异步处理模式
   系统创建任务记录和作业记录，由 Worker 执行具体处理。
4. 外部引擎执行生产
   当前已支持 ENVI/SARscape 和 ISCE2 两类生产能力。
5. 结果回流系统
   产物落地后可扫描入库、生成缓存、展示到地图和列表，并进入后续分析。
6. 运维与质量闭环
   通过健康检查、日志、审计、AI 分析和人工核查，形成可运维闭环。

这一主线决定了本系统天然适合接入多个生产引擎，只要外部引擎能被标准化调用。

## 五、D-InSAR 生产体系现状

### 5.1 已形成的多引擎框架

当前项目已经不再把 D-InSAR 生产写死在某一套工具链上，而是抽象成统一的“生产引擎”框架。对每个引擎，系统要求至少具备三类能力：

1. 可用性检查：系统要知道该引擎当前能不能用。
2. Profile 列表：系统要知道该引擎支持哪些处理链路。
3. 统一运行入口：系统要能按同样的方式下发任务并接收结果。

在这个框架下，系统现在已有三类引擎标识：

1. `sarscape`
   已可运行，对接现有 ENVI/SARscape 流程。
2. `isce2`
   已可运行，通过 WSL 调用 ISCE2 链路。
3. `landsar`
   目前仅做接口预留和前端占位，尚未真正接入生产能力。

### 5.2 当前已落地的两个生产核心

#### 1. ENVI / SARscape

这是当前系统最成熟的生产核心，主要特点：

1. 与现有历史流程兼容度高。
2. 支持 `metatask` 和 `custom6` 两种 profile。
3. 已具备运行、日志、结果回收和健康检查能力。
4. 适合作为当前生产主力链路。

#### 2. ISCE2

这是当前系统第二个生产核心，主要特点：

1. 通过 WSL 方式运行，避免强依赖本机 Windows 图形环境。
2. 已具备环境检查、路径转换、脚本调用、任务执行能力。
3. 适合承接 LT-1 等标准化链路。
4. 为系统后续接入更多异构引擎提供了样板。

### 5.3 LANDSAR 当前状态

这一点在汇报和采购中必须明确说明：

截至 2026-03-13，`LANDSAR` 在本项目中属于“架构已预留、能力未接入”的状态，具体表现为：

1. 后端已存在 `landsar` 引擎占位。
2. 前端生产中心已预留 `LANDSAR` 状态卡位置。
3. 健康检查体系已将 `LANDSAR` 视为可纳入统一监控的引擎类型。
4. 轨道池体系中已预留 `ORBIT_POOL_LANDSAR` 的配置位置。
5. 但任务提交、执行、日志、结果回收尚未真正实现。
6. 当前生产提交接口实际仍只支持已落地的引擎，`LANDSAR` 还不能像现有生产核心那样直接投入运行。

这意味着：系统架构已经准备好接纳 LANDSAR，但采购后的接入工作仍需要正式实施，不能误判为“买来即可无缝运行”。

## 六、为什么要把 LANDSAR 作为第三个生产核心

从平台演进角度，引入 LANDSAR 的意义主要有四点：

1. 降低对单一商业引擎的依赖。
2. 提升不同场景下的处理适配能力。
3. 形成多引擎并行的生产格局，增强方案弹性。
4. 使采购的软件能力真正纳入平台统一调度，而不是形成新的信息孤岛。

如果 LANDSAR 只是作为独立软件单独运行，那么它对现有系统的价值有限，最终仍然会回到“人工切换工具、人工导入结果、人工追踪过程”的旧模式。只有把它嵌入本系统，成为第三个生产核心，采购价值才能最大化。

## 七、LANDSAR 接入的目标定位

本项目对 LANDSAR 的目标定位不是“重写 LANDSAR 算法”，而是“把 LANDSAR 系统现有 D-InSAR 生产服务纳入统一调度平台”。

因此，推荐的定位是：

1. 本系统负责任务组织、权限控制、日志审计、状态展示、结果入库和运维闭环。
2. LANDSAR 系统负责实际 D-InSAR 生产处理。
3. 双方通过标准接口交互，而不是把两边代码强行揉成一体。

这也是最符合采购落地的模式，因为它对供应商最明确，对我方平台风险最可控。

## 八、LANDSAR 与本系统的推荐交互模式

### 8.1 推荐模式：服务嵌入式接入

建议将 LANDSAR 以“外部生产服务”的方式接入本系统，而不是以人工操作方式接入。

推荐架构如下：

1. 用户仍然只在本系统前端操作。
2. 用户在 D-InSAR 生产中心中选择 `LANDSAR` 作为引擎。
3. 本系统后端创建标准任务和作业记录。
4. `landsar` 适配引擎把任务参数发送给 LANDSAR 生产服务。
5. LANDSAR 返回运行编号并执行处理。
6. 本系统轮询任务状态，或者接收 LANDSAR 回调通知。
7. 处理完成后，产物输出到约定目录，或由本系统拉取到指定目录。
8. 本系统完成结果扫描、入库、展示和后续分析。

这样做的最大好处是：对用户来说，LANDSAR 不是另一套系统，而是本系统中的第三个生产核心。

### 8.2 不推荐模式：纯人工导入导出

如果采购的 LANDSAR 只能做到“人工打开软件、手工点运行、手工拷贝结果”，则它不能真正成为第三个生产核心，只能成为一个外部工具。这样会带来以下问题：

1. 无法统一任务状态。
2. 无法统一日志与审计。
3. 无法统一批次管理。
4. 无法纳入健康检查。
5. 无法形成稳定的生产闭环。

因此，采购时必须把“可集成、可调用、可监控”作为硬条件。

## 九、LANDSAR 接入后的业务流程

建议将接入流程设计为以下八步：

1. 任务组织
   用户在本系统完成配对、批次选择、AOI 约束和参数选择。
2. 任务提交
   本系统向 LANDSAR 服务提交标准化请求，包括输入目录、输出目录、profile、处理参数、任务编号等。
3. 运行登记
   本系统保存本地任务 ID 和 LANDSAR 侧运行 ID 的映射关系。
4. 执行监控
   本系统通过轮询接口或回调机制获取进度、状态和错误信息。
5. 日志采集
   本系统读取 LANDSAR 返回的执行日志摘要，必要时保留完整日志文件地址。
6. 产物回收
   LANDSAR 将产物输出到双方约定目录，或通过下载接口交给本系统。
7. 结果入库
   本系统对产物进行扫描、索引、缓存生成和结果入库。
8. 统一展示
   用户在现有结果管理界面中查看 LANDSAR 结果，与其他引擎结果统一管理。

## 十、LANDSAR 作为第三核心时的系统改造点

从本系统角度，真正需要做的改造不是推倒重来，而是在现有多引擎框架上补全 `landsar` 适配层。

### 10.1 后端改造点

1. 完成 `landsar_engine.py`
   目前这个文件只是占位，需要实现真正的可用性检查、profile 获取和运行逻辑。
2. 增加 LANDSAR 任务处理器
   可以新增独立 `JOB_TYPE_LANDSAR_RUN`，也可以复用统一外部引擎作业模式。
3. 增加运行状态映射
   需要把 LANDSAR 的状态映射到本系统统一状态，如 `PENDING`、`RUNNING`、`COMPLETED`、`FAILED`。
4. 增加日志采集与错误归一化
   要保证前端看到的日志和错误信息可理解、可追踪。
5. 增加结果回收逻辑
   需要把 LANDSAR 输出目录纳入结果扫描与入库体系。
6. 补充轨道池适配
   当前系统已预留 `ORBIT_POOL_LANDSAR`，采购后需明确 LANDSAR 轨道格式和同步策略。

### 10.2 前端改造点

1. 让 `LANDSAR` 状态卡从“预留”变成“可选可提交”。
2. 展示 LANDSAR 专属 profile 和参数项。
3. 在运行历史中显示 `engine=landsar`。
4. 在结果列表和详情中标识结果来源于 LANDSAR。

### 10.3 运维改造点

1. 增加 LANDSAR 服务健康检查。
2. 增加供应商服务连通性检查。
3. 增加回调鉴权或调用鉴权。
4. 增加 LANDSAR 结果目录一致性检查。

## 十一、采购时必须明确的接口要求

这一部分是采购方案的核心。若这些能力得不到保障，LANDSAR 就无法真正嵌入平台。

### 11.1 必须具备的调用方式

供应商至少应提供以下三种方式之一，优先级从高到低如下：

1. HTTP/REST 服务接口
   最推荐，最适合平台接入。
2. 命令行接口（CLI）
   可作为次优方案，但需要明确返回码、日志和输出目录约定。
3. Python/SDK 接口
   也可接受，但后续部署和版本兼容成本通常更高。

如果三者都没有，只提供 GUI 操作，则不建议作为“第三生产核心”采购。

### 11.2 必须具备的最小接口能力

若采用服务接口，建议采购时要求至少提供以下能力：

1. 提交任务接口
   输入参数包括任务编号、profile、输入目录、输出目录、处理参数。
2. 查询任务状态接口
   能返回排队、运行中、完成、失败、取消等状态。
3. 查询进度接口
   能返回百分比或阶段性进度。
4. 查询日志接口
   至少能返回日志摘要，最好支持完整日志文件。
5. 查询产物接口
   能返回主产物、辅产物、日志文件、质量文件等路径或下载地址。
6. 健康检查接口
   能返回服务可用性、许可证状态、核心依赖状态。
7. 能力枚举接口
   能列出当前支持的 profile、版本、约束条件。

### 11.3 必须明确的数据约定

采购时要和供应商约定清楚以下数据边界：

1. 输入目录结构由谁负责准备。
2. 输出目录结构是否固定。
3. 主结果文件命名规则是否稳定。
4. 日志文件命名规则和保存期限。
5. 失败任务是否保留中间文件。
6. 轨道文件格式和目录组织方式。
7. 坐标系、DEM、投影和元数据约定。

没有这些约定，后续集成必然出现反复沟通和返工。

## 十二、建议的采购技术条款

为了确保 LANDSAR 真正能嵌入本系统，建议采购文件中写入如下技术条款。

### 12.1 必选条款

1. 供应商须提供可编程调用接口，不得仅提供人工图形界面。
2. 供应商须提供任务提交、状态查询、日志查询、结果获取的完整接口说明。
3. 供应商须支持与第三方业务系统进行集成，并配合联调。
4. 供应商须提供稳定的版本管理和升级兼容说明。
5. 供应商须明确许可证机制对服务化调用的限制条件。
6. 供应商须配合完成至少一个标准 D-InSAR 生产 profile 的端到端联调验收。

### 12.2 强烈建议条款

1. 支持回调通知机制，减少轮询压力。
2. 支持独立健康检查接口。
3. 支持 profile 枚举和参数模板查询。
4. 支持输出标准化目录结构。
5. 支持服务部署在内网服务器环境。
6. 支持批量任务执行和失败重试。

### 12.3 验收建议

建议把验收拆成两个层次：

1. 集成验收
   能在本系统中完成 LANDSAR 任务提交、状态查看、日志查看、结果入库。
2. 业务验收
   能稳定完成至少一个真实生产样例，并在前端完成统一展示。

### 12.4 采购方案分级建议

为了避免采购完成后无法嵌入现有系统，建议把采购方案分成三档判断：

1. 推荐方案
   采购“LANDSAR 服务接口版 + 联调实施服务 + 服务化许可”。
   该方案要求供应商提供 API 或等价服务接口，并配合完成与本系统的任务、状态、日志、结果联通。这是最符合“第三生产核心”目标的方案。
2. 可接受方案
   采购“LANDSAR CLI/SDK 版 + 本地部署支持 + 接口适配支持”。
   该方案在没有标准服务接口时仍可落地，但后续部署、升级、兼容和运维成本会明显高于推荐方案。
3. 不建议方案
   仅采购“LANDSAR 桌面 GUI 单机版”。
   该方案无法稳定嵌入本系统，只能形成独立工具，难以支撑统一任务管理、日志审计和结果治理，不建议作为本项目采购目标。

## 十三、LANDSAR 接入对采购决策的影响

这一点需要在汇报中重点强调：

采购 LANDSAR，不是单纯采购一个处理软件，而是在采购本系统的第三个生产核心。

因此，采购判断应从以下维度展开：

1. 不只是看算法效果，还要看是否可集成。
2. 不只是看桌面端能不能跑，还要看服务端能不能调。
3. 不只是看一次能不能出结果，还要看能否纳入长期运维。
4. 不只是看供应商交付软件，还要看是否交付接口和联调能力。

如果采购时忽略这些条件，后续极有可能出现“软件买到了，但无法嵌入现有平台”的情况，导致采购价值被打折。

## 十四、建议的实施路径

建议分两步推进：

### 第一阶段：完成服务嵌入

目标是让 LANDSAR 先成为“可调度、可监控、可回收”的第三生产核心。

重点工作：

1. 完成接口对接。
2. 完成任务状态联通。
3. 完成日志与结果回流。
4. 完成前端选择与展示。

### 第二阶段：完成深度治理

目标是把 LANDSAR 结果纳入更完整的统一治理体系。

重点工作：

1. 结果版本管理。
2. 多引擎结果对比。
3. 质量评价与复核闭环。
4. 更细粒度的运行审计和运维检查。

这样推进的好处是先把采购价值尽快落地，再逐步做深，而不是一开始就把目标定得过重。

## 十五、结论

综合判断如下：

1. 当前 InSAR 管理系统已经具备平台化能力，适合承接第三方 D-InSAR 生产核心。
2. 系统的多引擎架构已经形成，`LANDSAR` 不是从零开始接，而是在既有框架中补齐适配层。
3. 截至目前，`LANDSAR` 在系统中仍是预留状态，尚未真正接入生产执行。
4. 因此，采购方案必须把“可编程调用、可集成、可监控、可回收”写成明确要求。
5. 最推荐的采购与实施方式，是将 LANDSAR 以外部生产服务的形式嵌入本系统，作为第三个 D-InSAR 生产核心统一调度。

一句话概括：本项目当前已经具备“接入第三生产核心”的平台基础，下一步采购是否成功，关键不在于是否购买到一个能跑的工具，而在于是否购买到一个能够被本系统稳定接入的服务化能力。