Custom Engineering · Scenario Customization

Custom Survey Data Acquisition Systems

Survey system customisation is mostly about standardising the acquisition so the outputs are comparable across operators and across months.

2 of 10Method note

Overview

Encode the acquisition parameters into the workflow so they cannot be varied by accident.
Build the control and check-point routine into the process, not into an individual's habits.
Define the deliverable specification — GSD, overlap, datum, tile scheme — before writing any software.
Plan how the data leaves the site: volume, connectivity and who handles it.

Survey customisation is usually about the deliverable, not the aircraft

Survey and mapping is the most standardised thing an aircraft does. Flight patterns, overlap, ground sampling distance and georeferencing are well understood, and the aircraft side rarely needs customising. What needs customising is almost always the specification of the output and the discipline that makes successive epochs comparable.

That means the custom engagement begins with four numbers: area, required ground sampling distance, accuracy target and the coordinate system and datum the deliverable must be in. Those four determine the sensor, the altitude, the overlap and the georeferencing approach, and they are what make the difference between a dataset that can be used and one that can only be looked at.

It also means the engagement should be explicit about what is not being delivered. A survey configuration has real limits — what it can resolve, what accuracy it achieves under what conditions, and which surfaces it reconstructs badly. Stating those limits in the requirement is what prevents the mismatch being discovered at delivery.

Where customisation actually happens

The first place is the acquisition standard itself. Programmes that will repeat — monitoring, progress tracking, change detection — need a documented specification: geometry, overlap, ground sampling distance, sensor, season, time of day and georeferencing method, all fixed and all written down. Our custom data acquisition standards work exists to produce that document, and it is the single artefact that most improves repeatability.

The second is the sensor configuration. Where the deliverable is a surface under vegetation, a LiDAR payload is required and photogrammetry will not substitute. Where it is façade or structure detail, oblique capture is required alongside nadir. Where it is vegetation condition, multispectral enters. These are deliverable-driven decisions, and getting them wrong is expensive because it is discovered after acquisition.

The third is the georeferencing and validation approach, which is where survey quality is actually determined. Direct georeferencing, ground control, or a hybrid; calibration discipline; and verification against independent check points. Our test and verification methods note describes how we structure it.

Making epochs comparable over time

Survey data compounds in value only if successive epochs can be differenced, and comparability is a design property rather than a processing fix. It requires the same sensor, the same geometry, the same season and growth stage, the same georeferencing approach, and a referencing scheme that does not depend on one person's knowledge.

Consistency is cheap to specify and expensive to retrofit. A programme that acquires its first epoch without deciding these things will find that its second epoch is not comparable, and the fix is to re-fly the first. Deciding them at the start costs a conversation; deciding them later costs a survey.

Where epochs are managed across years and across staff changes, the management discipline matters as much as the acquisition discipline. Our multi-epoch survey data management note covers how we structure that, and on-premise data management covers the case where the data must stay within the client's own infrastructure.

Acceptance for survey configurations

Acceptance should be stated as measurable criteria agreed before the pilot: achieved ground sampling distance, horizontal and vertical accuracy verified against independent check points, completeness of coverage, and the absence of reconstruction gaps in the areas that matter. These are checkable, and they are what makes an acceptance conversation a measurement rather than an argument.

Processing and delivery deserve criteria too: the output format, the coordinate system, the delivery time after acquisition, and what happens when a sortie fails verification. A configuration that produces excellent data in an unusable format has not met the requirement.

Where automated analysis is part of the deliverable — change detection, volume estimation, progress comparison — its acceptance should be stated separately and conservatively, as what it flags for review rather than as an accuracy claim. Our AI performance acceptance note covers how we write that.

Starting a survey engagement

The path is: state the four output numbers; decide the sensor from the deliverable rather than from capability; fix the acquisition standard in writing; agree the georeferencing and verification approach; then run a pilot epoch with agreed acceptance criteria.

Where a client already has an acquisition standard, we work to it rather than replacing it, and the engagement reduces to confirming that the configuration meets it and that the output matches the receiving system.

Send your area, required ground sampling distance, accuracy target, coordinate system, terrain profile and receiving system to our engineering team. We will propose the sensor and acquisition standard, and tell you what we would verify before you commit to a programme.