LOS to Vertical Deformation Converter

The single most common interpretation error in InSAR engineering practice is reading a line-of-sight velocity map as if it were vertical settlement. It is not. The satellite measures ground motion projected onto the radar viewing direction, and for Sentinel-1 that direction is tilted roughly 30–46° away from vertical. A genuine vertical subsidence rate of 12 mm/yr appears as only about 9.5 mm/yr in the LOS measurement — a silent 20–30% underestimate if you report the LOS number directly. This tool corrects that projection for you: it converts LOS velocities into vertical rates (and, where meaningful, into along-slope horizontal rates), quantifies the projection uncertainty, and prepares clean point datasets for hazard classification, GNSS comparison and reporting.

The tool is built for geotechnical and surveying engineers who receive velocity outputs from MintPy, LiCSBAS, HyP3 or insarmaps and need defensible, geometrically correct numbers in a report. Everything runs locally in your browser: paste your points, load the demonstration dataset, or type a single observation — nothing ever leaves your machine.

When you should use this tool

You have a LOS velocity field (mm/yr) from any InSAR processor and need vertical rates for a settlement, subsidence or asset-monitoring report.
You want to compare InSAR results against GNSS or levelling observations of vertical motion — the comparison is only meaningful after this conversion.
You need a first estimate of how much of the observed motion could be explained by downslope movement on a slope, and whether the slope orientation even makes that motion visible to the satellite.
You are preparing point datasets for the Hazard Classifier or the GNSS Validation tool and want the conversion done once, consistently, for every point.

When NOT to use this tool

You need a full 3D decomposition (east–west–up). One viewing geometry cannot resolve three components; you need at least ascending and descending tracks, ideally more — use this tool to process each track, then combine them offline.
The dominant motion is clearly horizontal, such as an active translational landslide or a strike-slip-related displacement field. The pure-vertical assumption would mislead you; the along-slope estimate is only as good as its assumption.
Your input is unwrapped phase, coherence or raw SLC data rather than a velocity layer. Preprocess with MintPy / LiCSBAS / HyP3 first.
You are producing an official geohazard assessment. This is a screening aid; the numbers support preliminary interpretation only and require field verification by qualified professionals.

Core theory & engineering background

Interferometric radar measures displacement along the unit vector pointing from the ground point towards the antenna. That vector has two useful projections: a vertical one, cos θ, where θ is the incidence angle measured from vertical, and a horizontal one, sin θ, oriented along the horizontal azimuth of the beam. Any ground deformation vector therefore contributes to the measured LOS velocity according to:

v_los = v_vertical · cos θ + u_slope · sin θ · cos(δ − α)

where δ is the downslope aspect angle and α the horizontal LOS azimuth. Two practical consequences follow. First, the pure-vertical estimate is simply v_los / cos θ — with a Sentinel-1 mid-swath incidence of 38°, vertical rates are about 27% larger in magnitude than LOS rates, which is exactly why reporting LOS values as settlement systematically understates the problem. Second, the slope term vanishes when cos(δ − α) = 0: a slope that dips away from (or directly towards) the radar is blind to along-slope motion. That is why one viewing geometry can never separate the two components, and why the tool flags the slope projection factor whenever it falls below a reliable threshold. The standard engineering response is to process both ascending and descending tracks and solve the two-observation system; this tool prepares each track consistently so that combination is possible.

Uncertainty propagates the same way. If the incidence angle carries an uncertainty dθ (metadata geometry is excellent, but DEM registration and local slope deviations make 0.3–0.5° a realistic planning figure), the vertical estimate inherits d(v_v) = |v_los · tan θ| · dθ. Note the tan θ growth: the error contribution rises as you move toward the far range of the swath, which is worth a sentence in any report that claims millimetre-level precision.

Input field definition reference

