Every drone LiDAR operator has a default processing pipeline — a sequenced chain of software steps that takes raw sensor data and produces a finished deliverable with minimal manual intervention. The default pipeline works beautifully for ~70% of projects. The other 30% need something different — non-standard classification, project-specific hydro-enforcement, unusual deliverable formats, custom QA workflows — and the default pipeline silently delivers the wrong thing if nobody flags the deviation. Knowing which 30% you're in is the difference between a smooth project and a delivery that's technically clean but doesn't fit.
If you've ever received a LiDAR deliverable that was technically correct but functionally mis-shaped — the right point cloud in the wrong projection, the right DTM at the wrong resolution, classified with ASPRS defaults when your design tools needed extended classes — you've met the default-pipeline-vs-custom problem. The operator ran the project through their standard processing chain. The chain works well for the majority of work it sees; it just doesn't fit yours.
Modern LiDAR processing is heavily automated. The major software platforms — TerraSolid for advanced processing, LP360 for general workflow, DJI Terra for entry-level, Bentley ContextCapture for hybrid work, Esri ArcGIS Pro for GIS-integrated workflows — each ship with default pipelines that handle standard projects end-to-end. Operators tune the defaults for their typical client base. The default becomes invisible to both operator and buyer until a non-standard project surfaces what was being assumed.
This article walks through what default pipelines actually do, where they fit and where they don't, when commissioning a custom processing chain is warranted, what custom processing actually costs in time and money, and the brief language that surfaces the decision explicitly rather than letting it default invisibly.
A typical drone LiDAR processing pipeline runs through eight to ten standard steps:
1. Trajectory post-processing. PPK correction of the GNSS+IMU data against base station RINEX. Tool: typically the sensor vendor's PPK software (Applanix POSPac, Trimble Inpho, etc.).
2. Cloud generation. Combining the trajectory with the sensor's range and angle measurements to produce the raw point cloud. Tool: sensor vendor's processing software (RIEGL RiPROCESS, YellowScan CloudStation, etc.).
3. Strip alignment. Registering adjacent flight strips to each other to remove residual offsets. Tool: TerraSolid TerraMatch is the industry standard; vendor tools are alternatives.
4. Boresight calibration. Solving for and correcting the small angular offsets between sensor and IMU mounting.
5. Control fit. Registering the cloud against ground control points to anchor absolute position.
6. Classification. Running ground extraction (CSF, progressive TIN), vegetation classification, building extraction, etc. Tool: TerraSolid TerraScan, LP360 classification, ArcGIS LAS Dataset tools.
7. Filtering and noise removal. Statistical outlier removal, low/high noise filtering.
8. Derivative generation. DTM, DSM, contours, canopy height model from the classified cloud. Tool: typically the same classification software.
9. Deliverable formatting. Tiling, naming convention, format conversion (LAS to LAZ, GeoTIFF generation, LandXML export).
10. QA pack generation. Residuals report, density coverage map, classification quality summary, manifest.
In a default pipeline, each step has preset parameters that the operator has tuned for their typical work. The whole chain runs largely unattended after initial setup; finished deliverable in days from capture.
(See processing pipeline article for the deeper technical breakdown.)
pipelines
The defaults aren't arbitrary — they reflect sensible choices for a broad client base. Typical defaults:
These defaults are reasonable for engineering-grade work on rural or peri-urban sites with moderate vegetation. They cover roughly 70% of typical drone LiDAR projects without modification.
(See reading the project brief article for how the same defaults get interpreted differently between operators.)
Six categories of project where defaults break and custom processing is warranted:
Projects needing extended ASPRS classes (powerline conductors, transmission towers, rail infrastructure, road surface as a distinct class) or project-specific user-definable classes.
Why default breaks. Default pipelines don't populate extended classes; the deliverable shows "unclassified" where the project expected specific class labels.
Custom pipeline addition. Project-specific classification rules, sometimes requiring training data and machine-learning model adjustment. Typical effort: 1-3 days additional processing setup.
Projects that need bare-earth DTM enforced at specific structures — bridges, culverts, weirs, low-level crossings, levees. Default pipelines either ignore these or treat them inconsistently.
Why default breaks. Bare-earth DTM "as captured" carries the bridge deck or culvert crown into the surface, producing wrong answers for drainage and flood modelling.
Custom pipeline addition. Manual or semi- automated breakline digitisation at each structure, hydro-enforcement applied at processing. Typical effort: 0.5-2 days per substantial structure.
(See flood modelling article for why hydro-enforcement matters specifically for hydraulic modelling.)
Projects in local site grids, projects spanning MGA zones, projects requiring transformation to non-standard CRS (legacy GDA94 systems for integration with old data, local engineering grids).
Why default breaks. Default pipeline assumes standard MGA Zone + AHD; non-standard CRS either isn't applied or is applied with default transformation chain that introduces errors.
Custom pipeline addition. CRS-specific transformation, validation against site control, documentation of transformation chain. Typical effort: 0.5-2 days plus validation work.
(See coordinate transformations article for the failure modes.)
Projects with specific format requirements that don't match default outputs — Civil 3D LandXML TIN with breakline attribution, Bentley i-Model, 12d strings, specific raster grids (e.g., custom-resolution DTM for a particular design tool).
Why default breaks. Default outputs are LAS/GeoTIFF/shapefile; specific design-tool formats need additional conversion and validation.
Custom pipeline addition. Format-specific export step, validation in target tool, manifest documentation. Typical effort: 1-3 days per non-standard format.
(See design handoff article for which formats civil engineering teams actually need.)
Projects requiring specific QA pack contents beyond default — compliance-grade reporting, specific accuracy reporting per cover class, documented capture conditions, independent reviewer sign-off as a formal process.
Why default breaks. Default QA pack is operator-templated; specific compliance or regulatory format may differ.
Custom pipeline addition. Project-specific QA template, additional documentation, independent reviewer workflow. Typical effort: 1-2 days documentation work plus reviewer time.
(See QA pack article and acceptance criteria article for the QA pack and acceptance criteria frameworks.)
Projects that are part of a recurring programme where consistency across cycles matters. Processing-chain stability requires explicit configuration rather than default versioning.
Why default breaks. Default pipelines evolve with software updates; default outputs in 2024 differ subtly from default outputs in 2026. Cycle-to-cycle comparison shows the software drift as apparent change.
Custom pipeline addition. Locked processing configuration, version control, explicit documentation of every parameter. Typical effort: 1-2 days setup, then maintained indefinitely.
(See change-detection article for the methodology requirements.)
Custom pipeline development for a single project typically falls in these ranges:
| Customisation type | Typical cost range | |---|---| | Extended classification setup | $1,500-4,500 | | Project-specific hydro-enforcement | $3,000-12,000 (depends on structure count) | | Non-standard CRS workflow | $1,500-4,500 | | Bespoke deliverable format | $1,500-5,000 per format | | Custom QA pack template | $2,000-5,000 | | Programme-locked processing chain | $3,000-8,000 setup, modest maintenance |
For a typical project requiring two or three of the above, total custom processing addition is $5,000-20,000 on top of standard processing cost.
The cost is real but proportionate to the value. Project that needs custom hydro-enforcement and the deliverable is wrong without it would face either expensive rework or unusable data; custom processing is cheaper than either.
Five signals that suggest your project needs custom processing rather than default:
1. The downstream tool isn't standard. If your design team uses Civil 3D / OpenRoads / 12d Model / specific GIS platforms with format requirements beyond LAS/GeoTIFF, custom deliverable formatting is likely needed.
2. The classification needs go beyond ASPRS standard. Powerline work, rail, specific utility infrastructure, custom asset classes — all need configuration beyond default.
3. Hydro-enforcement matters. Anywhere the deliverable will be used for drainage, hydraulic modelling, flood modelling, stormwater design, hydro-enforcement at structures is critical.
4. The CRS is unusual. Local site grids, trans-zone work, GDA94 integration, project- specific datums — all need custom CRS handling.
5. The QA or documentation requirements are specific. Compliance work, regulator filing, multi-cycle programmes, audit-defensible deliverables — all benefit from custom QA workflows.
If two or more of these apply, the project is probably in the 30% that needs custom processing. If none apply, default pipeline is appropriate.
Three paragraphs that pin down the processing approach explicitly:
"Processing approach: Operator's standard processing pipeline acceptable for [items where defaults are fine, e.g., 'trajectory, strip alignment, control fit, basic classification'].
Custom processing required for: [list specific items, e.g., 'powerline conductor classification as ASPRS class 14, hydro-enforcement at the three culverts shown in Appendix A, LandXML TIN export with breakline attribution for Civil 3D 2024 import, custom QA template per attached reference'].
Processing chain documentation: All custom parameters and software versions to be recorded in the manifest. For programme captures, the processing configuration shall be locked at cycle 1 and reused across subsequent cycles with explicit re-documentation if any parameter changes."
That language separates the default-acceptable items from the custom-required items, and pins down the documentation requirement that lets the processing be reproduced or audited later.
Four diagnostic questions during quotation:
1. "What's your standard processing pipeline, and what are its key defaults?" Surfaces what the operator's default looks like — accuracy parameters, classification scheme, formats, QA content.
2. "Which aspects of my project will require non-default processing?" Forces the operator to surface what they'd be doing custom anyway, giving you visibility into the scope.
3. "What's the additional cost for the custom processing items?" Itemised vs bundled. Both are valid; itemised is more defensible if scope changes.
4. "Will the processing configuration be documented in deliverable manifest, and locked for subsequent cycles if this is part of a programme?" Tests whether the operator's processing-chain discipline is mature.
Three patterns we see when processing scope goes badly:
Buyer assumes default pipeline is "complete" processing. Default is complete for standard projects; partial for non-standard. The brief that says "include all standard processing" gets default delivered; the project that needed custom doesn't.
Operator quotes default pipeline cost when custom is clearly needed. Operator either underestimates or absorbs the gap — either way the project economics break later.
Programme cycle 1 doesn't lock processing configuration. Cycle 2 uses default-of-the-day processing; the apparent change between cycles is software drift rather than real-world change.
Default LiDAR processing pipelines (TerraSolid macros, LP360 templates, DJI Terra defaults, ContextCapture standard chains) handle ~70% of typical projects without modification. The other 30% need custom processing chains.
Default pipelines typically include: ASPRS standard classification, no hydro-enforcement, standard MGA + AHD CRS, LAS 1.4 LAZ + GeoTIFF
Six categories warrant custom processing: non- standard classification (powerline, rail, custom classes), project-specific hydro-enforcement, unusual coordinate systems, bespoke deliverable formats, non-standard QA workflows, change- detection / programme captures.
Custom processing cost typically $1,500-12,000 per customisation type; total project addition $5,000-20,000 for projects needing two or three customisations. Cost is real but proportionate to value.
Five signals you need custom: non-standard downstream tool, classification beyond ASPRS standard, hydro-enforcement matters, unusual CRS, specific QA/documentation requirements. Two or more = custom processing warranted.
Three-paragraph brief language separates default- acceptable from custom-required, and pins down documentation for reproducibility.
Four diagnostic questions surface the operator's processing approach during quotation. Three common scoping mistakes: assuming default is complete, operator under-quoting custom, programme cycle 1 not locking configuration.
If your project hits any of the five signals (non-standard tool, extended classes, hydro-enforcement, unusual CRS, specific QA), worth walking through the processing approach explicitly at quotation. Send through the project shape and we'll separate what runs through default from what needs custom configuration, with itemised cost for each customisation.
The classification-specific decision that sits inside the broader processing pipeline choice. Custom classification is often the largest single component of a custom processing chain.
The deeper technical walkthrough of what each pipeline step actually does. Useful prerequisite for understanding which steps benefit from customisation.