Aerial Survey Data Quality Control: From Source Files to Final Products

Begin with acceptance criteria

Quality review should follow agreed purposes and criteria rather than a visually attractive result. Specify products, coverage, detail, coordinates, tests, and recipient formats. Separate required outputs from previews and optional derivatives. Without clear criteria, a team can spend time refining appearance while missing the defect that matters to analysis. Build a check sequence covering capture through export. Each finding needs a location, evidence, impact, and response. This makes acceptance traceable rather than a general approval based on one favourable screenshot that may not represent the whole dataset or the user's actual requirements.

Inventory source completeness and session identity

Match images, trajectories, logs, control coordinates, and field records against the session list. Look for missing, duplicated, corrupt, or misassigned files. Check time and equipment identities. A manifest helps verify copies and subsequent changes. For photographs, review sharpness, exposure, and coverage; for LiDAR, review continuity and required supporting inputs. Source problems are often easiest to detect before full processing. If inputs are incomplete, record the affected scope and decide whether provisional processing is useful or likely to create conclusions that cannot be assessed reliably from the available evidence.

Inspect geometry before producing derivatives

For photogrammetry, review camera connections, separate blocks, and weak reconstruction. For LiDAR, inspect trajectories, line agreement, and doubled surfaces. Use profiles and stable objects, not only a top-down display. Preserve before-and-after evidence when correcting problems. Completion without a software error message does not establish geometric quality. Derivatives can look complete despite weak inputs. Early geometry checks prevent a large set of outputs needing replacement together after users discover a fundamental problem while measuring the delivered product. Corrections should address a documented cause rather than merely improve the appearance of selected examples.

Test references and positions independently

Confirm horizontal and height references, units, and transformations against project records. Assess position using checkpoints not used to fit the solution. Keep these results distinct from internal control residuals. Review distribution, surface conditions, sample count, and spatial patterns. Small pixels or dense points do not prove absolute accuracy. Record technical reasons and checks for excluded references. Assessment also depends on the reference measurements' own quality. Users need to know what was demonstrated and what remains untested rather than receive an isolated numerical summary whose applicability to the full site is unclear.

Verify the meaning of each output

Orthomosaics, DSMs, DTMs, classified clouds, and meshes serve different purposes. Names must match actual processing and represented surfaces. A raster retaining canopy should not be labelled ground without suitable support and treatment. Review water, moving objects, shadows, and missing areas. Inspect artefacts introduced by classification or edits. For contours and volumes, trace the assumptions that influence calculations. Similar-looking files can answer different questions, so product-meaning checks help prevent use outside context. A valid elevation band is not, by itself, evidence that its values describe the surface required for the user's analysis.

Look closely at edges and joins

Block boundaries, tile joins, and coverage edges often contain problems absent from the central preview. Check gaps, abrupt elevation changes, unusual colour, and inconsistent classes. Use suitable surrounding support before clipping outputs. Reinspect combined datasets because merging can introduce grid or reference issues not apparent in isolated files. Map findings with source identities. After fixing one tile, review its neighbours. Overall quality depends on relationships between parts, not merely each file opening successfully. This review also provides evidence that a correction did not shift a problem to an adjoining section of the delivered area.

Test exported packages in the destination environment

Open sample products in the recipient's application or another relevant environment. Check coordinates, units, NoData, attributes, colour, and reading performance. Ensure lightweight previews are not confused with accepted analytical products. Test tile indexes and portable project links for large datasets. Confirm embedded metadata remains readable and supporting documents accompany the data. Export faults can arise even when the original processing project is correct. Package testing preserves the quality already achieved instead of losing it through an unsuitable format, folder structure, compression setting, or omitted auxiliary file during the final transfer.

Keep corrective decisions explicit

Each finding should have a clear status: corrected, awaiting additional observations, accepted within stated limits, or unresolved. Identify responsibility and retest evidence without burdening users with irrelevant detail. Do not close an issue merely because a deadline approaches. Where a limitation is accepted, retain the agreed scope and relevant approval under project procedures. Link decisions to exact dataset versions. This supports later review by another team and distinguishes changed data from changed interpretation. A usable quality history should not depend on private conversations or a processor remembering why a particular feature was treated differently.

Use a layered review sequence

Check source files in the field, review early geometry, assess position and product meaning, then test the exported package. Representative samples find problems early, while final review still covers the scope required by acceptance criteria. Adapt the checklist to each NiVO payload's data characteristics without losing traceability. The outcome is more than completed processing: it is information recipients can open, assess, and use with a clear understanding of supporting evidence and limitations. A layered approach also helps direct effort to the stage responsible for a finding, reducing repeated downstream work that cannot fix an upstream omission.

Illustrative scenario: a correct project exports an incomplete package

Consider a hypothetical survey whose processing project passes its internal review. The recipient then opens the exported package and finds that a classified cloud displays correctly but lacks an attribute required for selection. A linked GIS project also points to a folder that exists only on the processor's workstation. The team does not treat these issues as proof that the capture itself failed, nor dismiss them because the original project works. It separates source quality, processing quality, and delivery usability. The accepted product list and intended analytical tasks determine which missing information must be restored before handover can be considered complete.

A representative export is opened in the recipient environment, and the reviewers compare point attributes, coordinate interpretation, coverage, and relevant values with the main version. Portable links are tested from a separate copy rather than from the working folder. Any preview is labelled so it cannot substitute silently for the analytical dataset. The corrected export is assigned an explicit version, and the quality record identifies the original findings and the evidence used to close them. Other products sharing the same export route are checked where the discovered issue gives a concrete reason to expect a related problem.

Acceptance is based on the package users will receive, not solely on successful processing or a polished screenshot. The final index links each report to the matching dataset and supporting metadata. This hypothetical case demonstrates why quality control follows the information through transfer and reopening. It preserves a useful distinction between a valid source model and an incomplete delivery, directing the repair towards the actual failure while ensuring recipients can perform the agreed work without access to hidden local files or undocumented application settings.