A project delivery lands, the team uses it for a while, and then someone asks for something the delivery doesn't include. The reflexive answer is 'we'll need to re-fly'. The honest answer is more often 'we can reprocess the archive' — at a fraction of the cost and a fraction of the time.
If you've ever been quoted a fresh capture price for a request that turned out to be solvable from archived data, you've met the re-fly-vs-reprocess question. Many requests that sound like they need a new flight actually don't. Some genuinely do. The framework for telling them apart is straightforward; the question is whether your operator carries the archive that makes reprocessing possible.
This article is the working version. What's reprocessable from archived source data, what requires a fresh flight, the diagnostic to decide, and the hybrid pattern that often beats both.
A LiDAR project that's properly archived includes:
Given those archives, the following requests are reprocess-only — no new flight required:
Update to a different datum. GDA94 to GDA2020 transformation runs against the original cloud; no re-capture. The datum article covers the transformation specifics.
Re-classification with different parameters. If the original classification missed some ground in dense canopy, re-run the classifier with adjusted parameters against the same cloud. No re-fly.
Tighter contour interval. Original delivery shipped 0.25 m contours; design team needs 0.1 m for detail work. Re-generate contours from the captured DTM at the new interval. No re-fly.
Different tile structure. Original tiles are 1 km × 1 km; new consumer wants 500 m × 500 m. Re-tile from the same cloud. No re-fly.
Additional deliverable formats. Original shipped LAS + GeoTIFF; consumer needs DWG contours and LandXML surface. Re-export from the existing deliverables. No re-fly.
Better classification on edge cases. Manual review of problematic areas (bridges, batters, dense canopy) tightens classification quality without re-capture.
Updated PPK trajectory. If improved PPK software is now available, re-process the trajectory from the archived RINEX logs. The cloud regenerates with tighter trajectory and often improved accuracy.
Additional outputs not originally scoped. Per-cell point density raster, intensity raster, vegetation classification — all derivable from the existing cloud.
For all of the above, the time is days and the cost is typically 10-30% of the original capture cost. The cloud already exists; the work is the processing pipeline against it.
Some requests don't have a reprocess solution:
Anything that didn't exist at original capture time. Buildings, earthworks, infrastructure, planting that's been placed since the capture. No amount of archive reprocessing recovers data that wasn't captured.
Anything that has materially changed. Vegetation that has grown significantly, terrain that has settled, infrastructure that's been demolished or modified. The archived cloud represents the site as it was; current state requires current capture.
Coverage gaps the original missed. Areas outside the original flight extent — the operator captured the project boundary as specified; if the new requirement extends past that boundary, re-fly the extension.
Capture quality fundamentally inadequate. Original captured at insufficient point density for the new requirement. Re-fly at higher density (or use partial re-fly pattern below).
Sensor data corruption or loss. Rare but happens — storage failure, transfer corruption, lost media. Re-fly is the only recovery path.
For all of these, the cost is full capture price (or a proportion if partial re-fly works) and the time includes mobilisation lead time.
A simple flowchart for any post-delivery request:
Step 1: Is the source data archived? If no, the question is moot — only re-fly is available. If yes, continue.
Step 2: Does the request involve data that wasn't captured the first time? New features, changed conditions, coverage gaps. If yes, re-fly required (or partial re-fly).
Step 3: Is the request a derived product from the existing cloud? Different format, classification, surface resolution, contour interval, datum, tile structure — all reprocessable.
Step 4: Is the original cloud at adequate density for the new requirement? If yes, reprocess. If no, re-fly.
Step 5: Is the original capture's accuracy adequate? If yes, reprocess. If no, re-fly.
If you pass step 2 (data is in scope), step 3 (derivation sufficient), step 4 (density adequate) and step 5 (accuracy adequate), the answer is reprocess. Otherwise re-fly.
The realistic differentials:
| Pathway | Cost vs original | Turnaround | Lead time | | -------------------- | ---------------- | ---------- | --------- | | Format re-export | 5-10% | 1-3 days | None | | Re-tile / re-grid | 10-15% | 2-5 days | None | | Re-classify | 15-25% | 3-7 days | None | | Trajectory re-process| 15-30% | 3-7 days | None | | Full reprocess | 25-40% | 5-10 days | None | | Partial re-fly | 40-70% | 1-3 weeks | 1-2 weeks | | Full re-fly | 100% | 2-4 weeks | 1-2 weeks |
For requests resolvable by reprocessing, the cost difference vs full re-fly is the difference between a four-figure adjustment and a five-figure fresh capture. Worth confirming which category your request actually falls into before budgeting.
A subtle option: re-fly only the changed area, reprocess the unchanged area, and deliver a merged updated dataset.
The pattern:
Cost: typically 30-60% of full re-fly depending on changed- area fraction. Time: similar mobilisation lead time but shorter capture. The deliverable carries current data where it matters and reuses validated existing data everywhere else.
For sites that change incrementally (development projects, mine pit progress, environmental rehab), the partial-re-fly pattern is often the economically right answer — full re-fly is over-spec for unchanged areas, archive reprocessing doesn't cover the changed areas.
The realistic operator-side practices:
Retention period. Typical reputable operator retention is 12+ months for raw archive (trajectory, RINEX, sensor logs), indefinite for delivered products. Some operators keep indefinitely; others purge after fixed periods. Worth knowing your operator's policy.
Storage cost. Tens of GB per project, multiplied by hundreds of projects = terabytes of archive. Modern cloud storage is cheap enough that retention isn't economically constrained — it's an operational decision, not a cost decision.
Documentation. The archive is only useful if the processing pipeline + parameters are documented. An archive of raw data without the original processing context is much harder to reprocess.
Access for the client. Some clients want their archive shipped at project close; others rely on the operator's retention. Worth specifying in the original contract.
To preserve reprocess options, four contract items worth including:
1. Archive retention period. State explicitly how long the operator will retain raw source data — typically "minimum 12 months from delivery" or "indefinite for project lifetime, whichever is greater".
2. Reprocess pricing schedule. Pre-agreed rates for common reprocess operations (re-export, re-tile, re-classify) to avoid renegotiation when the need arises.
3. Documentation of processing pipeline. Software versions, parameter values, classification configuration — documented and shipped with the delivery so reprocessing can reproduce the original or deliberately differ from it.
4. Client archive access. Whether the raw archive is shipped to the client at delivery or retained operator-side.
A contract with these items established up front saves significant time when reprocess requests arrive.
Three patterns we see in marginal projects:
Re-processing without changing what caused the original issue. Original delivery had a classification problem; the reprocess uses the same classification parameters; the result has the same problem. The reprocess fix has to actually change the relevant input.
Insufficient documentation of original processing. Without the version numbers and parameter values, the reprocess can't reliably reproduce the original — every reprocess becomes a re-implementation. Avoid by treating processing documentation as part of the original deliverable.
Re-processing past the archive retention window. Asking for reprocess of a project from 36 months ago when the operator's retention is 12 months. The archive is gone; the only option is re-fly. Avoid by specifying retention in the original contract.
Many post-delivery requests are reprocessable from archived source data at 10-30% of original capture cost and a few days turnaround. Some require full re-fly. The partial-re-fly pattern often beats both for sites that have changed incrementally.
The 5-step decision framework: archive exists? request in scope? derivable from existing cloud? density adequate? accuracy adequate? If all yes, reprocess; otherwise re-fly (or partial re-fly).
To preserve reprocess options, specify archive retention, reprocess pricing, processing documentation and client archive access in the original contract. Doing so up-front saves significant cost when post-delivery requests arrive.
The reflexive "we need to re-fly" answer often reflects an operator without an archive, not a request that genuinely requires re-capture.
Tell us what changed since the original — site, requirements or just deliverable spec. We'll diagnose honestly whether reprocessing the archive solves it, or whether a fresh capture is unavoidable, and quote the cheaper option where it works.
What 'reprocessing' actually entails — the stages of the original pipeline that can be re-run against archived data.
Why the original capture's foundational work (control, calibration, documentation) determines what reprocessing options exist later.