Strip overlap is one of those processing stages everyone agrees is good and almost nobody looks at twice. The trouble is that a clean alignment can sit on top of an underlying problem and never surface it until the cloud meets independent ground control. Knowing what alignment actually fixes — and what it doesn't — is the difference between a defensible capture and one with a hidden bias.
In the processing pipeline article we mentioned strip alignment as stage 4. In the boresight calibration article we mentioned overlap discrepancy as the diagnostic for boresight quality. This article is the dedicated walkthrough — what strip alignment actually does, what problems it legitimately fixes, what it can't, and the over-fitting trap where the alignment looks clean but the cloud is quietly being warped to match noise.
A single drone flight strip is constrained in width by the sensor's field-of-view and flight altitude. A typical configuration produces a 100–300 m swath at 80–120 m AGL. Any project larger than that swath gets covered by multiple parallel strips.
Adjacent strips are flown with lateral overlap — typically 25–60% — so each piece of ground is captured by at least two strips from different sensor positions. The overlap is what makes alignment possible: the same physical ground in two strips should produce identical 3D coordinates. Where it doesn't, the alignment software can fit a transformation that reconciles them.
Overlap also provides redundancy. A strip with poor GNSS for 30 seconds doesn't have to be re-flown if the adjacent strip covered the same area cleanly — the bad section can be replaced by the good neighbour.
The standard alignment workflow:
1. Identify overlap zones. For each pair of adjacent strips, the software computes the bounding-box intersection and identifies the region where both strips have returns.
2. Find tie features. Within the overlap zone, the software identifies geometric features visible in both strips — building corners, hard surface edges, distinct trees, anything with strong geometric signature. These become the "tie points" used for alignment.
3. Compute discrepancy. For each tie feature, the software measures the offset between its position in strip A and its position in strip B. If alignment is perfect, the offset is zero; in practice it's typically a few millimetres to a few centimetres.
4. Fit a transformation. The software solves for the rigid transformation (translation + rotation) of one strip relative to the other that minimises the aggregate offset across all tie points. The fit is typically global per strip — one transformation per strip applied uniformly.
5. Apply and report. The fitted transformations are applied to each strip. The post-alignment overlap discrepancy is reported per strip pair as the QA signature.
Software in this space: TerraScan + TerraMatch (the commercial gold standard), LASTools (with lasalign / lascontrol), and the manufacturer-specific tools shipped with most professional sensors.
Five real problems that strip alignment addresses well:
Small boresight residuals. Even with good calibration, residual boresight error of ~0.005° remains. Strip alignment absorbs this through per-strip orientation adjustments.
GNSS solution drift across the flight. Long flights see the trajectory solution wander slightly as satellite geometry changes. Alignment adjusts per-strip position to absorb the drift.
IMU bias drift. IMU gyros and accelerometers exhibit slow bias drift over flight time. Per-strip orientation adjustment absorbs the resulting trajectory drift.
Sensor temperature variation mid-flight. Long flights from cold start to thermal equilibrium see small sensor recalibration shifts. Alignment per strip absorbs them.
Lever-arm vibration. The mechanical arm between the IMU and the sensor flexes microscopically under flight loads. The average flex shows up as a small systematic per-strip offset that alignment cleans up.
For all five, alignment is the right tool — fast, predictable, non-destructive to underlying truth.
Three problems that alignment will paper over rather than resolve:
Wrong absolute datum tie. If the GNSS solution is consistently off by 50 mm because the base station's own coordinate was incorrect, all strips are off by the same 50 mm. The overlap zones agree perfectly with each other (because they share the same error); alignment finds nothing to fix; the cloud is internally consistent and absolutely wrong.
This is one of the most common alignment-hides-problem patterns. The diagnostic isn't alignment — it's independent ground control checkpoints.
Boresight off by more than ~0.1°. Strip alignment can absorb small boresight errors through per-strip rotations. Large boresight errors require a non-rigid transformation per strip — different angles applied at different ground positions — which is what the software ends up fitting. The result has small overlap residuals but warped geometry: the cloud no longer represents the real ground accurately.
The signature is a non-trivial per-strip rotation being applied during alignment. Worth checking the strip-transformation log.
Strip-to-strip systematic drift larger than expected. A sensor that warms up significantly between flight strips may have different effective boresight in each strip. Alignment can fit each strip independently, but the result is a series of strips each internally consistent and externally disagreeing — patched together by the alignment but not geometrically coherent at the cloud level.
The signature is alignment fitting unusual per-strip adjustments. Worth investigating before accepting the result.
Strip alignment has the same statistical risk as any fitting problem: with enough parameters, it can fit the data arbitrarily well — including fitting the noise.
The classical over-fit signature:
What happened: the alignment software found a transformation that matched the overlap noise pattern, in the process warping the true geometry. The strips now agree with each other perfectly; they're both wrong in the same way.
Modern pipelines have safeguards (regularisation, limits on per-strip parameter ranges, validation against tie patches with known geometry). But the trap is real and worth understanding.
A clean strip alignment looks like this:
| Metric | Healthy range | | ----------------------------------- | ---------------------- | | Pre-alignment overlap RMSE | 20–50 mm typical | | Post-alignment overlap RMSE | 5–15 mm engineering | | Per-strip translation applied | Under 100 mm | | Per-strip rotation applied | Under 0.02° | | Independent checkpoint residuals | Match overlap residuals|
The last row matters most: post-alignment overlap residuals should match independent checkpoint residuals to similar order. If overlap is 5 mm and checkpoints are 30 mm, alignment is hiding a problem — the cloud is internally consistent but absolutely off.
A QA pack with both metrics reported and similar in magnitude is a healthy capture. A QA pack reporting only overlap with no checkpoint comparison is incomplete.
Patterns to watch for:
Pre-alignment discrepancy much larger than expected (over 100 mm RMSE). Indicates upstream problems — boresight, PPK trajectory, sensor mounting — that the alignment is being asked to clean up. Worth investigating the source rather than accepting the alignment.
Post-alignment discrepancy much better than checkpoints. Symptom of over-fitting or hidden datum error. The alignment made the cloud internally consistent without making it absolutely accurate.
Large per-strip transformations being applied. Translations over ~200 mm or rotations over ~0.05° suggest something larger than expected drift — could be legitimate (e.g., a cold-start strip vs warm-flight strips) or could be hiding a problem. Worth confirming the cause.
Systematic spatial pattern in checkpoint residuals after alignment. If residuals are predominantly positive in one part of the project and negative in another, the alignment fit might have introduced a tilt to absorb a systematic error elsewhere. Compare to pre-alignment residuals to see whether alignment improved or transferred the problem.
For projects where alignment quality matters, two things to specify at scoping:
1. Report pre-AND-post alignment overlap discrepancy — not just post-alignment. The before-and-after delta shows how much work the alignment did, which is itself diagnostic.
2. Compare alignment residuals against independent checkpoints — not just against the overlap zones. The comparison surfaces whether alignment achieved accuracy or just internal consistency.
And one thing to look for in the QA pack:
The per-strip transformation log showing the translation + rotation applied to each strip. Small values suggest clean underlying capture; large values suggest something the alignment was working hard to fix.
Strip alignment is a legitimate processing stage that handles five real problems (small boresight residuals, GNSS drift, IMU bias drift, sensor temperature drift, lever-arm vibration). It can also paper over three different problems (wrong absolute datum tie, large boresight errors, large strip-to-strip drift) in ways that look clean in the alignment metrics and surface only at independent ground control.
The QA pack signature of healthy alignment: pre-vs-post overlap discrepancy reported, post-alignment discrepancy matching independent checkpoint residuals, modest per-strip transformations applied. Anything departing from those is worth investigating before accepting the deliverable.
If you're reviewing a capture's QA pack and only the post-alignment overlap residuals are reported, ask for the rest. The picture isn't complete without it.
The QA pack shipped with every engineering-tier capture we run reports both pre-and-post overlap discrepancy AND independent checkpoint residuals. Tell us your acceptance criteria — we'll meet them in the pack rather than the executive summary.
The upstream cause of the small boresight residuals that strip alignment legitimately fixes — and the large boresight errors that strip alignment papers over.
The independent checkpoint residuals that distinguish clean alignment from one hiding an upstream problem.