Skip to content

What Processing a LiDAR Point Cloud Actually Costs

10 min read · updated August 11, 2026

There is no public price list for LiDAR processing, so nothing here is quoted. Every figure is derived from an input named in the sentence that uses it, and the arithmetic is the part worth keeping — substitute your own numbers and the structure of the answer does not change.

The inputs, all of them assumptions

workload
  corridor mapping from a drone-mounted sensor
  25,000,000 points per flight
  12 flights per day
  -> 300,000,000 points per day
  250 working days per year
  -> 75,000,000,000 points per year

per-point processing time, single-threaded
  decode and reproject          0.3 microseconds
  statistical outlier removal   4.0 microseconds
  ground classification         3.0 microseconds
  normal estimation             6.0 microseconds
  semantic classification       8.0 microseconds
  ------------------------------------------------
  total                        21.3 microseconds

prices, stated as assumptions to be replaced
  16-vCPU compute instance     $0.80 per hour
  object storage               $0.023 per GB-month
  egress                       $0.09 per GB
  technician, fully loaded     $60 per hour
Cloud prices change, vary by region and by provider, and are negotiable at volume. The four price figures above are placeholders chosen to be in a plausible band for list-price object storage and general-purpose compute; look up your own provider’s current rates before using any total below as a budget.

The per-point times are the input most worth replacing with your own, and they are also the easiest to measure: time one stage on one flight and divide. They vary by more than an order of magnitude with implementation. A neighbourhood operation that rebuilds a k-d tree per call rather than reusing one, or that queries a fixed radius in a region where the radius contains thousands of points, can be a hundred times slower than the figures above. If your measured number is far higher, the fix is almost always structural rather than a matter of buying a larger instance.

Compute, derived per stage

single-threaded time for one day of data
  300,000,000 x 21.3e-6 s = 6,390 s = 1.775 core-hours

on a 16-vCPU instance at an assumed 70 % scaling
  6,390 / (16 x 0.70) = 570 s = 0.159 instance-hours

cost per day
  0.159 x $0.80 = $0.13

cost per year (250 days)
  $0.13 x 250 = $32

per stage, per day, at the same rate
  decode/reproject        $0.002
  outlier removal         $0.024
  ground classification   $0.018
  normal estimation       $0.036
  semantic classification $0.048

Thirteen cents a day. That is the honest result and it is the most useful thing on this page, because it is not what anyone expects. A point is a handful of arithmetic operations and a k-d tree query, and modern CPUs do enormous numbers of both. If you moved the semantic stage to a GPU processing an assumed 500,000 points per second, one day takes 600 seconds at an assumed $1.20 per hour — twenty cents, which is more than the CPU cost it replaced and buys latency rather than money.

The corollary is that optimising per-point compute is almost never where the return is. Halving the normal estimation cost saves under two cents a day. It may still be worth doing for turnaround time, which is a different objective and should be argued as one.

Two things distort this picture and both are worth checking before accepting the total. Scaling efficiency of 70% across sixteen vCPUs is optimistic for anything that shares a spatial index between threads; measure it, because at 30% efficiency the compute line more than doubles — and still costs less than a third of a cent per flight. And the arithmetic assumes the pipeline is throughput-bound rather than idle. An instance held running while it waits for a file to arrive is billed for the waiting, which is how a workload with thirteen cents of actual computation turns into a monthly bill for a long-lived machine that is busy for nine minutes a day. Batch the work, or run it on something that scales to zero.

Storage and egress, which recur

raw volume, at 28 bytes per point (LAS format 1)
  300,000,000 x 28 = 8.4 GB per day
  x 250 days       = 2,100 GB = 2.1 TB per year

derivatives: assume the archive also keeps a classified
copy, a tiled copy for the viewer, and a decimated
preview -> a factor of 3 on top of raw
  = 6.3 TB per year

storage cost at $0.023 per GB-month
  year 1: 6,300 GB x $0.023        = $145 / month
  year 2: 12,600 GB x $0.023       = $290 / month
  year 3: 18,900 GB x $0.023       = $435 / month

  cumulative over 3 years, billed monthly on the
  average balance, is roughly $10,400

