chore: initialize insar management system v2

2026-04-14 13:16:01 +08:00
commit ecc72ec9cd
361 changed files with 2142522 additions and 0 deletions
@@ -0,0 +1,140 @@
+# Phase 0 Stack Findings
+
+Updated: 2026-04-03
+
+## Confirmed
+
+- Official stack tooling exists in the `isce2` env:
+  - `/home/administrator/miniconda3/envs/isce2/share/isce2/stripmapStack`
+  - `/home/administrator/miniconda3/envs/isce2/share/isce2/topsStack`
+- `stackStripMap.py` exists and is the stripmap stack entry point.
+- `prepStripmap4timeseries.py` exists in the official `stripmapStack` toolset.
+- `stackStripMap.py` expects:
+  - an SLC root directory via `-s/--slc_directory`
+  - a DEM via `-d/--dem`
+  - an optional reference date via `-m/--reference_date`
+  - temporal and baseline thresholds
+- The script scans date subdirectories under the SLC root.
+- Default behavior looks for `<date>.raw` inside each acquisition directory.
+- With `--nofocus`, it instead looks for `<date>.slc`.
+- Deeper code inspection confirms:
+  - `topo.py` opens `<date>/data`
+  - `geo2rdr.py` opens each secondary `<date>/data`
+  - `refineSecondaryTiming` uses both `<date>.slc` and the acquisition directory as metadata roots
+
+## Important implication
+
+Official stack processing expects a stack-style input layout such as:
+
+```text
+SLC/
+  YYYYMMDD/
+    YYYYMMDD.raw
+```
+
+or, when data are already focused:
+
+```text
+SLC/
+  YYYYMMDD/
+    YYYYMMDD.slc
+    YYYYMMDD.slc.xml
+    data
+```
+
+This is different from the current repository's custom LT-1 single-pair production flow.
+
+## Time-series bridge signal
+
+- `prepStripmap4timeseries.py` takes:
+  - pair/interferogram directories
+  - baseline directory
+  - geometry directory
+  - shelve metadata directory
+- The script writes `.rsc` sidecars and explicitly references `pysar`-style downstream usage.
+
+This is useful because it confirms the official stripmap stack toolset already contains a bridge from stack outputs toward time-series preparation.
+The weak point is still the LT-1 stack input/preparation stage, not the existence of a downstream time-series bridge.
+
+## Existing repo bridge signal
+
+The repository's current LT-1 single-pair pipeline already proves one important thing:
+
+- `stripmapApp.py` can be driven with:
+  - `sensor name = LUTAN1`
+  - direct `tiff` input path
+  - direct `orbitFile` XML path
+
+See:
+
+- `backend/app/isce2_pipeline/run_lt1_dinsar_pipeline.py`
+
+The generated XML writes:
+
+- `Reference -> tiff`
+- `Reference -> orbitFile`
+- `Secondary -> tiff`
+- `Secondary -> orbitFile`
+
+This suggests a promising adapter direction:
+
+- do not try to pretend LT-1 is ALOS or another officially prepared raw sensor
+- instead, explore generating LT-1-aware stack configs directly from:
+  - scene `tiff`
+  - scene `meta.xml`
+  - converted orbit XML
+
+That does not prove the official stack driver will accept this without modification.
+But it is the strongest current indication for how a custom LT-1 `stack-prep` layer should be shaped.
+
+## LT-1 / LUTAN1 signal so far
+
+- ISCE core does include a `Lutan1.py` sensor module.
+- But no direct `lutan` match was found in the `stripmapStack` helper scripts.
+- The `stripmapStack` README examples and preparation hints mention:
+  - `prepRawALOS.py`
+  - `prepRawSensor.py`
+- The README explicitly states automatic raw-data preparation support is currently oriented to:
+  - ALOS
+  - CSK
+- `prepRawSensors.py` automatic raw detection currently covers:
+  - Envisat
+  - ERS CEOS
+  - ERS ENV
+  - ALOS1
+  - CSK
+- `prepSlcSensors.py` automatic SLC detection currently covers:
+  - Envisat
+  - ALOS1
+  - CSK
+  - RSAT2
+  - TSX/TDX
+- No LT-1 or LUTAN1 hook was found in these official stack preparation scripts.
+
+## Interim conclusion
+
+Current evidence suggests:
+
+- ISCE2 core can parse LT-1/LUTAN1 at the sensor level.
+- Official `stripmapStack` tooling is present.
+- But the official stack preparation helpers do not currently advertise LT-1/LUTAN1 support.
+- There is no direct evidence yet that LT-1 can be fed into the official stack helpers without an adapter step.
+- `--nofocus` does not remove the need for acquisition metadata preparation.
+  - It still needs a per-date `data` shelve and an ISCE-style `.slc` image.
+
+This means the working assumption should be:
+
+- `LT-1 stack via official stripmapStack` is possible but unproven
+- an LT-1-specific stack preparation or conversion layer is required unless an existing hidden tool can materialize `data` + `.slc` directly for LUTAN1
+
+## Next checks
+
+1. Implement a dry-run LT-1 stack-prep workspace generator against the selected sample manifest.
+2. Design a scene materializer that transforms one LT-1 scene into:
+   - `YYYYMMDD.slc`
+   - `YYYYMMDD.slc.xml`
+   - `data`
+3. Decide whether that materializer should:
+   - call ISCE/LUTAN1 directly, or
+   - reuse parts of the existing pair pipeline
+4. After materialization is proven, run `stackStripMap.py --nofocus` on one tile-level stack