Six weeks after delivery the design team has progressed, the brief has shifted, and the question lands back with the operator: can the existing capture support the new requirement, or do we need to re-fly? The honest answer depends on what the archive contains and what specifically changed. The buyer who briefs the question well gets a real answer; the buyer who briefs it badly gets a defensive quote.
If you've ever needed to update a LiDAR deliverable months after the original capture and watched the operator quote a price that felt suspiciously close to a full re-fly, you've met the design-change problem. Sometimes the quote is fair and the work genuinely requires re-capture. Sometimes the quote is a defensive posture against an underspecified question — the operator is pricing the conservative case because they don't know what's actually being asked.
The asymmetry is solvable. Design changes fall into predictable categories; each has an honest answer to the reprocess-vs-re-fly question; the answer depends mostly on what's in the operator's archive and what specifically changed about the requirement.
This article is the categorisation. Six types of design change, the reprocess answer for each, what archive items make reprocessing possible, the cost and timeline implications, and the briefing pattern that surfaces the real answer.
(The companion re-fly decisions article covers the operator-side decision tree; this article covers the project-owner side.)
Before any of the categories below: the answer "reprocess is feasible" depends on the operator having retained specific items from the original capture. The minimum archive that enables reprocessing covers:
Without the archive, even simple-sounding changes require re-capture. With the archive, most design changes are absorbable.
(See archive retention section of procurement checklist for how to ensure this exists at contract time.)
Examples. Original delivery in LAS 1.2; design team needs LAS 1.4. Original tiled at 1 km; design team needs 500 m grid. Original delivered as single MOSAIC; design team needs per-feature tile bundles.
Reprocess answer: yes, straightforward. Format conversion runs directly off the delivered files; no archive access required beyond the deliverables themselves. Tile re-cutting runs off the source cloud.
Cost and timeline. Typically 1-3 days of processing time; cost is processor-day rate plus delivery-format checks. 5-15% of original project cost.
Watch-outs. Format down-conversions (LAS 1.4 → 1.2) can lose information if extended classification or extra return numbers are used. Worth confirming the new format can carry everything the old format did.
Examples. Original delivery was point cloud + DTM; design team now needs contours at 0.5 m, hydro- enforced breaklines, and a DSM. Original was bare- earth focused; design team now needs vegetation canopy height model.
Reprocess answer: yes, usually. Additional deliverables generally derive from the existing point cloud. Some (contours, DSM, simple raster derivatives) are pure post-processing on what's already classified. Others (canopy height model, biomass estimates, detailed building footprint) need additional classification work but no field re-capture.
Cost and timeline. 1-2 weeks for most derivative products. Cost depends on the deliverable complexity — a simple contour run is 5-10% of original project cost; full hydro-enforcement on a complex site can be 20-30%.
Watch-outs. If the original capture didn't acquire sufficient ground points under canopy, derived canopy products may have low confidence in those areas. The operator should flag this in advance.
Examples. Original delivered at ±50 mm planning grade; design team now needs ±20 mm engineering grade on a 5-hectare subset for a structure footprint.
Reprocess answer: maybe — depends entirely on what was captured. If the original capture used PPK trajectory correction with good base station data and adequate sensor accuracy, the cloud may already meet the tighter spec — what changes is the QA pack validation, not the capture itself. A new control survey in the subset area validates whether the existing data holds the spec.
If the original capture used RTK-only correction or was flown with a sensor at the edge of its capability, the tighter spec may not be supportable from the existing data regardless of reprocessing.
Cost and timeline. Validation-only update: 1-2 weeks, 10-15% of original cost. Full re-capture of the tighter-spec subset: 30-50% of original cost for that area only.
Watch-outs. The honest answer requires the operator to inspect their own trajectory data and tell you whether the existing capture is genuinely tighter than the originally-reported spec. Some operators report conservatively; others report at the spec they contracted to. Worth asking explicitly.
(See accuracy article for the underlying capture-vs-spec distinction.)
Examples. Original classified ground + vegetation + building; design team now needs road surface, water, and powerline conductors classified separately. Original classification was rushed; design team has found errors that need cleanup.
Reprocess answer: yes, definitively. Classification runs entirely on the point cloud and is the single most re-runnable processing step. Different parameters, additional classes, manual cleanup — all available from the existing data without re-capture.
Cost and timeline. Re-classification of an entire project takes 1-2 weeks; subset re-classification or class-specific cleanup is days. Cost typically 15-25% of original processing cost for full re-run; subset work proportionally less.
Watch-outs. Some classifications (especially powerline conductor detection) work better with denser captures and may have lower confidence on a sparse original. The operator should be able to predict likely success.
Examples. Original 100 ha; design team now needs an adjacent 20 ha that wasn't in scope. Or original captured the entire site; design team only needs the northern third and wants a budget refund.
Reprocess answer: extension needs re-fly of the new area (the original capture didn't go there). Reduction is straightforward subset extraction.
Cost and timeline for extension. The new area needs full capture, processing and QA. Cost is the extension area's standalone capture cost minus any mobilisation savings if it can be done as a single-day addition.
Cost and timeline for reduction. Subset extraction runs on existing data; 1-3 days; minimal cost. Whether a budget refund is appropriate depends on contract structure — fixed-price contracts generally don't refund.
Watch-outs. Extensions that join an earlier capture need careful seam handling. The operator should treat the join as a calibration boundary, not a straight concatenation.
Examples. Original delivered in GDA94 MGA Zone 56; design team now needs GDA2020 MGA Zone 56. Original in local site grid; design team needs national MGA coordinates.
Reprocess answer: yes, with caveats. Datum transformation runs on the existing cloud and deliverables. GDA94→GDA2020 has a well-defined transformation (uses the NTv2 grid in Australia); GDA2020 to local site grid uses the project's specific calibration.
Cost and timeline. Datum transformation of an entire project is 1-3 days. Cost typically a small processor-time charge plus QA validation in the new datum.
Watch-outs. Datum transformations are not geodetically equivalent — GDA94 and GDA2020 differ by about 1.8 m in any given location due to plate movement since 1994. Designers using both datums need to be careful which they're working in. (See AHD / GDA2020 article for the geodetic detail.)
Three categories where re-capture is genuinely required, regardless of archive contents:
1. The site has physically changed. Six months after capture, construction has progressed, vegetation has grown, a stockpile has been re-shaped. The existing data describes the past; the design needs the present. Re-fly is the answer.
2. The required accuracy exceeds what the sensor captured. Original captured with a 30 mm-class sensor; design team now needs sub-10 mm. The data isn't there to extract; no reprocessing will produce it. Re-fly with a better sensor is the answer.
3. The required coverage exceeds what was flown. The design has expanded to an area not in the original capture. Reprocessing can't invent data; the new area needs flying.
When the operator quotes "this needs a re-fly", these are the legitimate cases. If the change isn't one of these and the operator is still quoting re-fly, something else is going on — could be archive loss, could be defensive pricing, worth asking which.
Five things to include in any design-change brief that lets the operator give you a real answer:
1. Specifically what changed in the design. Not just "we need an updated deliverable"; the specific requirement that's new. Format change, additional class, tighter spec, etc.
2. What you've still got from the original delivery. The operator may have archive too, but restating what you have helps them assess the gap.
3. Whether the site has physically changed. If construction has progressed since the capture date, even a perfect-archive reprocess produces stale data. The buyer is the one who knows whether the site has moved.
4. The driving deadline. Real change requests have real deadlines; the operator can't optimise the reprocess-vs-re-fly trade-off without knowing yours.
5. The acceptable cost envelope. Approximately what budget the change should fit inside. The operator can sometimes find a partial approach that fits the envelope when the full answer doesn't.
A brief with these five elements gets a useful response. A brief with "the design has changed, can you re-quote" gets a conservative one.
Three questions that surface the real answer:
"Do you still have the source archive?" If yes, reprocessing options are open. If no, even straightforward-sounding changes may need re-fly.
"What's the cheapest path to meet the new requirement?" Forces the operator to articulate options rather than defaulting to a full re-quote. Reputable operators will lay out the trade-offs.
"Is the existing data tighter than the spec it was delivered against?" Specifically relevant for accuracy-tightening requests. Many captures over-deliver on accuracy; the operator's trajectory data tells them whether yours did.
Three patterns we see when design changes are handled badly:
Asking "can you re-fly" instead of "what are my options". The first question pre-commits the operator to quoting a re-fly. The second opens the solution space.
Not flagging physical site changes. Six months of construction progress is the operator's blind spot — they assume the site is as they left it. If it isn't, every reprocess answer is potentially wrong.
Treating the change as informal. A design change that's the subject of a casual email exchange generates a casual response. The change that's treated as a formal scope addition (with proper specification and explicit deadline) generates a proper response.
Design changes after delivery fall into six categories, each with a clear reprocess-vs-re-fly answer: format / tile-structure (reprocess), additional deliverable from existing data (reprocess), accuracy spec tightening (depends on original capture), classification change (reprocess), geographic extension (re-fly the new area only), datum / projection change (reprocess).
Three categories genuinely need re-fly regardless: the site has physically changed, the required accuracy exceeds what the sensor captured, the required coverage exceeds what was flown.
The archive prerequisite — raw sensor data, trajectory, RINEX, processing configuration — determines what's reprocessable. Archive retention clauses in the original contract are what make this work.
The briefing pattern that gets a real answer covers five things: specifically what changed, what you still have, whether the site has moved, the deadline, the acceptable cost envelope. Three questions to ask the operator surface the genuine options.
Most design changes are cheaper than they look when briefed properly. The defensive re-fly quote is usually a response to vague briefing, not the underlying reality.
If we ran the original capture, send through what's changed and we'll walk through the reprocess options before committing to any re-fly. If another operator ran the original, happy to give a second opinion on whether the re-fly answer is justified or whether reprocessing should be the first conversation.
The operator-side companion to this piece — covers the technical decision tree that operators work through internally when a re-fly question arrives.
Item 3 of the checklist — archive retention — is what makes this article's reprocessing options available. Pin it down at procurement, not at the first re-quote.