InSAR ↔ GNSS / Levelling Validation

Every InSAR report eventually faces the reviewer's question: how do you know the satellite is right? The honest answer is a comparison against independent ground observations — GNSS campaigns, levelling lines, or monitoring wells with vertical benchmarks — and the uncomfortable truth is that most practitioners do this comparison ad hoc in a spreadsheet, with a different method every time. This tool makes the comparison reproducible: it matches each ground observation to its nearest InSAR point within a stated radius, computes residuals, the root-mean-square error, the systematic bias and the residual spread, flags statistically anomalous pairs, and writes the comparison paragraph your report needs in standard, review-ready language.

The tool sits at the verification stage of the workflow, after conversion (GNSS measures vertical motion, so the InSAR side must be vertical velocities, not LOS) and alongside or after hazard classification. As everywhere on this site, both datasets stay in your browser; nothing is uploaded.

When you should use this tool

A monitoring campaign has both InSAR results and co-located GNSS or levelling observations, and the report needs a quantified agreement statement.
You are validating a new processing configuration (different atmospheric correction, different track, different time window) and want an objective, repeatable metric.
A reviewer challenged the credibility of the InSAR results and you need a defensible, standards-aware comparison section in an afternoon rather than a week.

When NOT to use this tool

The InSAR dataset is still in LOS geometry. GNSS vertical velocities compare to vertical InSAR velocities — run the LOS Converter first.
The observations do not overlap in time. Comparing a 2019 GNSS campaign to a 2026 InSAR velocity measures nothing about either; rates must cover a common or strongly overlapping window.
Ground points are kilometres away from any InSAR point. The match radius exists to keep the comparison honest; stretching it to force matches produces confident nonsense.
You expect tool output to replace judgement. Flagged anomalies need engineering interpretation, not automatic deletion.

What RMSE, bias and σ actually separate

The three statistics in the results header answer three different reviewer questions. The systematic bias (mean of InSAR − GNSS residuals) exposes constant-offset mechanisms: reference frame differences between the InSAR solution and the GNSS solution, residual atmospheric signal common to the whole scene, or a levelling datum shift. A bias of a few mm/yr is normal and worth one sentence of explanation; a bias comparable to the deformation signal itself means one dataset is anchored differently and should be de-trended or re-referenced before comparison. The residual σ (the random component, σ² = RMSE² − bias²) reflects point-level agreement: atmospheric turbulence between the paired epochs, phase-noise at the InSAR point, GNSS velocity uncertainty, and real local gradients between the two measurement locations. The RMSE is what reviewers remember — it combines both — so state bias and σ alongside it whenever the report has room for three numbers instead of one.

Anomalous pairs are flagged when the residual departs from the bias by more than k·σ (default k = 2). They are candidates for investigation — an unwrapping error at the InSAR point, a benchmark disturbance, a genuine local deformation feature — never candidates for silent deletion. The conclusion paragraph reports their identifiers precisely so that the report acknowledges them.

Input reference

InSAR side (Data Tray). The tool consumes whatever vertical-velocity dataset the tray holds — normally the output of the LOS Converter. If the tray is empty, the demo button loads and converts the sample scene automatically so you can exercise the full chain.
GNSS / levelling side. A CSV with point identifier, longitude, latitude and vertical velocity (mm/yr); accuracy and survey-date columns are welcome and survive through to the CSV export. Paste straight from Excel or import a file — the header matcher knows the common GNSS export column names.
Match radius. The maximum separation at which an InSAR point may represent a ground observation. 100–200 m is a sane band for velocity comparison over deforming ground; beyond that, real spatial gradients contaminate the residual. Unmatched ground points are reported as such, not silently dropped.
Anomaly tolerance k. The multiplier on σ for the anomaly flag. k = 2 flags roughly the outer 5% of a well-behaved population; raise it if your dataset is small and you only want gross errors to surface.

Step-by-step usage

Load the InSAR dataset (via the LOS Converter, or the demo auto-load here).
Import the GNSS table — file or paste.
Set the match radius and anomaly tolerance, then Run validation.
Read the statistics header, scan the table for flagged rows, and check the 1:1 plot: points sit on the dashed identity line when the two datasets agree; a cloud parallel to it but offset indicates bias; scatter perpendicular to it indicates random disagreement.
Export the pairs CSV for the report appendix and copy the conclusion paragraph into the text. The paragraph names the match radius, the counts, all three statistics, the flagged identifiers and the verification caveat — the section a reviewer will read first.

Common pitfalls & mistakes

Comparing LOS to vertical. The classic. GNSS vertical velocities against unconverted InSAR LOS velocities produce a systematic error of tens of percent that no statistical flourish will repair. Convert first.
Datum and frame mismatch. InSAR velocities are relative to the scene's reference point; GNSS velocities are absolute in a terrestrial frame. A large bias often means the InSAR scene reference is unstable or the GNSS solution embeds regional uplift — re-reference before interpreting.
Time-window mismatch. Velocities from different epochs embed different transients (groundwater cycles, construction). Overlap windows or state the caveat.
Deleting anomalies to improve RMSE. The report must account for every flagged pair. An explained anomaly strengthens the analysis; an unexplained deletion destroys its credibility.
Over-precision. Quoting RMSE to three decimals implies a rigor the method does not have. Two significant figures and an honest σ are more defensible.

Frequently asked questions

How many pairs do I need for the statistics to mean anything?: Rough guidance: below about 8–10 pairs the σ estimate is fragile and the anomaly flag unstable. With a handful of pairs, report residuals pair-by-pair instead of pretending to a distribution.
The bias is large but the σ is small — what does that mean?: The two datasets agree with each other up to a constant offset. Look for reference-frame or datum issues before suspecting the deformation signal itself.
Should I match to the nearest InSAR point even if it is 300 m away?: Only if you can defend that spatial separation is negligible for your deformation pattern. The radius exists precisely to stop the tool from manufacturing agreement.
Can I compare levelling lines (relative heights) instead of GNSS velocities?: Yes, if you convert the levelling increments into rates over the same window and acknowledge that levelling gives relative motion between benchmarks — the InSAR reference point choice then matters.
Why does the tool not weight pairs by GNSS accuracy?: Weighting is on the roadmap. At screening level, unweighted statistics are transparent and reproducible; state the accuracy column in the report if it varies strongly.

Demo dataset & related tools

The GNSS demo table contains 12 synthetic observations paired to the sample InSAR scene with a realistic error budget — run it and compare the RMSE you get against the value stated in the Sample dataset guideLOS Converter and the Hazard Classifier. Companion: the Error Budget calculator, which explains why the σ you measure is what it is.