Cross-validating InSAR with GNSS: the checklist before a deformation map goes in a report

22 October 2026 · about 9 min read

By the senior geotechnical engineer · insarwatch

Every deformation map eventually faces the same question in a review meeting: how do you know? Processing reports and coherence plots answer a different question — whether the measurement is well-made — not whether it is true. The answer to the real question is cross-validation against an independent ground method, and GNSS is the one most projects already have: continuous, precise, and measuring the same ground. Done properly, an InSAR–GNSS comparison is a half-day of work that converts a plausible map into a defensible result. Done carelessly, it produces a residual scatter plot that "confirms" whatever anyone wanted — or fails for reasons that have nothing to do with the InSAR. The difference is almost entirely procedure. This is the checklist, in the order the steps should be done, with the failure modes that show up when a step is skipped.

Before any pairing: three data checks

1. Time overlap. The two datasets must describe the same period. A GNSS solution averaged over 2019–2021 compared against an InSAR stack ending in 2024 does not validate anything — groundwater-driven areas move at different rates in different years, and the comparison will show a bias that is simply calendar. Trim both records to their common window and state the window in the deliverable. Rates fitted over different spans are the single most common source of phantom discrepancies.

2. Reference frame. Both datasets need the same answer to "motion relative to what?" GNSS velocities are conventionally published in a global frame (ITRF) or relative to a specified reference station; InSAR velocities are relative to a reference point the processor chose, often a stable patch selected by the software. If the InSAR reference point itself moves, every InSAR velocity inherits that motion. The fix is to align the frames explicitly — re-referencing the InSAR stack to the neighbourhood of a long-stable GNSS monument, or at minimum checking that the InSAR velocity at the GNSS monument's location is near zero — and to record which point anchored the comparison.

3. Common coordinates and geometry. The pairing step matches points by distance, so both files must live in one coordinate system — WGS84 lon/lat is the workbench's exchange standard, and the batch coordinate converter moves projected exports (UTM, local grids) into it before anything else happens. The geometry check from the previous article belongs here too: GNSS measures its own component, so the InSAR LOS velocities must be converted to vertical first, or the comparison will embed a twenty-percent systematic difference that no scatter plot explains. File-level preparation — column names, units, sign conventions — is what the CSV format specification exists for; five minutes there saves an hour of silent column mismatches.

Pairing points honestly

Validation works by matching each GNSS monument to the nearest coherent InSAR point and comparing rates. The pairing radius is the decision that decides whether the exercise means anything. Pair at 200 m — the default in this workbench's GNSS validation tool — and over flat, steadily deforming ground the assumption that nearby points share the same motion is reasonable. Pair at a kilometre across a gradient — the edge of a subsidence bowl, a railway embankment, a mine influence zone — and the "residual" mostly measures the deformation gradient, not the InSAR's accuracy. The rule of thumb: the pairing radius must be small compared to the length scale over which the deformation field changes. Where the field is steep, shrink the radius and accept fewer pairs; three honest pairs beat thirty contaminated ones.

Point quality matters as much as distance. A GNSS monument on a structure that is itself settling is not a ground-truth anchor for regional motion — it is a deformation measurement in its own right, and pairing it against surrounding ground guarantees a residual. Similarly, an InSAR point on a moving crane rail or a rooftop antenna reports the structure's motion, not the soil's. Prefer pairs where both instruments measure the same object: bedrock outcrops, deep-anchored monuments, building foundations whose own behaviour is understood.

Reading the residuals: three numbers, three stories

With pairs formed, the comparison reduces to three statistics, and each answers a different question. The mean bias (InSAR minus GNSS, averaged over pairs) answers "is there a systematic offset?" — its usual causes are reference-frame misalignment (check step 2), an atmosphere-correlated comparison, or a residual geometry error after conversion. The RMSE answers "how large is the total disagreement?" and mixes bias with scatter; report it with the bias so a reader can see how much is offset and how much is noise. The residual standard deviation — the scatter after removing the bias — answers "does InSAR agree point-by-point once the offset is accounted for?" This is the number that characterises the measurement, and it is the one to carry into the error budget as the empirical total against which the modelled budget (atmosphere, orbit, DEM, decorrelation, geometry) can be sanity-checked: if the modelled budget says 6 mm and the observed residual σ says 18 mm, something in the model — usually atmosphere over relief — is understated.

Flagging individual pairs works the same way as quality control anywhere else: this workbench's default marks a pair anomalous when its residual exceeds a 2σ screening tolerance around the bias. Anomalous pairs are not failures; they are the most informative lines in the table. Every one of them has a cause, and finding the cause is where validation stops being statistics and starts being engineering.

Four failure modes and what each usually means

Failed or ugly validations repeat a small number of patterns. Large bias, small scatter: every pair disagrees by nearly the same amount — this is almost never the InSAR itself; look first at the reference frame alignment, then at the sign convention of one of the exports, then at geometry conversion applied to one dataset but not the other. Small bias, large scatter: on average the datasets agree, but pair-by-pair they do not — suspect the pairing (radius too large for the deformation gradient) or point-type mismatch (structure points paired against ground). Scatter that grows with distance: the residual is measuring the deformation field, not the measurement error; shrink the pairing radius. One track validates, the other does not: with both ascending and descending stacks available, disagreement confined to a single geometry points at that track's processing (an orbit problem, an atmosphere artifact) or at a strong horizontal motion component that one LOS sees and the other barely does — which, on slopes, is a finding in itself, not a nuisance.

When validation fails, diagnose before discarding

The reflexive response to a failed comparison is distrust of the InSAR, but the checklist above shows the more likely order of culprits: reference frames, time windows, pairing distances, point types, geometry conversion. Only after all five are cleared does the measurement itself become the prime suspect — and even then the diagnosis continues: check the coherence landscape around the failing pairs with the site pre-checker, look for decorrelation-driven noise over vegetation or water margins, and re-examine the step flags from the time-series stage, since a single unwrapping artifact can inflate an RMSE for the whole scene. In practice, a "failed" validation that survives this diagnosis intact has usually found something real — a processing defect worth reporting to the provider, or a motion pattern the velocity map was genuinely misrepresenting. Both outcomes are more valuable than the validation passing.

What goes in the report

The validation section that survives review states its own terms: the number of pairs and the pairing radius; the common time window; the reference point used; the sign convention and geometry conversion applied; the bias, RMSE and residual σ; the tolerance used for flagging and the count of flagged pairs; and the disposition of each flagged pair (verified, explained, or excluded with reason). The GNSS validation tool emits exactly this summary block alongside the pair table, and the report generator folds it into the interpretation note. A validation reported in this much detail does not merely support the map — it advertises that the map can be checked, which is what makes readers trust it in the first place.