LiDAR companies usually move a project in three separate legs: field to office, office to processing, and office to client. Choose the transport for each leg after measuring the actual package, both endpoints, the deadline, and what the recipient needs. A mature workflow is often hybrid: protect and ship raw acquisition data when field connectivity cannot meet the deadline, while transferring smaller processed deliverables online.
Plan three different transfer legs
Field to office has the least predictable connectivity and the greatest risk of losing time. Keep verified source copies until the office confirms receipt. Inventory cards and drives before a crew leaves, and compare the available upload window with courier pickup and travel time.
Office to processing may stay on a LAN, move into cloud compute, or cross between offices. This leg rewards automation, consistent paths, and a manifest because processing systems need complete inputs rather than a polished client package.
Office to client usually carries fewer bytes but demands better packaging. Confirm the format, coordinate reference system, units, tile scheme, metadata, access window, and acceptance procedure. The LiDAR delivery checklist provides a repeatable handoff.
Inventory bytes before choosing transport
LAS is the ASPRS interchange standard. LAS 1.4 R15 defines Point Data Record Formats 0–10; formats 0–5 are legacy and 6–10 are preferred. Their minimum point-record sizes range from 20 bytes for PDRF 0 to 67 bytes for PDRF 10. PDRF 6 is the newer core record, with mandatory GPS Time, as many as 15 returns, and 256 classification values.
That makes a useful first estimate:
approximate LAS bytes = point count × bytes per point
For a worked lower-bound example, 100 square kilometres is 100 million square metres. At the USGS 3DEP QL1 minimum aggregate nominal pulse density of 8 pulses per square metre, use first returns as pulse surrogates and simplify to one stored return per pulse: 800 million point records. PDRF 6 at 30 bytes per record is approximately 24 decimal GB before headers and other project files. This is a specification-based sizing assumption, not a typical commercial density or dataset size. Pulses with multiple stored returns increase the record count and LAS bytes beyond this lower bound.
LAZ can reduce the transfer volume without discarding point data. LASzip describes LAZ as lossless with a bit-identical round trip and states that LAZ files are 7–20% of the original LAS size. Applied only to that one-return lower-bound LAS estimate, the result would be about 1.7–4.8 GB. Multiple returns can increase both the uncompressed record total and compressed bytes. The range is project-stated, not universal: attributes, precision, ordering, and dataset character affect the result.
Do not stop at the point cloud. Add source imagery, trajectories, calibration, control, DEMs, orthomosaics, breaklines, reports, metadata, and intermediate products. Published OpenTopography collections range from small surveys to multi-terabyte holdings, evidence that project volume must be measured rather than guessed.
Compare the calendar, not advertised bandwidth
Use the package total and measured upload rate. Under the site's current model, one decimal TB at 100 Mbps takes 24 h 53 m for one network leg. The model adds a 12% planning allowance; it is not measured throughput or a promise. A client download is another leg, often over a different connection.
Choose among four patterns:
- Online transfer: best when the complete path fits the deadline and staff can monitor progress, exceptions, and receipt.
- Physical media or transfer appliance: reasonable when connectivity is limited or the projected online duration misses the calendar. Microsoft currently positions Azure Data Box for datasets above 40 TB and lists 120 TB and 525 TB usable devices. Those August 2026 product details depend on region and availability; they are not a universal crossover.
- Streamable delivery: COPC is a single LAZ 1.4 file organized as a clustered octree and supports HTTP range requests for spatial subsets. EPT uses an octree directory that can contain many files. Either may let a client inspect subsets instead of receiving every source byte.
- Hybrid: ship the raw field copy while sending control, preview, and urgent processed data online; later deliver the contracted output online.
Use the shipping-versus-transfer calculator when neither route is obviously faster. The 5 GB versus 5 TB guide explains why long-running jobs need different operating discipline.
Build an operational workflow
Name an owner for every leg. Create a manifest with relative paths, file counts, byte counts, format and PDRF, CRS, units, and integrity values. Keep redundant source copies, queue the transfer, monitor exceptions, and require the receiver to compare the manifest and open representative files. A successful upload is not yet an accepted delivery.
TeraAirlift fits the online field-to-office and client-delivery legs as a Windows-first desktop operations console. Its current workflow includes file and folder queues, progress and ETA, cancellation, retry-friendly operations, history, diagnostics, recipient-controlled delivery, short-lived storage access, and SHA-256 verification. It is a delivery path rather than an archive, and it does not guarantee throughput or an SLA. See the LiDAR workflow after mapping the three legs.
Reality capture for AEC shares some transfer constraints but has different contractual outputs and stakeholders. Use the construction reality-capture guide for that context, and the remote large-footage guide for another example of hybrid delivery.
