Why the Geospatial Industry Keeps Paying Twice for the Same Data

Six-figure LiDAR survey. Delivered. Filed. Forgotten.

I watched this happen dozens of times. Government agencies, mining companies, infrastructure owners. The data came back perfect. The hard drive went into a desk drawer. Nobody opened it again. Nobody got fired. Nobody changed the process.

The industry calls this a delivery problem. It is not. It is a structural failure dressed up as a workflow gap, and it compounds every quarter the data sits unused while someone commissions a new survey of the same site.

The part of the value chain nobody prices

In every LiDAR programme I have seen, organisations account for two line items: capture, then processing. Those two dominate the budget conversation. Analysis, sharing, and storage barely register. They are also the line items that determine whether the first two were worth spending at all.

The cost is documented. Construction Industry Institute data shows rework driven by inaccurate or siloed information consumes an average of 12 percent of total project costs, with nearly half of that attributed to miscommunication and inaccessible data. McKinsey research on digital twin adoption puts the efficiency and capital use improvement at 20 to 30 percent for organisations that integrate spatial data across teams. The spread between those two numbers is the cost of treating spatial data as a project deliverable instead of an enterprise asset.

The first reason data goes unused: it gets mistaken for a picture

LiDAR and point cloud data get treated as a visual medium. People look at it, decide it is ugly, and move on. I have heard this more times than I can count. Dismissing point cloud data because it looks sparse or unfamiliar is like dismissing a spreadsheet because the cells are not pretty. You are looking at the container and ignoring what is inside.

A point cloud is a dataset with visual qualities. It is not a visual product with data attached. That distinction changes how it gets managed, shared, and used. A dataset has value across teams, over time, and across use cases nobody anticipated when the survey was commissioned. A visual product gets used once and filed.

The second reason: only two people on the team can open it

In practice, one or two specialists on a team can work with raw point cloud data. The wider team cannot open it, cannot interrogate it, and cannot extract value from it without routing through those experts. The practical value of the data shrinks to the capacity of those one or two people.

Point density has grown by orders of magnitude in the last decade. A survey LiDAR that captured 100,000 points per second in 2012 now captures millions. The data got better. The tools did not keep pace. Better data, harder to access, more expensive to use. The access problem did not get solved. It got worse.

A capture is not a deliverable. It is a timestamp.

A single LiDAR survey of a mine pit, a highway corridor, or a coastal asset is useful. Two surveys of the same site taken twelve months apart are more than twice as useful. They are a change detection record. Five surveys give you a trend. Ten give you an asset lifecycle in three dimensions.

The fourth dimension is time. The data does not depreciate with use. It compounds. A 2019 survey of an active pit is worth more in 2026 than it was in 2019, because now you can compare it against six subsequent captures and see exactly what moved, settled, eroded, or changed. That comparison did not exist when the first survey was delivered. Accumulated data over time created it.

The 4D point cloud is the spatial foundation of that capability. You cannot build a meaningful digital twin on a single static capture. You build it on accumulated captures that let you model change, predict failure, and make maintenance decisions on evidence instead of schedules. You cannot run a 4D programme if each capture goes into a drawer. The data needs to be accessible, comparable, and usable by people who are not LiDAR specialists.

Enterprise IT solved this problem thirty years ago. Geospatial is still catching up.

Before Euclideon, I worked at Microsoft, SAP, and NetApp helping enterprise customers implement data resiliency and availability programmes. Data lifecycle frameworks. Access policies. Utilisation metrics. I helped organisations define who can reach their data, how it gets used, and what happens when it goes stale, and I operated inside those same standards myself. Having no plan for data you spent significant capital to acquire was considered negligent. Geospatial has no equivalent standard.

The founding premise at Euclideon, carried into Nuclideon, was simple: data that is not accessible has no value. udCloud started from that idea. Get the data out of the drawer and onto a screen any stakeholder could open.

The complete answer goes further. Enterprise customers already have AWS and Azure contracts with committed spend they are trying to justify and maximise. The question is not whether to put the data online. The question is where, and who controls it. udCloud manages spatial data wherever the customer needs it to live, including inside their existing cloud environment. That is not a storage product. It is an enterprise data integration position. Spatial data alongside the rest of the organisation's assets, governed by the same policies, accessible through the same infrastructure: that is what makes it an asset instead of a file.

The cheapest data you will ever have

The spatial data your organisation captured in the last five years is the cheapest data you will ever access. The capture cost is paid. The processing is done. The asset exists. What it lacks is a workflow to make it useful beyond the day it was delivered.

How much of it is actively informing decisions today? If the answer is not close to all of it, that gap is a cost. It does not appear on any budget line. It is real, and it compounds every year the data sits unused.