egress, if the day's data is downloaded once
  8.4 GB x $0.09 = $0.76 per day = $189 per year

egress, if somebody pulls the whole 3-year archive once
  18,900 GB x $0.09 = $1,701 in a single afternoon

Storage is the cost that behaves differently from the others: it is recurring, it accumulates, and it is charged on everything you have ever collected rather than on what you are working with. Three years in, storage costs roughly a hundred times what compute does, and the ratio keeps widening.

Two mitigations follow directly. Compress the archive — see point cloud compression, where a lossless ratio measured on your own data divides the storage line directly, and where the derivative copies are usually the first thing that should not have been stored uncompressed. And tier it: raw data older than a defined age moves to archival storage at a fraction of the price, with a retrieval charge that is acceptable precisely because nobody reads it.

The number that dominates

assume a technician spends 2 hours per day on QA:
inspecting classification results, fixing misclassified
regions, checking registration, rejecting bad flights

  2 hours x $60 = $120 per day
  x 250 days    = $30,000 per year

compare, per day:
  compute   $0.13
  storage   $4.80   (year-1 average, per day)
  egress    $0.76
  human   $120.00

human time is roughly 900x the compute cost.

This ratio is the reason the interesting optimisation is never the inner loop. Anything that removes a manual step pays for an enormous amount of machine time. Running the semantic classifier three times with different parameters and picking the best by an automated metric costs forty cents and might save an hour of somebody looking at it. Reprocessing a whole year of archive to try a better ground filter costs about $32 of compute — the decision is entirely about whether the result is worth a technician’s review, not about the compute.

It also reframes what a quality gate is for. An automated check that catches a bad flight before a person opens it — the kind derived on the quality check page — is worth far more than its runtime suggests, because the thing it saves is priced at $60 an hour and the thing it costs is priced at fractions of a cent.

One caution about the human line: it is the figure most likely to be wrong in your own version, and usually wrong downward. Two hours a day is what a smooth day looks like. A flight that has to be rejected and reflown, a classification model that starts drifting on a new site type, or a coordinate reference system recorded incorrectly on ingest can each consume a day of somebody’s attention, and the last can invalidate a month of deliverables. Those events are rare enough to leave out of a per-day average and expensive enough to dominate an annual one, so budget them separately rather than folding them into an hourly rate.

Memory is the constraint, not money

The engineering difficulty in this workload is not cost, it is fitting a flight into RAM. Per-point overhead adds up faster than the record size suggests:

per point, held in memory during processing
  coordinates, 3 x float64      24 bytes
  normal, 3 x float32           12 bytes
  intensity + classification     4 bytes
  k-d tree node overhead        ~32 bytes
  ------------------------------------------
  total                        ~72 bytes

one flight of 25,000,000 points
  25e6 x 72 = 1.8 GB

with 8 parallel workers on one machine
  8 x 1.8 = 14.4 GB, before the framework's own
  copies during a transform

Which is why real pipelines are tiled and out-of-core: split the cloud into spatial tiles with a buffer overlap wide enough that neighbourhood operations near a tile edge see the neighbours they need, process tiles independently, and merge. The buffer width is set by the largest neighbourhood radius in the pipeline, and getting it wrong produces a seam artefact along every tile boundary that is easy to miss and painful to explain.

What actually changes the total

  • Collect less. The largest lever by a wide margin, and it acts on storage, egress, compute and human time simultaneously. Halving the point count halves every line above. The density and resolution page derives what resolution the deliverable actually requires, which is usually less than what was captured.
  • Compress the archive and tier it. Acts on the only line that recurs and accumulates.
  • Do not egress. Process where the data already is. The full-archive download above cost more in one afternoon than three years of compute.
  • Automate a review step. Priced at 900× compute, this is where the money is, and it is the least likely thing to appear on a cost spreadsheet.
  • Do not optimise the inner loop first. It is satisfying, measurable, and worth about two cents a day.