Drone Data Processing — From Raw Capture to Client-Ready Deliverables

What "Processing" Actually Covers

Raw drone data is not a deliverable. A LiDAR flight produces a trajectory and a few hundred million range measurements; a photogrammetry flight produces a folder of images and a base station log; a GPR flight produces radar traces; a sonar flight produces soundings. None of it is useful to an engineer, a GIS analyst, or a regulator until it has been georeferenced, cleaned, classified, checked against control, and written out in the format their software expects. That work is what we mean by processing, and it is where most of the accuracy — and most of the mistakes — in drone surveying actually live.

• Trajectory and georeferencing — PPK/RTK solution, base station and CORS integration, lever-arm and boresight calibration, and the coordinate system and vertical datum transformation your project specifies
• Point cloud classification — ground, vegetation by height class, buildings, water, conductors and structures for corridor work, with the classification scheme documented
• Surface generation — bare-earth DTM, full-surface DSM, hillshade, slope, and contours at the interval you specify
• Orthomosaic and imagery products — true orthomosaics, multispectral index maps such as NDVI and NDRE, radiometric thermal mosaics
• Volumes and change detection — stockpile volumes with base surfaces documented, cut/fill against design, surface-to-surface differencing between epochs
• Geophysical processing — GPR processing chain (filtering, gain, migration, velocity) and interpreted depth surfaces; bathymetric soundings to depth surfaces and volumes
• Accuracy assessment — independent checkpoint comparison, residuals, and RMSE, reported with the control used

Software and Workflow

We process in industry-standard tools — Pix4D for photogrammetry and multispectral products, ArcGIS for GIS deliverables and analysis, dedicated LiDAR, GPR, and hydrographic packages for their respective data — and, more importantly, in a documented workflow. Every dataset gets a processing report that states the software, the parameters, the control, and the checks, so the result can be reproduced and defended rather than taken on trust. Our post-processing lead checks every survey against its control before it ships.

Deliverables by Who Is Receiving Them

The same survey turns into different files depending on the desk it lands on. We ask that question first.

Engineering and design firms

Classified LAS/LAZ, DTM and DSM as GeoTIFF or gridded ASCII, contours and breaklines as DXF/DWG, surfaces as LandXML for Civil 3D, cross-sections at station intervals, and the accuracy report.

GIS and asset teams

Shapefile, GeoJSON, file or enterprise geodatabase, GeoTIFF rasters with defined projections, and attribute schemas matched to your existing layers so the data drops into the map you already maintain.

Operations, agronomy, and finance

Volume reports with base surfaces documented, index maps and prescription-ready zones, PDF summaries with the numbers up front and the method in the appendix.

Regulators and owners

Compliance-format depth surfaces and contours, dated and documented, with the survey conditions stated.

Send Us Your Raw Data

We process third-party data. If you or another operator have flown a site and what came back was a folder rather than a deliverable — or a deliverable that does not check against control — send us the raw capture and we will produce the products your project actually needs.

What we need to do it properly:

• The raw sensor data — LAS/LAZ or trajectory files for LiDAR, original images with EXIF for photogrammetry, native radar or sonar files for geophysical data
• Base station observations or the CORS/RTK network used, and the flight logs
• Ground control and independent checkpoint coordinates, with the coordinate system and vertical datum they are in
• What the deliverable is for, and the format and datum it has to arrive in

What we will not do is certify accuracy we cannot verify. If a dataset arrives without checkpoints, we will process it, state the relative accuracy it supports, and tell you plainly that an absolute accuracy figure would require control that does not exist. Where a project needs a stamped deliverable, the processed data goes to a licensed professional partner for review, as it does with our own surveys.

Turnaround

Standard processing turnaround is 72 hours from receipt of complete data, 36 hours with rush processing. Full classification of large corridor datasets and multi-epoch change analyses can run longer; we confirm the timeline when we see the data, not after the fact. Third-party data is quoted after a quick look at what arrived, because the state it arrives in is the biggest driver of effort.

When We Will Tell You Not to Buy It

If your team already runs Pix4D or a LiDAR pipeline and has the control to check against, you may not need us for processing at all — we will say so. If the raw data was flown without ground control or a usable base station, no amount of processing will turn it into a survey-grade product, and we would rather tell you that before you pay for it. And if the capture itself is the problem, the cheapest fix is usually to fly it again properly, which we can also do.

Further Reading

LiDAR Mapping — what ±2–5 cm actually means, and why ground control decides whether a dataset is survey-grade.

Drone Survey Cost Guide — how processing and deliverables factor into what a survey costs.