LiDAR, mobile mapping, and machine learning for 3D infrastructure modeling — lessons from processing terabytes of spatial data and building AI pipelines for geospatial analysis.
Most AI research happens in the image domain — clean, 2D, nicely cropped tensors that fit in GPU memory. The world, however, is three-dimensional, noisy, irregularly sampled, and enormous. Geospatial data — LiDAR point clouds, aerial imagery, satellite rasters, GIS layers — does not conform to the assumptions baked into standard deep learning pipelines. Working with it requires rethinking data structures, scale, and what “a sample” even means.
My work in this area spanned AI-powered geospatial analysis, mobile mapping systems, and infrastructure modeling for large-scale national projects. It was some of the most engineering-intensive work I have done, and it shaped how I think about the gap between research and deployment.
A mobile mapping system is a vehicle — truck, van, occasionally a boat or backpack — equipped with an array of sensors: multiple LiDAR units, calibrated cameras, IMU, GNSS, and sometimes additional payloads like ground-penetrating radar. It drives roads, collects data at high speed, and the challenge begins immediately.
The data volume is massive. A single day of collection can produce terabytes of raw sensor data. The sensors need to be precisely calibrated relative to each other (extrinsic calibration) and to absolute world coordinates (georeferencing). Any error in calibration propagates into every downstream product.
The output of a mobile mapping run is a georeferenced point cloud and synchronized imagery — the raw material for everything that follows.
A LiDAR point cloud is a set of 3D points with intensity values, return counts, and timing information. Unlike images, point clouds are:
Processing this at scale requires specialized data structures. We used octrees for spatial indexing, tile-based parallel processing for large point cloud manipulation, and purpose-built I/O pipelines since standard ML frameworks were not designed for this data modality.
The first major AI task is point cloud classification: labelling every point with a semantic category — ground, vegetation, building, power line, road surface, vehicle, noise. This is the foundation for every downstream product.
We built classification pipelines using a combination of:
Geometric features: computed locally for each point — planarity, linearity, sphericity, normal deviation. These capture local structure efficiently.
Deep learning backbones: we experimented with PointNet++, KPConv, and voxel-based approaches. The tradeoff between receptive field, memory footprint, and inference speed is non-trivial at production scale.
Post-processing: raw model outputs are noisy. Connected component analysis, morphological operations on rasterized outputs, and rule-based corrections are essential for production-quality results. Pure deep learning rarely produces clean enough outputs directly.
From classified point clouds, we derived topographic products: Digital Terrain Models (DTMs), Digital Surface Models (DSMs), building footprints, road centerlines, utility corridor mapping.
The accuracy requirements for these products are strict — centimetre-level in some cases. This meant investing heavily in quality control: automated checks for point cloud coverage gaps, classification consistency, and surface model artifacts, with human review workflows for edge cases.
The integration with GIS systems added another layer of complexity: coordinate systems, datum transformations, format standards (LAS, LAZ, GeoTIFF, GeoPackage), and interoperability with existing national mapping infrastructure.
The scale of these projects is qualitatively different from what most ML practitioners encounter. We were not training a model on a GPU for a few hours; we were processing entire national highway networks, urban blocks, and utility corridors.
This required:
The software engineering requirements are as demanding as the ML research. A model that achieves great benchmark numbers but cannot run reliably on 500GB point clouds is not a solution.
Working in geospatial AI gave me a deep appreciation for the gap between benchmark performance and production reality. The data modalities are different enough that standard approaches often fail, and the scale demands engineering discipline that academic ML rarely prepares you for.
More broadly, it reinforced that the hardest problems in applied AI are rarely the model itself. They are data quality, scale, calibration, evaluation, and integration — the infrastructure around the model. The model is often the easiest part.
This perspective shapes how I approach every ML problem I work on now: start with the data, understand the evaluation, design for scale, and treat the model architecture as the last decision, not the first.