Local vs cloud LiDAR processing: control, cost, and data governance
Classification has to run somewhere. For most teams the real choice is not which algorithm to trust but where the work physically happens — on a workstation under the desk, or on rented machines in a data centre reached over the network. That decision quietly shapes how fast a project moves, what it costs, and who is allowed to hold the data along the way.
Neither answer is universally right. Cloud processing solved real problems, and there are jobs where it stays the sensible pick. But the trade-off is rarely laid out honestly from the side that has already moved the data onto the network. This piece walks through the arithmetic of moving LiDAR blocks, the way each cost model actually scales, the data-governance rules that settle the question outright for some programs, and the cases where cloud genuinely wins.
The upload reality: moving the data is often the slowest step
LiDAR blocks are large. A single classified tile can run to several gigabytes, and a full campaign — a corridor, a municipality, a watershed — reaches tens of gigabytes or more before any processing begins. Cloud classification cannot start until those points sit on the remote machine, which means every job carries an upload before it carries any compute.
The arithmetic is worth doing once, because it is easy to underestimate. Fifty gigabytes at a sustained 100 Mbps uplink is 400,000 megabits divided by 100 megabits per second — roughly 4,000 seconds, or over an hour, and that assumes the connection holds that rate the whole time. Field offices and many business connections upload far slower than they download, so a real transfer can stretch across an afternoon. Local processing skips this step entirely: the block is already on the machine that will classify it.
How the cost models differ in shape
Cloud and local processing do not just cost different amounts — they cost in different shapes, and the shape is what matters over a project's life. Cloud classification is usually billed per gigabyte processed or per job submitted, so the bill scales with data volume. Feed it more points and it costs more, in a fairly direct line.
The part that surprises teams is reprocessing. Classification is not a single pass — parameters get tuned, a threshold gets adjusted, a tile gets re-run because the first result put vegetation into the ground. On a per-job or per-gigabyte model, every one of those iterations is billed again. Three passes over the same block cost roughly three times the compute, even though only the last one ships. Local processing inverts this: the cost sits mostly in hardware you already own or amortize over years, and a re-run is just more time on a machine that is already paid for. The marginal cost of the fourth iteration is close to zero.
Data governance and where point clouds may travel
For a growing set of programs, the question is settled before cost or speed enters the conversation. Public-sector mapping, defence-adjacent surveys, and critical-infrastructure work — power corridors, water systems, transport — often come with rules about where the point cloud is allowed to go. Procurement terms and contract clauses can require that data stay on controlled machines, remain inside the country, or never leave a specific network at all.
Uploading to a third-party data centre, however well run, is a data-governance event: it has to be reviewed, approved, and sometimes it is simply not permitted. Local classification sidesteps that review because the data never moves. The points stay on the machine they arrived on, the work happens there, and the deliverable leaves as a finished product rather than a raw scan crossing a network boundary. For teams whose contracts turn on data control and privacy, that is not a convenience — it is the very basis for being allowed to bid.
Iteration: run, review, adjust, re-run
Classification is iterative by nature. A first pass is run, a reviewer opens the result, finds low vegetation biting into the ground on a slope or a building edge misread, adjusts the settings, and runs it again. That loop — run, review, adjust, re-run — repeats until the block holds. How long each turn of the loop takes is what actually governs a project's pace.
Local processing keeps that loop tight: adjust a parameter and re-run immediately, watching the result on the same screen. A cloud loop adds a queue and two transfers to every turn — upload the change or wait for a slot, let the job run, download the result to review it. When a block needs five or six passes, those added minutes compound into the difference between finishing a tile in a morning and carrying it across two days.
When cloud genuinely fits
None of this makes cloud the wrong choice everywhere. There are real situations where renting compute is the better call, and pretending otherwise would be dishonest:
- Burst capacity for a one-off campaign. When a single massive dataset lands and there is no time to stand up hardware, renting a large machine for a week can beat buying one that then sits idle.
- Teams without capable workstations. If the local machines cannot carry the compute, cloud puts serious processing power within reach without a hardware purchase.
- Collaboration and visualization of finished products. Sharing a classified block with a client, or streaming a large cloud to reviewers across several offices, is something hosted infrastructure does well.
- Long-term archive. Keeping finished deliverables somewhere durable and offsite is a genuine strength of cloud storage, separate from where the classification actually runs.
Choosing where classification runs
The honest way to decide is to weigh the two models across the dimensions that actually differ, then match them to the job in front of you.
| Dimension | Local | Cloud |
|---|---|---|
| Data movement | None — the block stays put | Upload every block before compute |
| Iteration speed | Immediate re-run on the same screen | Queue plus transfer on every pass |
| Cost shape | Mostly fixed hardware, cheap re-runs | Scales with volume and every reprocess |
| Data governance | Data never leaves the machine | Upload must be reviewed and approved |
| Scale | Bounded by your own hardware | Elastic burst capacity on demand |
With those in view, a short checklist settles most cases:
- Do contract or procurement rules restrict where the point cloud may travel? If yes, local is often the only compliant answer.
- How many review-and-adjust passes does a typical block take? The more iterative the work, the more a tight local loop pays off.
- Is this steady ongoing work or a one-off spike? Steady volume favours owned hardware; a rare massive campaign can favour rented burst capacity.
- Do your workstations already have the compute to carry the job? If yes, the cloud's main advantage narrows sharply.
- What has to be shared, and with whom? Final-product collaboration and long-term archive are where hosted infrastructure earns its place.
This is the ground Vecten Desktop is built for. It runs classification locally, on your own workstation, with no upload required for inference — the block stays where it is, the review loop stays fast, and the data-governance question stays simple. For teams whose work is iterative, whose contracts constrain where data lives, or who would rather spend on hardware they keep than on compute they rent by the gigabyte, local is not a compromise. It is the fit. And for the genuine burst-and-share cases above, the two approaches are not enemies — many teams classify locally and use cloud storage for the finished archive.
