TeraAirlift
Delivery checklist
demo@rcparker.co
https://teraairlift.com/demo
LiDAR Dataset Delivery Checklist
Who it's for: Reality-capture crews, field leads, processing managers, and geospatial PMs moving scan packages to office or client.
When to use: Use when moving LAS, LAZ, E57, GeoTIFF, orthos, DSMs, or full scan project exports from field devices to office, processing partners, or client GIS teams.
TeraAirlift
Delivery checklist
LiDAR Dataset Delivery Checklist
Who it's for: Reality-capture crews, field leads, processing managers, and geospatial PMs moving scan packages to office or client.
When to use: Use when moving LAS, LAZ, E57, GeoTIFF, orthos, DSMs, or full scan project exports from field devices to office, processing partners, or client GIS teams.
01Before you leave the site
- ☐Confirm project ID, site name, and capture date on the root folder
- ☐Write a one-line capture notes file (sensor, flight/scan method, known gaps)
- ☐Confirm CRS / EPSG / vertical datum notes travel with the package
- ☐List which tiles/flights are in this handoff vs deferred
- ☐Estimate total size and whether hotel/jobsite connectivity can finish overnight
02Field packaging
- ☐Keep one coherent project tree — avoid dumping mixed sites into one root
- ☐Exclude unrelated flights/scans and incomplete captures from this handoff
- ☐Include calibration / trajectory / control notes the office needs to process
- ☐Add a simple manifest: folder list, file counts, and approximate GB/TB
- ☐Verify a sample LAS/LAZ/E57 opens on the field laptop before upload
- ☐Note battery and power plan if the upload machine must stay up overnight
03Connectivity & timing
- ☐Test real upload speed from the field location (not the office pipe)
- ☐Plan for intermittent cellular/hotel Wi-Fi — assume at least one retry
- ☐Schedule upload during the strongest window (evening vs morning congestion)
- ☐Decide whether to stay on-site until first chunks succeed
- ☐If connectivity can’t finish overnight, escalate shipping/drive plan early
04Handoff queue
- ☐Queue jobs per crew/site so office can prioritize processing
- ☐Assign an office owner for acceptance before registration/classification starts
- ☐Schedule an explicit retry window if connectivity is intermittent
- ☐Label critical path packages (needed for tomorrow’s processing) vs archives
- ☐Leave contact info for the field operator who packaged the set
05Office intake
- ☐Confirm the package arrived under the expected project ID
- ☐Compare file counts and sizes to the field manifest before compute starts
- ☐Park incomplete transfers in a quarantine folder — don’t mix with live jobs
- ☐Notify processing only after integrity and spot-open checks pass
06Failure / retry plan
- ☐Never assume a mid-field upload finished without confirmation from the console/status
- ☐Retry with the same package identity; avoid creating confusing duplicate roots
- ☐Hold registration/classification until integrity check passes
- ☐Document corruption or truncation symptoms for hardware/vendor follow-up
- ☐If field power dies mid-upload, restart from a verified incomplete state — don’t re-copy blindly
- ☐Escalate early if remaining field window can’t finish before demob
07Recipient / access plan
- ☐Limit client access to the agreed deliverable subset (not raw everything)
- ☐Expire client links after the acceptance period
- ☐Keep internal processing shares separate from client review packages
- ☐Track which subcontractor received which tile set or product
- ☐Revoke temporary partner access when the processing milestone closes
- ☐Record who can still pull the dataset after the field team demobs
08Verification plan
- ☐Hash or integrity-verify when the toolset supports it; fail closed on mismatch
- ☐Spot-open a sample of LAS/LAZ/E57 files on office systems
- ☐Confirm file counts and total size match the field manifest
- ☐Check CRS notes landed with the package before starting registration
- ☐Only then kick off registration / classification compute
- ☐Log acceptance time so rework disputes have a clear “when did office get it” mark