From the moment the drone lands to the moment a defensible DTM appears on the design team's desk is typically a week or two of work. Most clients see it as a black box. This article opens the box — stage by stage, with the time each one actually takes and the bottlenecks that decide whether your project ships on schedule.
If you've ever quoted a 10-day turnaround on a Friday and watched it ship the following Friday, you've met the LiDAR processing pipeline. The capture is the part everyone sees; the post-processing is the part that actually determines whether the project lands on time. Most clients understand the capture intuitively (drone goes up, scans, comes down) and treat the processing as black-box magic.
The pipeline isn't magic — it's a sequence of well-defined stages, each with characteristic time budgets and failure modes. The /process page on this site lists the ten stages at the marketing level. This article opens each stage to the computational and judgement work inside.
What happens: Raw sensor logs (LAS / proprietary native format), GNSS observations from the drone receiver, IMU log file, base-station RINEX log, photo logs if a camera was paired, flight telemetry. Each lands as a separate file from the field kit.
Time: 1-3 hours including transfer from media to processing server. Larger captures with high point density can take longer just to copy.
Bottleneck: Network bandwidth for off-site transfer. For remote captures this is often the longest stage in absolute terms.
What happens: The base station RINEX log and the drone GNSS
Output: A trajectory file with position + orientation at every epoch, plus per-epoch quality metrics (forward fixed, float, etc.) and a covariance plot.
Time: 30 minutes — 3 hours depending on flight duration and solution complexity.
Bottleneck: Forward+backward processing for solution convergence at flight edges. Long flights with marginal GNSS geometry can take longer; clean conditions resolve fast.
What happens: The corrected trajectory is applied to the raw sensor pulses. For each laser pulse, the sensor knows the range and angle; combined with the precise sensor position + orientation at the pulse-emission epoch, every return becomes a 3D geo-referenced point.
This is computationally intensive — hundreds of millions of pulses, each with multiple returns, each requiring a coordinate transform from sensor frame to world frame.
Output: Geo-referenced LAS files, typically tiled by flight strip.
Time: 1-6 hours depending on point count and processing hardware. A 500-million-point capture is a 4-8 hour job on modern processing servers.
Bottleneck: Pure CPU throughput. Modern pipelines split the work across cores; GPU acceleration helps some operations.
What happens: Adjacent flight strips overlap by 25-60%. In the overlap zones, the same physical ground is captured twice from different angles. The two strips should agree perfectly; in practice they disagree by a few millimetres to a few centimetres due to small calibration errors.
Strip alignment software (TerraScan, TerraMatch, LASTools) identifies the overlap zones, fits a transformation that minimises the discrepancy, and applies it to one strip relative to the other.
Output: Aligned strip set with per-strip-pair discrepancy statistics in the QA pack.
Time: 2-6 hours depending on strip count and computational complexity of the alignment fit.
Bottleneck: Often human review — the algorithm produces an alignment but the operator validates that the result is sensible (no over-fitting, no warped geometry).
What happens: Atmospheric scatter, low birds, dust returns, multi-path artifacts and isolated noise points are removed. The algorithms look for points that don't fit local surface expectations — too far above neighbours, too far below, isolated from clusters.
Output: A cleaned cloud with noise classified out (typically to ASPRS class 7 or 18 rather than deleted, so the original returns are preserved if review is needed).
Time: 30 minutes — 2 hours, typically automated.
Bottleneck: Pipeline configuration for the project's specific conditions. Dusty mining captures need different filter parameters from clean civil captures; getting it wrong removes real points or keeps noise.
What happens: The biggest single stage. CSF (Cloth Simulation Filter) and progressive TIN densification (Axelsson algorithm) run automatically, then a human reviewer goes through bridges, steep batters, dense canopy patches and edge cases manually.
(For the algorithmic detail, see ground classification — the algorithms behind bare earth.)
Output: Cloud with every point classified to an ASPRS class (2 = ground; 3-5 = vegetation tiers; 6 = building; 9 = water; etc.).
Time: Automated step is 1-3 hours. Manual review is 4-12 hours for a typical engineering capture, longer for complex sites with bridges, steep batters or dense canopy.
Bottleneck: Manual review time. The honest answer is the automated classification gets 85-95% by point count; the remaining 5-15% needs human review, and that's where the most consequential errors live.
What happens: For projects requiring CAD linework or asset extraction, vectors are pulled from the classified cloud. Edges of formation, kerb lines, fence lines, building outlines, drainage features — all extracted as 3D polylines or polygons.
Some extraction is algorithmic (edge detection on intensity); some is manual digitisation in TerraScan, MicroStation or similar.
Output: Vector deliverables — DWG, SHP, GeoJSON.
Time: Highly project-dependent. Bare-civil sites with simple feature sets: 1-2 hours. Asset-dense urban or industrial sites: 1-3 days of skilled manual work.
Bottleneck: Skilled operator time. Feature extraction doesn't parallelise the way classification does.
What happens: Ground-classified points are interpolated into a DTM raster or TIN. Surface-of-everything points are combined into a DSM. Breaklines are added at hydraulic structures, ridges and channels for hydro-enforcement. Contours are generated at the specified interval and smoothed to tolerance.
Output: DTM + DSM rasters (GeoTIFF) or TINs (LandXML), with contours (DWG) and any hydro-enforcement breaklines packaged separately.
Time: 2-8 hours depending on surface complexity and hydro-enforcement scope.
Bottleneck: Hydro-enforcement editing where structures need manual breakline placement. Pure surface generation is fast; making the surface hydraulically correct is what takes the time.
What happens: Independent ground control checkpoints are compared against the cloud at the corresponding XY positions. Vertical and horizontal residuals are computed, RMSE aggregated, per-cover stratification produced, distribution plotted, spatial map generated.
If any residuals exceed project tolerance, the offending area gets manual review or, in serious cases, re-processed from upstream.
(See reading a residuals report for the format.)
Output: QA report with the residuals page plus the other nine sections documented in whats actually in a LiDAR QA report.
Time: 4-8 hours including any remediation cycles.
Bottleneck: Often the project's first time through the QA pipeline catches calibration issues that require reprocessing upstream stages. Repeat captures with the same configuration run through QA cleanly.
What happens: Outputs are converted to the formats specified in the project brief (LAS vs LAZ, GeoTIFF resolution, DWG vs DXF, etc.), packaged in the requested tile structure, metadata files generated, README written, deliverable manifest produced, QA pack assembled, signed off and uploaded for client access.
Output: Final delivery package.
Time: 4-8 hours including independent sign-off review.
Bottleneck: Last-mile format conversions where the client's specific software has unusual requirements. Standard formats (LAZ + GeoTIFF + DWG) ship fast.
A typical engineering-grade capture, end to end:
| Tier | Capture | Processing | Total turnaround | | ----------------- | ------- | ---------- | ---------------- | | Simple (5 ha) | 1 day | 2-3 days | 3-7 days | | Standard (50 ha) | 1-2 days| 4-7 days | 5-12 days | | Complex (500 ha) | 3-5 days| 7-14 days | 10-21 days | | Specialist (XL) | 5-14 days| 14-21 days| 14-35 days |
The capture is rarely the bottleneck. Processing — especially stages 6 (ground classification) and 9 (QA + remediation) — dominates the schedule. Programmes with repeat captures of the same site run faster once calibration is established and the pipeline is locked.
In our experience, three stages account for most of the schedule variance:
1. Trajectory post-processing on marginal flights. A flight with good GNSS conditions PPKs in 30 minutes. A flight with multi-path issues or extended GNSS gaps can take half a day, sometimes with a partial re-fly required.
2. Ground classification manual review on complex sites. Bare civil sites classify cleanly. Sites with multiple bridges, dense canopy, or unusual terrain features need significant manual review time. The schedule budget should reflect site complexity.
3. First-time QA on novel project configurations. The first project against a new sensor configuration, new datum, or new client deliverable spec almost always surfaces something during QA that requires upstream remediation. Subsequent projects with the same configuration breeze through.
Honest expectations about pipeline shortcuts:
Can be skipped for planning-grade work:
Can never be skipped for engineering-grade work:
A "fast" turnaround that skips items in the second list isn't fast — it's missing the work that makes the deliverable defensible.
A few stages parallelise across multiple captures:
For multi-flight programmes (corridor work over multiple days, recurring monthly captures, large mine-site mobilisations), the processing wall-clock time scales sub-linearly with flight count because of parallelism. For single one-off captures, the pipeline runs more or less serially.
The pipeline isn't a black box; it's ten well-defined stages with characteristic time budgets and known bottlenecks. Capture takes hours; processing takes days; the schedule lives in the processing pipeline, not the airtime.
Programmes with repeat captures of the same site speed up after the first; novel configurations surface remediation work on the first project. The honest schedule budget accounts for both.
If you're scoping turnaround on a project, ask the provider which of the ten stages dominate the schedule. Reputable operators answer specifically; marginal operators describe it as "a few days of processing" and discover the bottleneck on the day.
Tell us the deliverable spec and the date you need it landed. We'll walk through which stages drive the schedule for your specific project — and whether the timeline fits a single-mobilisation capture or a phased programme.