Files

T

Harmon d108b33f80 docs: govern and archive superseded notes

- add documentation governance and cleanup audit documents

- update README and docs index to distinguish current vs historical sources

- move superseded planning, SBAS, Gamma, and experiment notes into docs/archive

- fix remaining archive text garbling in two documents

2026-04-27 08:06:09 +08:00

18 KiB

Raw Blame History

InSAR 管理系统项目汇报

版本日期：2026-03-13

一、汇报目的

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

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

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

二、项目总体定位

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

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

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

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

三、当前系统建设情况

3.1 技术架构

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

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

3.2 主要功能模块

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

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

3.3 当前系统成熟度判断

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

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

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

四、系统运行主线

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

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

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

五、D-InSAR 生产体系现状

5.1 已形成的多引擎框架

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

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

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

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

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

1. ENVI / SARscape

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

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

2. ISCE2

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

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

5.3 LANDSAR 当前状态

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

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

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

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

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

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

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

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

七、LANDSAR 接入的目标定位

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

因此，推荐的定位是：

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

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

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

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

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

推荐架构如下：

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

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

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

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

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

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

九、LANDSAR 接入后的业务流程

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

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

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

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

10.1 后端改造点

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

10.2 前端改造点

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

10.3 运维改造点

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

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

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

11.1 必须具备的调用方式

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

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

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

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

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

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

11.3 必须明确的数据约定

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

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

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

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

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

12.1 必选条款

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

12.2 强烈建议条款

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

12.3 验收建议

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

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

12.4 采购方案分级建议

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

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

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

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

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

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

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

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

十四、建议的实施路径

建议分两步推进：

第一阶段：完成服务嵌入

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

重点工作：

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

第二阶段：完成深度治理

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