Workflow manual — a full screening campaign

Who this page is for: the engineer running an actual campaign, who knows what InSAR is (the basics page covers that) and needs the operational sequence — what to prepare, what to run in which order, what to check at each gate, and what the deliverables are. What it adds over the workflow overview: the overview describes the pipeline; this manual describes running it, including the decisions that are yours rather than the tools'.

Before you open the workbench

Three things must exist outside the tools, because no tool can invent them. A defined engineering question — "is the embankment between chainage 42 and 55 deforming differentially?" is a campaign; "what does InSAR say about this area?" is not. The question determines the criteria package, the neighbour radius, the observation window and the report scenario at the far end. The processing outputs from your InSAR software: a velocity layer with per-point incidence and azimuth geometry, exported per the CSV specification, plus time series if the campaign needs temporal characterisation. Ground observations if you have them — the validation stage is what converts a plausible result into a defensible one, and arranging benchmark access is a pre-campaign task, not a post-processing one. With those three in hand, budget half a day for the first full pass; subsequent campaigns on the same site take an hour.

Phase 1 — Pre-check (Site Suitability tool)

Enter the bounding box around the assets, the dominant land cover, climate class, the maximum slope from your DEM, your intended sensor band, and the deformation target. Read the flags before the score: each flag names a mechanism and a countermeasure. Record the outcome in the project file either way — a documented pre-check protects the campaign if the results later disappoint, and the Markdown export exists for exactly that. Decision point: Poor score with unfixable red flags means stopping or changing sensor here is cheaper than a doomed processing run.

Phase 2 — Conversion (LOS Converter)

Import the velocity table — file or paste; the header matcher handles the common exports. Verify the sign convention on one known area before trusting the batch: pick a point where the ground truth is intuitively clear and confirm the sign points the expected way. Convert, and sanity-check the summary: the velocity range should be consistent with regional knowledge. The converted points now live in the Data Tray. Quality gate: sign convention confirmed; incidence angles actually vary across the table rather than being one copied constant (unless the site is genuinely small).

Phase 3 — Spatial screening (Hazard Classifier)

Select the criteria package matching the asset, and — the decision that is yours — set the neighbour radius to the structural span you care about, not the default for its own sake. Run, then read in this order: the distribution bar chart (is the split plausible?), the map (do flagged points cluster along the asset or scatter randomly?), and only then the table. Check the neighbour column for isolated points, whose classes rest on the velocity safeguard alone. Export the CSV for the record and the KML for spatial context. Quality gate: every class quoted in future text carries its package name and radius.

Phase 4 — Temporal characterisation (Time-series tool)

If the campaign imported a time series, run the six-step check here: which flagged zones are accelerating, which are steady, and whether any step flags coincide with known processing events. Thresholds are yours to tune — record the final values. A common pattern worth learning on the demo: acceleration flags that track wet seasons are seasonal signals wearing an acceleration costume; widen the threshold or annotate the seasonality rather than escalating blindly.

Phase 5 — Ground truth (GNSS Validation)

Load the observation table, set a match radius that is honest about spatial gradients, and run. Read the three statistics separately — bias is a reference-frame conversation, σ is a noise conversation, RMSE is what the reviewer remembers. Investigate flagged pairs before the report, not after a reviewer finds them. Copy the generated conclusion paragraph into the report; it already contains the standardised caveat language. Quality gate: every anomalous pair accounted for in writing.

Phase 6 — Uncertainty statement (Error Budget)

Replace the screening defaults with values justified by your processing: archive length, correction models applied, coherence levels observed. The pie chart tells you which term dominates; the GNSS-measured σ from Phase 5 is your reality check — if it exceeds the prediction substantially, an assumption is wrong, usually the atmosphere. Export the Markdown summary for the quality-assurance section.

Phase 7 — Reporting (Report Generator)

Choose the scenario matching the client's vocabulary, fill the identification fields, write the key observations in your own words, and generate. The injection pulls the Data Tray statistics; the limitations and verification language arrives standardised. Edit the placeholders — they are marked — and attach the CSV/KML exports as appendices. The final professional act is yours: the generator writes structure, the engineer owns conclusions.

Troubleshooting the common stalls

Four stalls account for most lost hours. The tray is empty at the classifier: the Data Tray lives per browser tab — run the whole chain in one tab, or re-import. The validation shows far fewer pairs than benchmarks: the match radius is smaller than the real point separation, or the two datasets' coordinates are in different units or order; check the scatter. The classification looks uniformly Stable: the velocity column may still be LOS rather than converted vertical, or the sign convention flipped — both surface as compressed ranges in the converter's summary. The report statistics look stale: the injection happens at generation time; you re-ran the analysis after generating, so regenerate. Each stall has a signature in the tools' own summaries, which is why the habit of reading summaries before tables pays for itself within the first campaign.

Campaign hygiene

• One question per campaign. Mixing asset types in one run blurs the criteria choice; run separate campaigns per asset class.
• Record every threshold. Radius, k-factor, acceleration and step thresholds are part of the method; a result without them is not reproducible.
• Re-generate after re-analysis. Stale injected statistics are the classic audit finding; the report is generated from the tray, so regenerate whenever the tray changes.
• Keep the browser tab alive through a phase. Tray data lives in memory; closing the tab between tools means re-importing. Complete a phase, export, then close if you must.
• Archive the exports, not the browser state. CSVs, KML, Markdown reports and the pre-check PDF are the campaign record; the tab is not.

Scheduling considerations: when each phase should run

The seven phases are ordered by data dependency, but they also interact with the calendar, and two scheduling rules prevent the most common timing mistakes. First, respect the seasonality window in rate fitting: a rate fitted over less than a full year absorbs the seasonal wave into its slope, so whenever the available record is shorter than twelve months, state the window on every fitted rate and avoid comparing rates fitted over different spans — a January-to-December fit against a March-to-February fit can differ by several mm/yr on the same ground with no real change. Where the project calendar forces a short window, prefer comparing second-half against first-half rates within the same record (the time-series tool's acceleration split) rather than absolute rates across records. Second, run the ground-truth phase close in time to the InSAR stack it validates: a GNSS campaign averaged over a different year validates a different process, and in groundwater-driven areas the discrepancy will be calendar, not measurement. When new GNSS results arrive mid-campaign, re-run the validation phase and regenerate the report rather than merging statistics by hand.

One further habit: schedule the pre-check before committing field resources, not after. The pre-check's land-cover flags exist precisely because discovering a C-band decorrelation problem after the survey is the most expensive possible order of events — the cheapest failure is the one caught before the mobilisation.

Where to go next

Rehearse the entire sequence on known data with the sample dataset before the first real campaign — ten minutes there buys fluency here. The basics page backfills concepts, and each tool's own page documents its inputs, outputs and pitfalls in depth.