Five flight blocks, one surface: catching a datum offset before it reached the drawing

The situation

A site of just under 5,000 hectares is too large to fly in one go. This one was covered in five blocks over several days, producing roughly 22,000 images. Deliverables were straightforward on paper: an orthomosaic and 1 m contours, output in the client’s local grid, for onward submission to their own client on a fixed date.

The part that is never straightforward at this scale is the control. Ground control points were spread across the whole site rather than concentrated, which meant any individual block had only two or three within it. That is normal for a site this size, and it is also exactly the condition under which a systematic error can hide.

What the control check showed

Before building any surface, the reconstruction was compared against the surveyed control. What matters at this stage is not the size of the differences but their consistency.

They were not consistent. At two control points the reconstruction matched almost exactly — within a few centimetres. At three others it sat several metres low.

That distinction decides everything that follows. A uniform difference across all points is a datum question: the whole dataset sits at a constant offset, and a single shift corrects it. Differences that vary from point to point mean something structural, and averaging them produces a surface that is wrong nearly everywhere while appearing acceptable on paper.

The pattern here was neither random nor uniform. It was grouped — some points clean, others out by a similar amount in the same direction. That is the signature of blocks referenced to different starting positions.

The cause

On a site of this size, the base station cannot always stay in one place for the whole survey, and it had been moved between flights. Each flight is georeferenced to whatever the base was set to at the time. If one setup differs — a coordinate entered against a different reference, an antenna height measured to a different point, a position taken as an autonomous fix rather than tied to known control — then every point captured during that flight carries the same bias, while flights on a correctly set base come out clean.

The data itself was sound. It was the reference frame that varied between blocks.

What was done about it

Rather than applying a single average correction across the site, each block was reconstructed and fitted against the control that fell within it, then brought onto a common datum. Contours were derived from the resulting surface rather than from any one block’s own reconstruction, so that the blocks agreed along the edges where they met.

That is more processing than a single pass over the whole site, and on a dataset of this size it is not a trivial amount. It is also the only version of the job that produces contours which tie together.

Why this matters to anyone commissioning this work

A contour drawing looks equally convincing whether or not the blocks beneath it agree. Nothing about a 1 m contour set at first glance tells you that one part of the site sits several metres below where it should. The error surfaces later — when someone draws a section across a block boundary, or ties the survey to something built from it.

The check that catches it is not exotic. It is comparing the reconstruction against the control and looking at whether the residuals are consistent, before committing to a surface. It costs an hour. Skipping it is what turns a reference-frame problem into a deliverable problem.

If you are commissioning large-area drone processing, it is a fair question to ask of whoever is doing it: what were the residuals at the control points, and were they consistent across the site?