LOS velocity (mm/yr) — the velocity column from your processor. MintPy exports it as velocity, LiCSBAS-derived tables often as los_vel, insarmaps CSVs carry a similar column. The tool assumes the common InSAR convention: negative means motion away from the satellite (for a descending-looking geometry over this hemisphere, typically subsidence), positive means motion towards it. If your export uses the opposite sign, multiply the column by −1 before import; mixing conventions is the fastest way to produce an inverted risk map.
Incidence angle θ (°) — measured from the local vertical. Take it from the processing geometry file (MintPy geo_incidence, LiCSBAS geom_inc) rather than assuming one value: it varies systematically across the swath from about 30° near the near range to about 46° at the far range of an IW scene. A single mid-swath value is acceptable for screening work on small sites.
LOS azimuth α (°) — the horizontal azimuth of the ground-to-satellite line-of-sight direction. Read it from your processing metadata rather than from memory: different software packages report antenna heading or LOS azimuth with different orientation conventions, and a 180° flip mirrors the slope-sensitivity term. As a sanity check, the two Sentinel-1 viewing directions put this value in roughly the 250–290° band for one track direction and 70–110° for the other at mid-latitudes.
Slope β and aspect δ (°) — local terrain geometry under the point, from your DEM. They only influence the along-slope estimate and the projection factor, not the pure-vertical result.
Incidence uncertainty dθ (°) — planning value for the error column. 0.5° is a reasonable screening default.

Step-by-step usage

Start with the single-point form: enter the five geometry values for one representative point and press Compute. The vector diagram updates live so you can see how the LOS beam, the slope face and the resolved components relate.
For real work, use Load demo dataset (87 points, four deformation regimes) or import your own CSV — either a file or a direct paste from Excel. The header matcher recognises the common MintPy / LiCSBAS / insarmaps column names automatically and tells you exactly which required column is missing if it is not.
Every converted point lands in the Data Tray at the bottom right. From there the Hazard Classifier and the GNSS Validation tool consume the same points without re-importing anything.
Export the results table as CSV for your records, or the geometry diagram as SVG for the report appendix.

Output interpretation guide

The results table reports, for every point: the vertical velocity under the pure-vertical assumption with its propagated uncertainty; the along-slope velocity under the pure-slope assumption (blank when unobservable); and the slope-to-LOS projection factor. Read them as a pair of bounding scenarios, not as independent truths: the real motion is generally some mixture, and single-track data cannot tell you the mix. The orange dashed arrow in the geometry diagram shows the along-slope scenario; the teal arrow shows the vertical scenario. A projection factor near zero is the situation to take seriously — it means the observed LOS motion on that slope is geometrically inconsistent with downslope movement, so what you see is either vertical, atmospheric, or unwrapping error. Points flagged as poorly observable deserve an explicit caveat in the report text.

Common pitfalls & mistakes

Sign-convention mixing. Most processors use negative = away from satellite, but not all exports state it. One flipped column inverts the deformation pattern. Always sanity-check one known subsiding area against a positive/negative expectation before trusting a batch.
Heading reported as LOS azimuth. Antenna heading and ground-to-satellite LOS azimuth differ by roughly 90°. Feeding a heading value into the azimuth field corrupts the slope-projection term. Check your software's definition; when in doubt, verify against a known viewing geometry.
One incidence angle for the whole swath. Using 38° for points that sit at the far range (where θ approaches 45°) shifts the vertical estimate by several percent. For long, narrow projects along-track this is negligible; across-track it is not.
Unit drift. Reports mix mm/yr and cm/yr freely. Convert once, at import, and state the unit in every table caption.

Frequently asked questions

Why is my vertical rate larger than the LOS rate?: Because division by cos θ (less than one) amplifies the magnitude. A −9.5 mm/yr LOS signal at 38° incidence corresponds to −12.2 mm/yr of vertical motion. The LOS number was the projection all along.
Can I get east–west motion from this tool?: Not from one track. You need ascending and descending velocities (and ideally an azimuthal spread) to solve for multiple components. Process each track here, then combine.
Which assumption should I put in the report — vertical or along-slope?: State both if the site is sloping, with the projection factor as context. For flat sites the two scenarios converge and the pure-vertical estimate stands on its own.
Does the tool use my data anywhere else?: No. All computation happens in your browser's JavaScript and the points vanish when you close the tab. There is no upload path in the code at all.
What incidence-angle uncertainty should I assume?: 0.3–0.5° covers typical DEM-registration and local-slope effects for screening purposes. Tighten it only if you have verified the geometry per point.

Demo dataset

The demonstration dataset — 87 points covering stable, slow, accelerating and outlier behaviour — is described in detail in the Sample dataset guide

Related tools

Next steps in the workflow: the Subsidence Gradient & Hazard Classifier turns these vertical rates into risk classes; the GNSS Validation tool checks them against ground truth; the Error Budget calculator quantifies the uncertainty statement your report will need.