Send a large point cloud through a six-stage procedure: confirm the client's acceptance format, package the contracted files, optimize without changing required data, select transport from measured size and deadline, grant scoped access, and verify receipt before retiring the transfer copy. The best transfer cannot rescue the wrong CRS, units, PDRF, or file set.
1. Confirm what the client can accept
Ask which software and version will open the data and whether the contract requires LAS, permits LAZ, or expects E57, COPC, or a vendor project. Record the LAS version and PDRF, coordinate reference system, horizontal and vertical datums, units, classification scheme, tile grid, and required derivatives.
Do not assume compressed LAZ is contractually interchangeable with LAS. LASzip describes LAZ as lossless with a bit-identical round trip, but acceptance is a separate question. The USGS Lidar Base Specification requires LAS 1.4 with PDRF 6–10 for its point deliverables and does not name LAZ there, even though 3DEP data is publicly distributed as LAZ. Distribution format and contractual format can differ.
E57 may suit terrestrial and AEC handoffs because the ASTM E2807 container can carry points, images, and metadata. COPC may suit clients who need spatial subsets: it is a single LAZ 1.4 file organized as a clustered octree and supports HTTP range requests. Neither choice overrides the client's software or specification.
2. Package a usable delivery
Build one release folder rather than sending exports from several working locations. Include the contracted cloud, tile index, derived products, control and QA reports, metadata, and a plain-language README. The README should identify the project, release date, CRS, datums, units, format/PDRF, classification convention, tile naming, software notes, and support contact.
Create a manifest of relative paths, byte sizes, and integrity values. Preserve filenames after generating it. If the project includes E57, orthomosaics, meshes, or BIM references, keep their relationships clear. Construction recipients may need different outputs from a survey/GIS client; see the construction reality-capture guide for that adjacent workflow.
3. Optimize without changing the agreement
Compress LAS to LAZ only when accepted. LASzip states that LAZ commonly occupies 7–20% of the original LAS size, but the achieved result varies by dataset, attributes, precision, and ordering. Measure representative tiles instead of promising a ratio.
Use consistent, non-overlapping tiles when the specification calls for them. Tiling makes processing incremental and isolates a failed or corrected item. For streaming, COPC consolidates an octree into one file; EPT uses many LAZ and JSON files. Package a many-file dataset carefully because file count affects queueing, per-file overhead, and exception handling.
4. Choose online, physical, or hybrid transport
Add every item in the release folder, then compare the total against measured sender upload, recipient download, deadline, and local disk rates. Under the current planning model, 1 decimal TB at 500 Mbps takes 4 h 59 m for one leg. The model adds 12% overhead and does not predict achieved throughput. Upload plus client download are separate legs.
Use online delivery when both legs fit the window and the workflow provides progress, exceptions, access control, and verification. Use physical media when the calendar beats the network; include copy-to-media, courier, copy-off, and verification time. A hybrid can send a small validation tile and README immediately while the complete package follows. Compare scenarios with the shipping-versus-transfer calculator.
5. Scope access and define retention
Prefer identified recipients, read-only access, HTTPS, a near-term expiry, and a revocation plan. Microsoft recommends user-delegation SAS where possible for Azure Storage and recommends short expiry when revocation options are limited. Those are provider practices, not proof of any particular deployment.
Tell the client when access begins and ends, who may request an extension, and whether downloads require authentication. A transfer copy is not the archive. Agree in writing who retains the authoritative source, acceptance copy, and project record, and for how long.
6. Verify the handoff
Do not close the job when an upload reaches 100%. Have the recipient compare the manifest, confirm the byte set, verify integrity, and open representative files in the intended software. Test more than one tile and include examples near project edges or special classifications. Record acceptance and any replacement release.
Use this condensed checklist:
- [ ] Client software, format, LAS version/PDRF, CRS, datums, and units confirmed
- [ ] Consistent tile grid and tile index included
- [ ] Classification scheme and contracted derivatives documented
- [ ] README, metadata, manifest, file sizes, and integrity values included
- [ ] Transfer time checked against both endpoints and the deadline
- [ ] Recipient access is scoped, read-only, expiring, and revocable
- [ ] Recipient compared the manifest and opened representative files
- [ ] Acceptance, replacement procedure, retention, and archive owner recorded
The printable LiDAR dataset delivery checklist expands this routine.
Where TeraAirlift fits
TeraAirlift is a Windows-first desktop operations console for the online stage. Current repository-supported behavior 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 does not guarantee throughput, replace the archive, or decide the client's format. Review the LiDAR workflow and large-point-cloud operating guide after defining the delivery package.
