Harmon/insar-management-system-v2
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update production workflow design and runtime changes

Browse Source
This commit is contained in:
Harmon
2026-06-14 18:47:00 +08:00
parent 58a87706ef
commit b1c59051b9
41 changed files with 2042 additions and 134 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/BASEMAP_TILESERVER_PROXY_AND_ACCESS_20260613.md
+152
View File
@@ -0,0 +1,152 @@
# Basemap Tile Server Proxy and LAN Access
Date: 2026-06-13
This document records the local tile-server integration used by the InSAR Management System v2 Windows launcher.
## Goals
- Start and stop `D:\Code\tile-server` from the main `start_system.bat` / `stop_system.bat` workflow.
- Serve basemap tiles through the main Nginx entry instead of exposing tile-server directly to browsers.
- Keep tile access token configuration in local `.env`; do not commit real tokens.
- Allow optional LAN client IP whitelisting.
- Show a clear restricted-access page for non-whitelisted clients.
## Runtime Topology
```text
LAN browser
-> http://<server-ip>/
-> main nginx :80
-> frontend dist
-> /api/ -> FastAPI backend on 127.0.0.1:<PORT>
-> /tiles/ -> tile-server on 127.0.0.1:8910
-> /geojson/ -> tile-server on 127.0.0.1:8910
```
The tile-server can stay bound to `127.0.0.1:8910`. LAN clients should not call `8910` directly.
## `.env` Settings
Tile-server frontend URL should normally be empty, which means same-origin routing through Nginx:
```env
VITE_TILE_SERVER_URL=
VITE_TILE_SERVER_TOKEN=change_me
TILE_SERVER_AUTO_START=true
TILE_SERVER_AUTO_STOP=true
TILE_SERVER_ROOT=D:\Code\tile-server
TILE_SERVER_START_SCRIPT=start-all.bat
TILE_SERVER_STOP_SCRIPT=stop-all.bat
```
The real `VITE_TILE_SERVER_TOKEN` belongs only in local `.env`.
## LAN IP Whitelist
Use `NGINX_ALLOWED_CLIENT_IPS` to restrict clients:
```env
NGINX_ALLOWED_CLIENT_IPS=192.168.1.10;192.168.1.23
```
Accepted separators are semicolon, comma, or whitespace. CIDR values are also accepted:
```env
NGINX_ALLOWED_CLIENT_IPS=192.168.1.0/28
```
Empty value means no client IP restriction:
```env
NGINX_ALLOWED_CLIENT_IPS=
```
When the whitelist is enabled, the launcher generates `nginx/client_allow.conf` with `allow` rules plus `deny all`.
## Downstream Router Cases
When client devices are behind another router, write the IP that the InSAR server actually sees.
### NAT router mode
If a downstream router has an upstream LAN address such as `192.168.1.63`, and its clients are hidden behind NAT, Nginx will see every downstream client as:
```text
192.168.1.63
```
Whitelist the router IP:
```env
NGINX_ALLOWED_CLIENT_IPS=192.168.1.63
```
This allows all clients behind that NAT router because the server cannot distinguish them by their private downstream IPs.
### AP or bridge mode
If the downstream device works as an AP/bridge, clients usually receive addresses from the main LAN, for example:
```text
192.168.1.80
192.168.1.81
```
Whitelist the actual device IPs:
```env
NGINX_ALLOWED_CLIENT_IPS=192.168.1.80;192.168.1.81
```
### Routed subnet without NAT
If the downstream router forwards another subnet without NAT, the server may see the real downstream subnet addresses, for example:
```text
192.168.63.10
192.168.63.11
```
Whitelist exact client IPs:
```env
NGINX_ALLOWED_CLIENT_IPS=192.168.63.10;192.168.63.11
```
Or whitelist the whole downstream subnet when that is acceptable:
```env
NGINX_ALLOWED_CLIENT_IPS=192.168.63.0/24
```
### How to decide
Open the system from the downstream device before whitelisting it. The restricted-access page displays the detected client IP. Put that displayed IP, or its trusted CIDR range, into `NGINX_ALLOWED_CLIENT_IPS`.
## Restricted Client Page
Nginx maps `403` responses to `nginx/access_denied.html`. The page displays:
- access restricted message
- detected client IP
- requested host
- operator hint to update `NGINX_ALLOWED_CLIENT_IPS`
## Applying Changes
After changing `.env`, run `start_system.bat` or reload Nginx:
```powershell
C:\nginx-1.29.6\nginx.exe -t -c D:\Code\Insar_management_system_v2\nginx\nginx.conf
C:\nginx-1.29.6\nginx.exe -s reload -c D:\Code\Insar_management_system_v2\nginx\nginx.conf
```
From an allowed client:
```text
http://<server-ip>/
http://<server-ip>/tiles/gaode_image/7/107/42.webp?token=<token>
```
From a denied client, Nginx should return the restricted-access page with HTTP 403.
docs/DEPLOYMENT.md
+31 -5
View File
@@ -111,11 +111,37 @@ ORBIT_POOL_LANDSAR=
IDL_EXECUTABLE=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idl.exe
IDL_WORKBENCH_PATH=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idlde.exe
IDL_DINSAR_DEM_BASE_FILE=D:\SRTM30m\SRTMDEM_RSP_SARscape
IDL_WORKER_RUNTIME_DIR=D:\Code\Insar_management_system_v2\backend\runtime\idl_worker
IDL_WORKER_RUNTIME_DIR=D:\production_runtime\idl_worker
ENVI_TASK_TIMEOUT_SECONDS=21600
```
### 3.5 WSL 共享运行时
### 3.5 GF3 SARscape 生产
GF3 当前主线是“ENVI/SARscape 生产原生 `_geo` 证据层，平台标准化成 GeoTIFF 后入库和供洪涝/水体算法消费”。旧 Python/GDAL L1A 预处理链路默认关闭。
```env
GF3_ARCHIVE_SOURCE_DIRS=D:\production_inputs\gf3\archives
GF3_LEGACY_GDAL_ENABLED=false
GF3_SOURCE_DIRS=
GF3_SARSCAPE_NATIVE_DIRS=D:\production_results\gf3\sarscape_native
GF3_STORAGE_DIRS=D:\production_results\gf3\standard_l2
GF3_SARSCAPE_RUNTIME_DIR=D:\production_runtime\gf3\sarscape_runtime
GF3_SARSCAPE_WRAPPER_EXE=D:\Code\Insar_management_system_v2\third_party\GF3_L1A_To_L2_pipeline\dist\windows\gf3wrapper.exe
GF3_SARSCAPE_IDLRT_PATH=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idlrt.exe
GF3_SARSCAPE_DEM_PATH=D:\DEM\COPDEM_GLO30_China_4326_DEM
GF3_SARSCAPE_POLARIZATIONS=HH,HV
GF3_SARSCAPE_AUTO_STANDARDIZE=true
GF3_SARSCAPE_CLEAN_AFTER_SUCCESS=true
```
说明：
- `GF3_SARSCAPE_NATIVE_DIRS` 长期保留 `_geo`、`.hdr`、`.sml`、快视、KML、日志和 manifest。
- `GF3_STORAGE_DIRS` 是标准 L2 GeoTIFF 池，后续入库、预览、洪涝/水体分析优先消费这里和 `SAR_ANALYSIS_READY_ROOT`。
- `GF3_SARSCAPE_RUNTIME_DIR` 只放 wrapper 配置和运行时临时文件，不应混入原生结果池。
- 如确需恢复旧 L1A 解包/预处理，需要同时设置 `GF3_LEGACY_GDAL_ENABLED=true` 和 `GF3_SOURCE_DIRS`。
### 3.6 WSL 共享运行时
当前推荐采用“一套共享 distro + 一套共享 conda 环境”模式。
@@ -123,7 +149,7 @@ ENVI_TASK_TIMEOUT_SECONDS=21600
WSL_DISTRO=Ubuntu-24.04
WSL_SHARED_CONDA_ENV=insar_wsl_v1
WSL_SHARED_PYTHON=/home/administrator/miniconda3/envs/insar_wsl_v1/bin/python
WSL_BROKER_JOB_ROOT=D:\Code\Insar_management_system_v2\backend\runtime\wsl_jobs
WSL_BROKER_JOB_ROOT=D:\production_runtime\wsl_jobs
ISCE2_RUNTIME_ID=isce2_runtime_v1
PYINT_RUNTIME_ID=gamma_pyint_runtime_v1
@@ -138,7 +164,7 @@ PYINT_RUNTIME_ID=gamma_pyint_runtime_v1
使用共享 python，runner 为 `deploy/wsl/runners/gamma_pyint_runner.py`
Gamma 固定环境脚本为 `deploy/wsl/profiles/gamma_env.sh`
### 3.6 ISCE2 D-InSAR 与旧时序兼容
### 3.7 ISCE2 D-InSAR 与旧时序兼容
```env
ISCE2_ENABLED=false
@@ -156,7 +182,7 @@ TIMESERIES_PYTHON=/home/administrator/miniconda3/envs/insar_wsl_v1/bin/python
- 旧 ISCE2/MintPy 时序生产链默认关闭，不再作为 SBAS 生产入口。
- 如果必须做历史链路对比，需要显式开启 `TIMESERIES_ENABLED=true` 并提供完整旧脚本路径。
### 3.7 Gamma / PyINT / SBAS
### 3.8 Gamma / PyINT / SBAS
```env
PYINT_ENABLED=true
docs/DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md
+212
View File
@@ -0,0 +1,212 @@
# D-InSAR 三引擎 Task_Pool 生产链路重构设计
更新日期：2026-06-14
## 1. 结论
D-InSAR 后续生产只保留三类核心引擎：
- `sarscape`：ENVI + SARscape。
- `landsar`：LandSAR D-InSAR。
- `pyint`：Gamma / PyINT。
`isce2` 从 D-InSAR 正式生产链路退出。后端运行入口、引擎注册、任务类型、结果发布特殊分支、前端引擎选择和结果筛选都需要清理。已有 ISCE2 历史结果不在本次设计中直接删除，默认进入 legacy 只读语义：不参与新任务分发、不在默认结果管理视图中展示，只在显式历史查询或迁移脚本中处理。
三条保留链路统一走 Task_Pool 任务格式。LandSAR 和 ENVI + SARscape 只处理陆探 LT-1 数据；Gamma / PyINT 同时支持 LT-1 和 Sentinel-1。
## 2. 当前代码事实
当前系统已经具备多引擎基础，但还没有完成 Task_Pool 一致化：
- `backend/app/routers/dinsar_production.py` 暴露 D-InSAR 多引擎生产接口，当前仍接受 `sarscape / isce2 / pyint / landsar`。
- `backend/app/dinsar_engines/registry.py` 仍注册 `Isce2Engine`。
- `backend/app/services/dinsar_production_service.py` 已经按 engine/profile 生成运行项、当前指针和未完成判断，但 `_task_type_for_engine`、`_workflow_name_for_engine`、`_workflow_step_name_for_engine` 仍包含 ISCE2。
- `backend/app/services/job_handlers.py` 同时存在 SARscape、ISCE2、PyINT、LandSAR 的 job handler。
- `backend/app/dinsar_engines/landsar_engine.py` 已经围绕 LT-1 `Task_*/Input_Data` 和 `master/slave` 原始目录做输入检查。
- `backend/app/dinsar_engines/pyint_engine.py` 支持 `lt1_gamma_dinsar` 和 `s1_gamma_dinsar` profile，但未完成判断目前偏向 LT-1 profile，需要按 profile 收敛。
- `backend/app/services/result_catalog_service.py` 的结果目录、manifest、current 指针和 `result_products` 表已经能承载多引擎多次运行，但展示层仍是“一个引擎结果一条记录”。
- `backend/app/routers/task_batches.py` 的 D-InSAR batch/item 表保存了配对身份和任务状态，但没有保存或返回各引擎结果矩阵，也没有显式 Task_Pool 物理发布状态。
- `frontend/src/components/DinsarCatalogPanel.jsx` 和 `frontend/src/utils/dinsarEngines.js` 仍把 ISCE2 当作当前引擎之一，结果管理也是平铺展示。
## 3. 目标 Task_Pool 契约
D-InSAR 正式生产入口统一接受 Task_Pool 任务目录，不再把任意平铺目录作为正式生产输入。兼容导入可以保留在迁移工具或单独入口，不能作为标准链路。
推荐根路径：
```text
D:\Task_Pool\DInSAR\
Task_<master_date>_<slave_date>[_suffix]\
task_manifest.json
.dinsar_pair.json
master\
...
slave\
...
Input_Data\
...
```
目录语义：
- `task_manifest.json`：Task_Pool 任务清单，记录任务来源、配对身份、数据类型、允许引擎、各引擎结果快照和分发状态。新实现应写入；旧任务可由 `.dinsar_pair.json` 和目录结构推断。
- `.dinsar_pair.json`：现有配对侧车文件，继续作为 `pair_key`、`pair_uid`、`network_run_id`、`network_edge_id` 等身份信息的本地来源。
- `master/`、`slave/`：标准主从影像资产目录。LT-1 放陆探原始包或解包后的 xml/tif；Sentinel-1 放 SAFE/ZIP 及可解析的轨道资产引用。
- `Input_Data/`：LandSAR 运行所需的 LT-1 输入目录。可以由 `master/slave` 导入生成，但生成关系必须写入 manifest，避免后续误判源数据。
任务身份以 `pair_key` 为稳定主键，`network_edge_id` 为配对网络中的边身份，`run_key` 为一次具体生产实例。已有代码中的 `.dinsar_run.json` 继续用于单次运行元数据。
## 4. 引擎能力矩阵
| 引擎 | engine_code | 数据类型 | 输入目录 | 结果 profile |
| --- | --- | --- | --- | --- |
| ENVI + SARscape | `sarscape` | LT-1 | `Task_*/master` + `Task_*/slave` | `custom6`、`metatask` |
| LandSAR | `landsar` | LT-1 | `Task_*/Input_Data`，或从 `master/slave` 导入生成 | `lt1_dinsar` |
| Gamma / PyINT | `pyint` | LT-1 | `Task_*/master` + `Task_*/slave` | `lt1_gamma_dinsar` |
| Gamma / PyINT | `pyint` | Sentinel-1 | `Task_*/master` + `Task_*/slave`，配套轨道资产 | `s1_gamma_dinsar` |
生产入口需要按数据类型和 profile 做硬约束：
- LT-1 任务允许 `sarscape`、`landsar`、`pyint`。
- Sentinel-1 任务只允许 `pyint`。
- `sarscape` 和 `landsar` 对 Sentinel-1 返回明确不可分发状态，而不是进入运行后失败。
- `pyint` 的未完成判断必须按 profile 区分，不能只检查 `lt1_gamma_dinsar`。
## 5. 配对发布与完成状态
当前 `/task-batches/dinsar` 只保存配对条目，不知道每个 engine 是否已经产出结果。后续需要在“发布到 Task_Pool”和“查看任务池条目”两个位置补齐结果矩阵。
建议在 D-InSAR task item 响应中增加 `engine_results`：
```json
{
"pair_key": "lt1_20250101_20250201_xxxxx",
"task_alias": "Task_20250101_20250201",
"task_pool_dir": "D:\\Task_Pool\\DInSAR\\Task_20250101_20250201",
"engine_results": {
"sarscape": {
"allowed": true,
"status": "missing",
"profile_code": "custom6",
"latest_product_id": null,
"can_dispatch": true,
"skip_reason": null
},
"landsar": {
"allowed": true,
"status": "ready",
"profile_code": "lt1_dinsar",
"latest_product_id": 123,
"can_dispatch": false,
"skip_reason": "result_exists"
},
"pyint": {
"allowed": true,
"status": "failed",
"profile_code": "lt1_gamma_dinsar",
"latest_product_id": 124,
"can_dispatch": true,
"skip_reason": "retry_allowed"
}
}
}
```
状态建议：
- `missing`：没有对应引擎/profile 的有效产品。
- `running`：已有未完成 job 或运行锁。
- `ready`：已有有效产品，默认不重复分发。
- `failed`：最近一次产品或 job 失败，可按策略允许重跑。
- `blocked`：数据类型、轨道、DEM、许可证或输入结构不满足该引擎。
- `legacy`：历史结果存在，但不参与当前三引擎分发规则。
结果矩阵优先从 `result_products` 和运行状态表实时聚合，不建议一开始复制到 batch item 表中。`task_manifest.json` 可以保存发布时快照，但界面展示应以数据库/catalog 聚合结果为准。
## 6. 结果管理重构
当前结果管理按 `result_products` 平铺展示，导致同一任务的三个引擎结果分成三条记录。目标视图应按任务/配对聚合：
```text
Task_20250101_20250201
pair_key: lt1_20250101_20250201_xxxxx
sarscape: ready / latest run / preview / assets
landsar: missing
pyint: ready / latest run / preview / assets
```
后端建议保留 `result_products` 作为原子产品表，新增聚合查询：
- `GET /dinsar-products/pairs`：按 `pair_key`、`pair_uid`、`network_edge_id` 聚合结果。
- `GET /dinsar-products/pairs/{pair_key}`：返回同一任务下三个引擎的运行历史、资产、预览和 current 指针。
- `GET /dinsar-products/{product_db_id}`：继续保留单产品详情，作为资产钻取入口。
前端结果管理调整为“一行一个任务/配对”，内部显示三个引擎状态 chip。引擎筛选不再把结果拆成多行，而是控制哪些引擎列/状态参与显示。ISCE2 默认不显示，只能通过 legacy 显式开关查看历史记录。
## 7. 中间文件删除模块
删除能力必须建立在“结果已注册成资产”之后，不能直接按目录名粗暴删除。建议新增 D-InSAR intermediate cleanup 服务，职责如下：
- 扫描某个 `pair_key`、`run_key` 或 `product_db_id` 下可清理路径。
- 校验 `manifest.json`、`execution_manifest.json`、`result_assets` 或 manifest assets 中的必要资产都存在。
- 只删除或隔离中间目录，例如 `native/`、engine work dir、临时转换目录、LandSAR 导入过程缓存、PyINT/Gamma 临时处理目录。
- 永远保留标准发布资产：`assets/`、`preview/`、`manifest.json`、`execution_manifest.json`、`.dinsar_run.json`、current 指针、Task_Pool 任务 manifest 和 `.dinsar_pair.json`。
- 支持 `dry_run`，返回将删除的路径、大小和风险原因。
- 第一阶段建议移动到 quarantine/trash，再由运维策略做永久删除。
- 删除动作写审计日志，并把清理状态写回产品摘要或独立 cleanup 表。
建议接口：
- `POST /dinsar-products/{product_db_id}/cleanup-intermediates?dry_run=true`
- `POST /dinsar-products/pairs/{pair_key}/cleanup-intermediates?dry_run=true`
- `GET /dinsar-products/{product_db_id}/cleanup-intermediates/plan`
## 8. 后端改造清单
第一阶段只做读模型和状态聚合，不改变生产执行：
- 新增三引擎常量和能力矩阵，作为后续后端和前端共同事实来源。
- 新增 D-InSAR task item engine result 聚合函数。
- 新增 result catalog pair-grouped 查询。
- 修正 PyINT 按 profile 判断完成状态。
第二阶段收紧 Task_Pool 输入：
- D-InSAR 运行入口只接受 Task_Pool 任务目录或任务目录集合。
- Pairing 发布 batch 时生成或补齐 `task_manifest.json` 与 `.dinsar_pair.json`。
- 对 LT-1 / Sentinel-1 做引擎可分发校验。
- LandSAR 的 `Input_Data` 生成关系写入 manifest。
第三阶段移除 ISCE2 正式链路：
- 删除 `Isce2Engine` 注册。
- 移除 D-InSAR submit API 中的 `isce2` 分支。
- 移除 ISCE2 job type 到新任务分发的映射。
- 移除 result catalog 新发布中的 ISCE2 特殊处理。
- 前端移除 ISCE2 引擎选项、筛选项和当前说明文案。
- 历史 ISCE2 产品标记为 legacy，只在显式历史入口展示。
第四阶段上线中间文件清理：
- 先提供 dry-run 和 quarantine。
- 加入资产完整性校验。
- 加入审计记录和恢复说明。
- 稳定后再允许永久删除。
## 9. 前端改造清单
- D-InSAR 生产面板只展示 `sarscape`、`landsar`、`pyint`。
- 数据类型为 Sentinel-1 时，只允许选择 Gamma / PyINT；LT-1 时允许三引擎。
- Batch/Task_Pool 列表展示每个任务的三引擎结果状态。
- 已有结果的任务默认显示“已有结果”，并允许按策略重跑或跳过。
- 结果管理从产品平铺改成任务聚合视图。
- 单产品详情保留，用于下载、预览和资产级操作。
- 中间文件清理入口放在产品详情或任务聚合详情内，默认先显示 dry-run 计划。
## 10. 风险与待定项
- 现有 ISCE2 历史结果是否需要迁移到 legacy catalog，还是只隐藏默认入口后保留原记录，需在实际清理前确认。
- ENVI + SARscape 的 `metatask` 是否继续作为可选 profile，还是统一收敛到 `custom6`，需要结合现有项目参数模板决定。
- Task_Pool 根路径需要明确配置项，建议新增 `DINSAR_TASK_POOL_ROOT`，默认 `D:\Task_Pool\DInSAR`。
- 中间文件清理需要先确认每个引擎的“可删目录”和“必须保留资产”清单，不能用一套规则覆盖全部。
- 前端 grouped 结果视图需要兼容旧 flat API 一段时间，避免已有页面一次性断裂。
docs/FLOOD_GEOTIFF_GAMMA_PREPROCESS_DESIGN_20260515.md
+1 -1
View File
@@ -503,7 +503,7 @@ Git 可以提供平台代码、Python 算法、任务编排、数据库迁移和
The first code pass now implements LT1 and GF3 as analysis-ready scene preprocessors:
- New config roots: `SAR_ANALYSIS_READY_ROOT`, `SAR_ANALYSIS_WORK_ROOT`, `SAR_ANALYSIS_PREVIEW_ROOT`.
- Current config roots: `SAR_ANALYSIS_READY_ROOT` and `SAR_ANALYSIS_WORK_ROOT`. `SAR_ANALYSIS_PREVIEW_ROOT` was removed; previews live beside each analysis-ready scene.
- `sar_scene_geo` now stores `analysis_tif_path`, `analysis_dir`, preview path, engine/profile, backscatter unit, nodata, metadata and quality JSON.
- `/flood/preprocess` routes GF3 scenes to `gf3_gdal` standardization and LT1 scenes to `lt_gamma` single-scene preprocessing.
- GF3 uses the existing GDAL/RPC L1A->L2 result, then registers the selected L2 GeoTIFF under `SAR_ANALYSIS_READY_ROOT`.
docs/FLOOD_WATER_ALGORITHM_ENGINEERING_HANDOFF_20260602.md
+1 -2
View File
@@ -54,7 +54,7 @@
| `pixel_size_m` | 近似像元大小 |
| `status` | `PENDING/RUNNING/DONE/FAILED` |
当前 GF3 SARscape 链路会把原生 `_geo` ENVI 二进制转换为 `D:\GF3_L2_Image_Pool` 下的 GeoTIFF，并注册到这里。
当前 GF3 SARscape 链路会先产出原生 `_geo` ENVI 二进制，再由平台转换为 `D:\production_results\gf3\standard_l2` 下的 GeoTIFF，并注册到这里。
### 3.2 WaterExtractionORM
@@ -508,4 +508,3 @@ options: dict | None = None
- 支持模型版本；
- 输出概率图和二值图；
- 与 RF/baseline 可切换。
docs/GF3_SARSCAPE_NATIVE_TO_GEOTIFF_DESIGN_20260530.md
+17 -12
View File
@@ -19,12 +19,15 @@ GF3 原始压缩包池
## 2. 目录约定
推荐继续沿用现场已有目录语义，并新增一个 ENVI/SARscape 原生池。
推荐把输入、生产结果和运行时目录分开，避免把系统工作文件混入业务结果池。
```env
GF3_ARCHIVE_SOURCE_DIRS=D:\GF3_Image_Pool_Zip
GF3_SARSCAPE_NATIVE_DIRS=D:\GF3_L2_ENVI_Binary_Pool
GF3_STORAGE_DIRS=D:\GF3_L2_Image_Pool
GF3_ARCHIVE_SOURCE_DIRS=D:\production_inputs\gf3\archives
GF3_LEGACY_GDAL_ENABLED=false
GF3_SOURCE_DIRS=
GF3_SARSCAPE_NATIVE_DIRS=D:\production_results\gf3\sarscape_native
GF3_STORAGE_DIRS=D:\production_results\gf3\standard_l2
GF3_SARSCAPE_RUNTIME_DIR=D:\production_runtime\gf3\sarscape_runtime
SAR_ANALYSIS_READY_ROOT=D:\production_results\sar_analysis_ready
```
@@ -33,8 +36,10 @@ SAR_ANALYSIS_READY_ROOT=D:\production_results\sar_analysis_ready
| 目录 | 职责 | 系统是否直接分析 |
| --- | --- | --- |
| `GF3_ARCHIVE_SOURCE_DIRS` | 原始 GF3 L1A `.tar.gz` 池 | 否 |
| `GF3_SOURCE_DIRS` | legacy Python/GDAL L1A 解包输入，默认关闭 | 否 |
| `GF3_SARSCAPE_NATIVE_DIRS` | SARscape `_geo` 原生结果池 | 否 |
| `GF3_STORAGE_DIRS` | GF3 标准 GeoTIFF 池 | 是 |
| `GF3_SARSCAPE_RUNTIME_DIR` | wrapper 配置、IDL 运行时临时文件 | 否 |
| `SAR_ANALYSIS_READY_ROOT` | 洪涝/水体分析级统一输入 | 是 |
生产服务器可以不部署完整管理系统。只要把完成后的 `_geo` 原生结果组放入 `GF3_SARSCAPE_NATIVE_DIRS`，管理系统就可以扫描、转换和入库。
@@ -44,7 +49,7 @@ SAR_ANALYSIS_READY_ROOT=D:\production_results\sar_analysis_ready
原生池以批次日期或人工批次号分组。单景目录名尽量保持 GF3 原始产品名。
```text
D:\GF3_L2_ENVI_Binary_Pool
D:\production_results\gf3\sarscape_native
20260514
GF3_MH1_FSII_051377_E132.3_N48.2_20260514_L1A_HHHV_L10007356478
GF3_MH1_FSII_..._hh_geo
@@ -110,7 +115,7 @@ SLC 中间产物
系统从原生池转换后写入 `GF3_STORAGE_DIRS`。
```text
D:\GF3_L2_Image_Pool
D:\production_results\gf3\standard_l2
20260514
GF3_MH1_FSII_051377_E132.3_N48.2_20260514_L1A_HHHV_L10007356478
HH_L2.tif
@@ -269,8 +274,8 @@ status=DONE
{
"schema": "gf3_sarscape_native.v1",
"scene_name": "GF3_MH1_FSII_...",
"native_dir": "D:\\GF3_L2_ENVI_Binary_Pool\\20260514\\GF3_MH1_FSII_...",
"source_archive": "D:\\GF3_Image_Pool_Zip\\20260514\\GF3_MH1_FSII_....tar.gz",
"native_dir": "D:\\production_results\\gf3\\sarscape_native\\20260514\\GF3_MH1_FSII_...",
"source_archive": "D:\\production_inputs\\gf3\\archives\\20260514\\GF3_MH1_FSII_....tar.gz",
"polarizations": ["HH", "HV"],
"status": "NATIVE_READY",
"assets": [
@@ -295,8 +300,8 @@ status=DONE
{
"schema": "gf3_standard_geotiff.v1",
"scene_name": "GF3_MH1_FSII_...",
"native_manifest": "D:\\GF3_L2_ENVI_Binary_Pool\\...\\gf3_native_manifest.json",
"standard_dir": "D:\\GF3_L2_Image_Pool\\20260514\\GF3_MH1_FSII_...",
"native_manifest": "D:\\production_results\\gf3\\sarscape_native\\...\\gf3_native_manifest.json",
"standard_dir": "D:\\production_results\\gf3\\standard_l2\\20260514\\GF3_MH1_FSII_...",
"status": "DONE",
"converter": {
"name": "gf3_sarscape_geo_to_tif",
@@ -446,7 +451,7 @@ GF3_ARCHIVE_SOURCE_DIRS
新增配置：
```env
GF3_SARSCAPE_WRAPPER_EXE=D:\Code\Insar_management_system_v2\.codex_tmp\GF3_L1A_To_L2_pipeline\dist\windows\gf3wrapper.exe
GF3_SARSCAPE_WRAPPER_EXE=D:\Code\Insar_management_system_v2\third_party\GF3_L1A_To_L2_pipeline\dist\windows\gf3wrapper.exe
GF3_SARSCAPE_IDLRT_PATH=C:\Program Files\Harris\ENVI56\IDL88\bin\bin.x86_64\idlrt.exe
GF3_SARSCAPE_DEM_PATH=D:\DEM\GMTED2010.jp2
GF3_SARSCAPE_POLARIZATIONS=HH,HV
@@ -473,4 +478,4 @@ GF3_SARSCAPE_PRODUCE_TIMEOUT_SECONDS=0
- 每景写 `gf3_cleanup_manifest.json`，记录删除条目和释放字节数。
- 不删除 `GF3_ARCHIVE_SOURCE_DIRS` 中的原始压缩包，也不删除 `GF3_STORAGE_DIRS` 中的标准 GeoTIFF。
这样 `D:\GF3_L2_ENVI_Binary_Pool` 只长期保存可追溯的最终 `_geo` 原生结果组，中间过程文件在标准化完成后自动释放空间。
这样 `D:\production_results\gf3\sarscape_native` 只长期保存可追溯的最终 `_geo` 原生结果组，中间过程文件在标准化完成后自动释放空间；wrapper 配置和临时运行文件放在 `D:\production_runtime\gf3\sarscape_runtime`。
docs/INDEX.md
+10 -5
View File
@@ -1,6 +1,6 @@
# 文档索引
最后更新：2026-05-30
最后更新：2026-06-14
本页是当前有效文档入口。没有列在本页的历史设计、实验记录和过程文档不再作为当前系统事实依据。
@@ -12,6 +12,8 @@
- [DEPLOYMENT.md](DEPLOYMENT.md)
Windows + PostgreSQL + WSL2 + Gamma/ISCE2/ENVI 的部署与运行说明。
- [BASEMAP_TILESERVER_PROXY_AND_ACCESS_20260613.md](BASEMAP_TILESERVER_PROXY_AND_ACCESS_20260613.md)
Tile-server proxy, LAN access, token configuration, and Nginx IP whitelist.
- [DOCUMENTATION_GOVERNANCE.md](DOCUMENTATION_GOVERNANCE.md)
文档治理规则、事实来源优先级和清理约定。
@@ -24,10 +26,13 @@
## 生产与结果
- [PRODUCTION_RESULTS_MULTI_ENGINE_DESIGN_20260423.md](PRODUCTION_RESULTS_MULTI_ENGINE_DESIGN_20260423.md)
统一结果目录、标准产品包、catalog 与多引擎结果共存约定。
统一结果目录、标准产品包、catalog 与多引擎结果共存约定。D-InSAR 当前引擎集合以 2026-06-14 三引擎 Task_Pool 重构设计为准。
- [DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md](DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md)
D-InSAR 保留 ENVI/SARscape、LandSAR、Gamma/PyINT 三引擎，退出 ISCE2，统一 Task_Pool、结果聚合和中间文件清理的当前设计。
- [DINSAR_PRODUCTION_CORES_OVERVIEW.md](DINSAR_PRODUCTION_CORES_OVERVIEW.md)
ENVI/SARscape、ISCE2、Gamma/PyINT 三条 D-InSAR 生产核心说明。
旧版 ENVI/SARscape、ISCE2、Gamma/PyINT D-InSAR 生产核心说明。ISCE2 相关内容仅作历史背景。
- [SBAS_INSAR_CURRENT_WORKFLOW.md](SBAS_INSAR_CURRENT_WORKFLOW.md)
当前 Gamma SBAS-InSAR 生产、AOI 选栈、结果 catalog、产物和 LOS 符号约定。
@@ -41,10 +46,10 @@
PROJ / GDAL 配置说明。
- [ISCE2_MANAGED_DINSAR_IMPLEMENTATION_20260424.md](ISCE2_MANAGED_DINSAR_IMPLEMENTATION_20260424.md)
ISCE2 托管 D-InSAR 落地说明。
ISCE2 托管 D-InSAR 历史落地说明。新 D-InSAR 生产不再采用。
- [ISCE2_PRODUCTION_RELIABILITY_HARDENING_DESIGN_20260424.md](ISCE2_PRODUCTION_RELIABILITY_HARDENING_DESIGN_20260424.md)
ISCE2 生产链路稳定性约束。
ISCE2 生产链路历史稳定性约束。新 D-InSAR 生产不再采用。
## 数据与业务模块
docs/LandSAR_API服务接入采购需求说明书_20260604.docx
BIN
View File
Binary file not shown.
docs/PRODUCTION_RESULTS_MULTI_ENGINE_DESIGN_20260423.md
+2
View File
@@ -2,6 +2,8 @@
更新日期：2026-04-24
> 2026-06-14 状态说明：本文保留结果包、catalog、manifest、current 指针等通用目录约定；D-InSAR 当前引擎集合已调整为 ENVI/SARscape、LandSAR、Gamma/PyINT 三类，ISCE2 退出正式生产链路。D-InSAR 引擎、Task_Pool、结果聚合和中间文件清理以 `DINSAR_TASK_POOL_THREE_ENGINE_REFACTOR_20260614.md` 为准。
## 1. 目标
本设计解决三个长期问题：
docs/SBAS_INSAR_CURRENT_WORKFLOW.md
+7 -1
View File
@@ -66,12 +66,13 @@ GAMMA_SBAS_DEFAULT_MB_MODE
GAMMA_SBAS_DEFAULT_REFERENCE_WINDOW
GAMMA_SBAS_STEP_TIMEOUT_SECONDS
GAMMA_SBAS_WORKFLOW_TIMEOUT_SECONDS
GAMMA_SBAS_TRIAL_ROOT
```
默认工作根：
```text
backend/runtime/sbas_insar_production
D:\production_runtime\sbas_insar_work
```
默认产品根：
@@ -80,6 +81,11 @@ backend/runtime/sbas_insar_production
D:\production_results\timeseries\sbas
```
`GAMMA_SBAS_WORK_ROOT` stores heavy, restartable Gamma intermediate data.
`GAMMA_SBAS_PRODUCT_ROOT` stores lightweight catalog/download packages under
`runs/<run_id>`. The result catalog indexes the product root first and keeps the
work root only as a compatibility fallback.
## 4. 生产流程
用户侧推荐顺序：