Before the drone goes anywhere near the site, the operator's planning team builds a capture plan — a document and accompanying maps describing exactly how the flight will run. Flight pattern. Altitude. Overlap. Launch points and abort criteria. The plan exists; the operator works to it. Buyers almost never see it, mostly because asking has never been part of standard procurement. Asking is a high-leverage move — the plan is where scope gaps surface most cheaply, and an operator without a real plan is signalling something important about how the project will run.
If you've ever commissioned a drone LiDAR capture and realised after delivery that the operator's flight plan didn't match what you assumed — wrong overlap, unexpected altitude, control marks placed differently than you'd imagined — you've met the capture-plan-visibility problem. The plan existed. The operator worked to it. The deliverable reflects it. You just didn't read it before the work happened.
Asking to see the capture plan is one of the highest-leverage moves in LiDAR procurement. It's cheap (operator emails you a PDF), takes 20-40 minutes to review, and surfaces every flight- planning assumption the operator made about your project. Scope gaps, density misunderstandings, control mark coverage problems, missing buffers — all of them visible in the plan rather than in the delivered cloud.
This article walks through the ten components of a typical drone LiDAR capture plan, what each one signals about operator competence, what to look for as a buyer reading the plan, and the diagnostic questions to ask when items are missing or unexpected.
The plan starts with the project area drawn over aerial imagery — typically as a shapefile or KML boundary against a recent satellite or aerial basemap.
What to look for. The boundary matches your project specification exactly. If the operator's AOI differs from yours, that's a scope misunderstanding before any other discussion.
What it signals. Boundaries that aren't explicit shapes (just "this paddock" with no polygon) signal a low-rigour planning process.
The drone's planned flight lines drawn over the AOI. Typical patterns:
What to look for. Flight lines extend past the AOI boundary (the buffer for edge effects); spacing is consistent; pattern matches the intent.
What it signals. A plan with flight lines exactly at the AOI boundary signals no buffer strategy (see edge effects article). Lines drawn freehand or inconsistently signal the plan was put together in a hurry.
The planned above-ground level altitude — a single number for flat-ground projects, or a terrain-following profile for variable terrain.
Typical values. 60-120 m AGL for engineering- grade work; 80-200 m for planning-grade; lower for specific sensor or accuracy requirements; higher for very large area captures with appropriate sensor capability.
What to look for. Altitude matches the density and accuracy spec. Compare to the operator's quoted sensor PRR — at this altitude and speed, will the resulting density meet spec? (See PRR vs density article for the arithmetic.)
What it signals. AGL of 150 m+ on a project with a quoted high-density spec signals the density numbers don't actually work out.
The percentage by which adjacent flight strips overlap. Typical values 25-50%.
What to look for. Overlap matches the sensor's swath width at the planned altitude and the project's quality requirements. Engineering-grade work typically benefits from 40-50% overlap; planning-grade work can work with 25-30%.
What it signals. 0% or very low overlap is a red flag for any engineering work — strip alignment quality degrades without sufficient overlap.
(See strip alignment article for what overlap actually does.)
The planned drone speed over ground during capture. Typical values 6-10 m/s for multirotor; 14-25 m/s for fixed-wing.
What to look for. Speed × altitude multiplied through the density arithmetic produces the expected ground density. Higher speed at the same altitude reduces density.
What it signals. Operators flying at the top of the speed range for their platform are optimising for throughput; operators flying slower are optimising for density and quality. Worth knowing which.
The specific locations from which the drone will take off and land — typically marked on the map with coordinates.
What to look for. Multiple launch options (primary + backup); each verified to be clear, accessible and CASA-compliant; locations chosen for sky visibility (GNSS reception) and practical access.
What it signals. Single launch point with no backup signals the project will fail on the day if that point has unexpected access issues. Plans with three or more options signal robust planning.
(See pre-capture site visit article for what gets validated at the launch points.)
The placement of ground control points (GCPs) across the project area, distinguished into calibration marks (used in PPK fit) and independent checkpoints (validation only).
What to look for. Calibration marks distributed across the project including edges; independent checkpoints withheld from the fit; minimum 15-20 independent marks for engineering-grade validation; clustering avoided (marks geographically distributed).
What it signals. All control used for calibration (no independent checkpoints) means the QA pack can't honestly report absolute accuracy. Marks all clustered in one area means edge accuracy is unverified.
(See residuals report article for what the QA pack does with control data.)
Specific zones where the drone won't fly — buffer distances from powerlines, prison exclusions, school zone restrictions, sensitive habitat exclusions, specific landowner refusals.
What to look for. No-fly zones marked explicitly; buffer distances appropriate to voltage class / facility type; effective capture area calculated after buffers applied.
What it signals. Plans without buffer analysis signal either the project has no applicable buffers or the operator hasn't checked. For most projects there are some applicable buffers; the question is whether they've been surfaced.
(See buffer zones article for what stand-offs typically apply.)
The conditions under which the flight will be aborted — wind speed thresholds, cloud ceiling limits, visibility minimums, GNSS PDOP thresholds, equipment status thresholds, comms failure protocols.
What to look for. Specific numerical thresholds, not vague language; abort decision authority clearly identified (pilot-in-command); return-to-launch procedures defined; specific emergency procedures.
What it signals. Plans without abort criteria signal a "we'll figure it out if something goes wrong" approach. Plans with documented thresholds signal a real risk-management framework.
(See weather window article for the on-the-day go/no-go decision the abort criteria support.)
How the operator coordinates with relevant external parties during capture — ATC notifications, asset owner sign-offs, landowner contacts, emergency service notifications, internal crew comms.
What to look for. Specific contacts and notification procedures named; emergency escalation chain defined; comms equipment listed (radio, satphone, mobile coverage check).
What it signals. Plans with detailed comms arrangements signal mature operation; plans with "will notify as required" signal under-prepared operation.
A reasonable capture plan for a typical 100 ha engineering project runs 8-15 pages:
Operators with mature processes have a templated plan that gets populated per project — most of the structure is standard, project-specific content fills the gaps. Plans assembled fresh per project tend to be either heroic or missing things.
A 30-40 minute review of the capture plan, before mobilisation, catches the issues that would otherwise surface in delivery. The review pattern:
1. Read the AOI overlay. Does the planned capture cover what you commissioned, with appropriate buffer?
2. Check the density arithmetic. At the planned altitude and speed, will the captured density meet your spec?
3. Verify control distribution. Are calibration marks and independent checkpoints both present and geographically distributed?
4. Review buffers and no-fly zones. Are applicable buffers identified? Is the effective capture area documented?
5. Read the abort criteria. Are they specific enough to be applied operationally?
6. Check the comms plan. Are notifications to relevant external parties planned?
Issues found at this stage cost an email exchange to fix. Issues found after delivery cost a re-fly or scope renegotiation.
Five red flags in capture plans:
1. No effective capture area distinct from gross AOI. Suggests no buffer strategy; edge effects will land inside your deliverable.
2. Single launch point. Project will fail on the day if that point has access issues, weather limitations, or stakeholder problems.
3. No independent checkpoints. The QA pack won't be able to report absolute accuracy honestly — only calibration consistency.
4. Vague abort criteria. "We will not fly in poor weather" is not an abort criterion; "sustained wind over 8 m/s, gusts over 12 m/s, cloud ceiling below 200 m AGL" is.
5. Missing asset owner coordination on powerline or pipeline projects. Captures done without easement notification produce data the network operator may not want to receive formally.
(See contractor's view article for the relationship side of what good coordination looks like.)
A small fraction of operators in the market work without a formal capture plan — flight planning happens on the day, in the pilot's head, against intuition rather than documented procedure. The deliverable might be fine. The lack of plan is a signal worth weighting:
This isn't disqualifying for every project; it is worth knowing about and adjusting expectations accordingly. For engineering-grade or compliance-critical work, written capture plans should be a procurement requirement.
Four diagnostic questions about the capture plan:
1. "Can I see the capture plan before mobilisation?" Simple yes/no. Operators with mature processes share immediately; those without will produce something hastily or deflect.
2. "What's your typical structure for capture plans?" Surfaces whether plans are templated or ad hoc.
3. "When does the plan get finalised?" Operators who finalise plans 1-2 weeks before flight day have time for buyer review; those who finalise day-of don't.
4. "What changes between the planned and actual capture, and how is the change documented?" Tests whether plan-vs-actual discipline is part of the operator's QA workflow.
Three patterns we see when capture plans go badly:
Plans that are technically complete but generic. Every section populated with operator's default language; nothing specific to the project. Looks thorough, isn't.
Plans with great risk analysis but missing operational detail. Pages on CASA compliance and risk assessment, no actual flight line specification.
Plans missing the buyer-relevant details. Plan focuses on operator-side operational information; doesn't surface the spec items (density, accuracy validation, deliverable format) that the buyer needs to validate.
The fix for the third pattern is the buyer explicitly asking for the operational-spec items in the plan, not just the operational-execution items.
Every drone LiDAR capture starts with a planning document. Reading it is one of the highest- leverage moves in procurement — cheap, fast, catches scope gaps cheaply.
Ten components of a capture plan: project area and AOI overlay, flight pattern, flight altitude AGL, swath overlap, ground speed, launch and recovery points (primary + backup), control mark distribution (calibration + independent), no-fly zones and buffers, abort criteria, communications and coordination plan.
Typical good plan: 8-15 pages for a 100 ha engineering project. Mature operators use templates; ad-hoc operators write fresh per project and miss things.
Buyer-side review pattern: 30-40 minutes covering AOI overlay, density arithmetic, control distribution, buffers, abort criteria, comms plan. Issues found here cost an email; issues found at delivery cost re-fly or renegotiation.
Five red flags: no effective area distinct from gross AOI, single launch point, no independent checkpoints, vague abort criteria, missing asset owner coordination on infrastructure projects.
Operators without formal capture plans are a signal — not disqualifying but worth weighting. For engineering or compliance work, written plans should be a procurement requirement.
Four diagnostic questions surface whether the operator has real plans or is improvising. Three common gotchas: generic-but-complete, great- risk-analysis-no-operational-detail, missing buyer-relevant spec items.
If you're scoping a project and want to see what a capture plan looks like — what we'd send for your specific project before flight day, what level of detail is reasonable to expect from any operator — happy to share a sample. Reading the plan before mobilisation is the cheapest validation step in LiDAR procurement; worth normalising it as standard practice.
The on-site validation that complements the desktop capture plan. Together they're the two pre-flight risk-management documents a competent operator produces.
The on-the-day execution of the abort criteria specified in the capture plan. Useful for understanding why the abort criteria need to be specific rather than vague.