The capture lands; the operator hits send; the deliverable starts a download that's still running 18 hours later when someone notices. The point cloud was 240 GB; the corporate VPN does 6 Mbps on a good day; the project's design tool is on a workstation that doesn't have 240 GB free. None of this is hypothetical — it's the standard pattern for any organisation that hasn't sized the infrastructure for the deliverable they commissioned. The fix is talking about it before capture, not at handover.
If you've ever commissioned a LiDAR capture and discovered at deliverable handover that your organisation's infrastructure can't comfortably absorb the file sizes — slow downloads, no spare disk, design tools that can't open the point cloud, archive systems that aren't sized for the data — you've met the storage-and-bandwidth problem. The data is there. The transfer is technically possible. The practical experience is friction that nobody costed at quotation.
Raw drone LiDAR captures are large. A small project (20 ha bare paddock) lands at maybe 30-60 GB. A typical engineering capture (100-200 ha mixed cover) lands at 150-400 GB. A corridor capture (20-50 km) lands at 200-800 GB. A multi-cycle programme accumulates terabytes per year. The numbers don't sound shocking in 2026 terms — until you try to move them through corporate IT infrastructure that wasn't designed for them.
This article walks through what LiDAR file sizes actually look like by project type, the four transfer mechanisms operators use with realistic timing for each, cloud storage cost arithmetic across multi-year programmes, and the infrastructure questions worth asking before the deliverable arrives rather than after.
File size depends on density, area, and what's included in the deliverable. Typical sizes for LAS 1.4 LAZ-compressed point cloud only:
| Project size | Density | Typical raw size | |---|---|---| | 10 ha small site | 30-50 ppm² | 5-15 GB | | 50 ha planning project | 30-80 ppm² | 25-80 GB | | 100 ha engineering | 50-100 ppm² | 60-200 GB | | 200 ha engineering | 50-100 ppm² | 120-400 GB | | 10 km corridor | 100-200 ppm² | 80-200 GB | | 50 km corridor | 100-200 ppm² | 400-1,000 GB | | 500 ha mine site | 100-150 ppm² | 300-800 GB | | Programme cycle 1 | varies | 200-500 GB typical |
For uncompressed LAS, multiply by 5-8. For intermediate processing files (sensor's native format, full-return data, calibration intermediates), add another 50-100% of the deliverable size on the operator's side.
The full deliverable bundle — point cloud + DTM + DSM + contours + classification deliverables + QA pack — typically adds 30-50% to the point cloud size. Programme captures with cycle-over-cycle archives double for each cycle retained.
(See LAS/LAZ format article for the compression structure details, and the PRR vs density article for what drives density.)
Three structural reasons the size catches buyers out:
1. Most corporate file transfers are documents, not data. Corporate file-share infrastructure is optimised for hundreds-of-MB office documents, not hundreds-of-GB scientific data. Limits, timeouts and storage quotas reflect the expected workload.
2. Connection speeds vary dramatically by location and infrastructure. A regional office on ADSL or 4G might have 5-20 Mbps usable upload; a metropolitan office on fibre might have 100-500 Mbps. The same 240 GB takes 20 hours on the slow link and 1.5 hours on the fast one.
3. Storage planning lags acquisition. Procurement commissions the data without coordinating with IT on where it lands. Six months in, the data is held in operator's storage because nobody has provisioned receiving infrastructure.
The fix isn't more bandwidth; it's matching the transfer mechanism and timing to the available infrastructure.
Operators typically use one of four mechanisms for deliverable handover:
Operator copies the deliverable to a portable hard drive (typically 2-4 TB external SSD) and ships it via courier. Two business days end-to-end.
Pros. No bandwidth dependency, simple, works for any file size, no security concerns about internet transfer, recipient gets a physical backup at the same time.
Cons. Drive cost ($150-400 each), courier cost ($50-150 metro / $200-500 remote), end-to-end time longer than a fast cloud transfer, drive has to be returned or replaced if the operator's kit.
When it's the right choice. Deliverables over about 100 GB to recipients with limited bandwidth. Effectively the default for many regional or remote-area clients.
Operator places the deliverable on their own hosting platform (cloud storage with web access) and provides a download link. Recipient downloads at their own pace.
Pros. No physical logistics, link can be shared with multiple stakeholders, often integrates with operator's archive system.
Cons. Recipient bandwidth determines transfer time; recipient storage capacity has to absorb the download; portal hosting is operator infrastructure that has its own continuity risks (what happens if the operator changes platforms or goes out of business).
When it's the right choice. Deliverables under about 50-100 GB to recipients with good bandwidth, particularly when multiple stakeholder access is wanted.
Operator uploads directly to the buyer's nominated cloud bucket (S3, Azure Blob, Google Cloud Storage). Buyer's cloud infrastructure handles storage and downstream access.
Pros. Buyer controls storage and access from day one, fast network within cloud regions, scales to any size, integrates with the buyer's existing data infrastructure.
Cons. Requires the buyer to provide upload credentials or use a transfer mechanism the operator's tools support, cloud egress costs apply when downstream consumers download from the bucket, requires buyer-side cloud literacy.
When it's the right choice. Large deliverables, multi-cycle programmes where consistent storage matters, organisations that already operate in cloud.
Operator uploads to a buyer-provided endpoint (SFTP, network share over VPN, transfer service). Effectively a managed version of the cloud upload with the destination being the buyer's existing infrastructure rather than cloud-native storage.
Pros. Lands in the buyer's existing systems without additional cloud setup; familiar to corporate IT.
Cons. Bandwidth-bound; large deliverables can saturate the buyer's network for hours; corporate IT has to allow the connection (often a delay).
When it's the right choice. Mid-sized deliverables, organisations with established SFTP/transfer infrastructure, buyers without cloud setup.
For a 250 GB deliverable bundle (typical engineering-grade capture on a 150 ha mixed site), end-to-end transfer time by mechanism:
| Mechanism | Typical end-to-end | Notes | |---|---|---| | Physical drive (courier) | 1-3 business days | Independent of recipient bandwidth | | Operator portal, 100 Mbps recipient | 6-8 hours | Plus download initiation time | | Operator portal, 25 Mbps recipient | 22-26 hours | Often runs over multiple days | | Operator portal, 10 Mbps recipient | 55-60 hours | Practical timeline 4-5 days | | Direct cloud upload, region-matched | 1-3 hours | At cloud-to-cloud speeds | | Network transfer, corporate VPN at 50 Mbps | 11-14 hours | Plus IT setup time |
The mechanism choice should reflect the infrastructure available. Defaulting to "we'll just download it" without checking recipient bandwidth is where the transfer-day surprise lives.
For organisations that retain LiDAR data in cloud storage:
Hot storage (frequently accessed) — typical $20-25 per TB per month on AWS S3 Standard or equivalent Azure / GCP tiers.
Cool storage (occasionally accessed) — typical $10-15 per TB per month on S3 Standard-IA or equivalents.
Archive storage (rarely accessed) — typical $1-5 per TB per month on Glacier or equivalents, with retrieval lead time and per-retrieval fees.
Egress — bandwidth out of cloud to your network or other clouds. Typical $80-100 per TB egressed, applies whenever data is downloaded from the cloud.
Cost picture for a programme that captures 500 GB per cycle and retains all cycles indefinitely:
| Cycle count | Stored data | Hot storage / year | Cool storage / year | |---|---|---|---| | 1 cycle | 500 GB | $130 | $80 | | 3 cycles | 1.5 TB | $390 | $230 | | 5 cycles | 2.5 TB | $650 | $380 | | 10 cycles | 5 TB | $1,300 | $760 | | 20 cycles | 10 TB | $2,600 | $1,520 |
Plus retrieval and egress costs whenever data is accessed. For active programmes, hot storage is typically right for the current cycle; cool or archive for older cycles.
For programme captures retained over years, three common archive patterns:
1. Hot-cold tiering. Current 1-2 cycles in hot storage for active use; older cycles transitioned to cool or archive storage automatically. Cloud platforms support lifecycle rules to handle this without manual management.
2. On-premise plus cloud backup. Active data on organisational storage; cloud as archive backup. Works for organisations with established storage infrastructure; doesn't scale as well for very large multi-decade programmes.
3. Operator-hosted archive. Operator retains the raw archive; buyer holds processed deliverables. Cheaper for the buyer up front, introduces dependency on operator continuity.
For multi-year programmes, worth explicitly discussing the archive strategy at programme inception rather than letting it default to "we'll figure it out later".
(See annual capture programmes article for the programme-level decisions, and the multi-year vendor relationships article for archive ownership considerations.)
Not every consumer needs the full deliverable. Three common consumption patterns:
Design tools (Civil 3D, OpenRoads, 12d Model). Need the surface deliverables (DTM, contours, LandXML) and sometimes a subset of point cloud for spot verification. Typically 20-30% of full deliverable size.
GIS systems (ArcGIS, QGIS). Need point cloud or DTM for spatial analysis, sometimes classified vector layers. Typically 50-80% of full deliverable depending on workflow.
Web viewers and stakeholder access. Need streaming-optimised formats (Potree, Cesium 3D Tiles) rather than raw LAS. Typically 10-20% of full deliverable size after streaming preparation.
Archive only. Needs the complete deliverable plus raw source archive for potential reprocessing. Full size.
Scoping the consumer pattern up front lets the deliverable distribution match the actual need rather than sending the full bundle to every consumer.
Three patterns we see when storage and bandwidth aren't planned:
The transfer that runs for days. Operator delivers via portal; recipient on slow connection; download initiates, runs slow, sometimes fails and restarts. The four-hour transfer becomes a four-day exercise; project schedule slips.
The storage that wasn't budgeted. Six months into a programme, the IT cost line for LiDAR archive becomes visible — and it wasn't in the original procurement budget. Awkward reconciliation follows.
The deliverable nobody can open. Workstations sized for typical CAD work struggle with multi-GB point clouds. The deliverable sits in storage; the design team works from a derived DTM; the value of the point cloud classification work is partially wasted.
Five diagnostic questions during scoping:
1. "What's the typical deliverable file size for my project shape?" Forces the operator to estimate rather than wait for delivery.
2. "What transfer mechanisms do you offer, and which is appropriate for my bandwidth?" Tests whether the operator has thought about transfer infrastructure.
3. "What's the recommended storage and retention approach for our project?" For one-off vs programme captures.
4. "Can the deliverable be split into tiles or subsets for different consumers?" Reduces distribution load downstream.
5. "What's your data continuity guarantee on your hosting platform?" For operator-portal deliveries, what happens if the operator changes infrastructure.
Drone LiDAR file sizes by project type: 5-15 GB for small sites, 60-400 GB for typical engineering, 200-1,000 GB for corridors, multi-TB for programme captures across cycles.
Four transfer mechanisms with realistic timing on a 250 GB bundle: physical drive (1-3 days regardless of bandwidth), operator portal (6-60 hours depending on recipient bandwidth), direct cloud upload (1-3 hours region-matched), network transfer to corporate (11-14 hours at 50 Mbps).
Cloud storage cost: $20-25/TB/month hot, $10-15 cool, $1-5 archive plus egress at $80-100/TB. Multi-year programme archives accumulate to multi-thousand-dollar annual storage bills.
Three multi-year archive patterns: hot-cold tiering with lifecycle automation, on-premise plus cloud backup, operator-hosted archive.
Four downstream consumption patterns: design tools (20-30% subset), GIS systems (50-80%), web viewers (10-20% streaming-optimised), archive (full).
Three common infrastructure-failure patterns: multi-day transfers, unbudgeted storage cost, deliverable nobody can open. All preventable with five diagnostic questions during scoping.
The infrastructure conversation should happen before capture, not at handover. The cost of fixing it after is always more than the cost of asking before.
If your project is large enough that transfer and storage will be substantial, or your downstream consumer environment has specific bandwidth or platform constraints, worth talking through the infrastructure picture at quotation. We can recommend deliverable splits, transfer mechanisms and archive strategy that match your environment rather than defaulting to whatever's convenient at handoff.
The tile-structure decisions that determine how a large deliverable gets split for distribution and downstream consumption. The structural complement to this transfer-and-storage piece.
The programme-level architecture that determines multi-year storage costs. Storage and bandwidth become substantial budget items at programme scale; worth designing into the programme rather than discovering at cycle 3.