Raw LiDAR Is Not an Operational Layer
A LiDAR point cloud of 400 million returns per flight tells an operations team very little until those returns are classified, normalized, and converted into derivatives. LAZ and LAS files preserve the observations, but they are not the format most teams want to inspect while dispatching crews, monitoring a transmission corridor, or reviewing a change alert. A dashboard needs spatially indexed surfaces and measurements: ground elevation, surface elevation, vegetation height, slope, intensity, or a difference from a known baseline.
That distinction matters because point clouds and operational layers have different computational profiles. A point cloud is a collection of three-dimensional returns with attributes such as intensity, return number, classification, and timestamp. A dashboard usually needs a raster that can be requested by map tile, clipped to an asset, compared with another date, and rendered at several zoom levels. Sending the original cloud directly to a browser is usually too expensive in bandwidth and too slow for routine operations. The engineering work is the conversion between those two representations.
For a typical infrastructure workflow, the useful output may include a Digital Elevation Model, or DEM, a Digital Surface Model, or DSM, a Canopy Height Model, or CHM, and one or more quality or change layers. The CHM is commonly computed as DSM minus DEM. That arithmetic is simple. Producing surfaces that deserve to be compared across acquisition dates requires much more care.
From Returns to Derivatives
The first decision is what each return represents. Ground classification is generally performed against accepted ASPRS classification conventions, with algorithms and review processes separating ground points from vegetation, buildings, utilities, and other objects. A ground surface may then be generated from classified ground returns, often with emphasis on last returns where the sensor penetrates vegetation and records the terrain. The correct filtering strategy depends on point density, terrain, scan geometry, and the quality of the source classification.
A DSM retains the uppermost measured surface, including vegetation and structures. A DEM attempts to describe bare earth. Subtracting the DEM from the DSM produces a normalized height surface, but the result is only as meaningful as both inputs. Misclassified shrubs can create false ground elevations. Sparse returns can leave gaps or introduce interpolation artifacts. A change in acquisition density can make a later CHM appear different even when vegetation has not materially changed.
Other derivatives serve different operational questions. Intensity return rasters can expose differences in surface response, although intensity values need sensor and acquisition context before they are compared across flights. Return count rasters help identify areas where sampling is sparse or where vegetation structure is changing. Slope and aspect are useful for access planning, drainage review, and terrain risk. Normalized ground models can express object height above the local terrain rather than absolute elevation.
Processing pipelines should preserve provenance for each derivative. The metadata should identify the source flight, point density, classification version, cell size, vertical datum, horizontal CRS, interpolation method, no-data handling, and quality checks. Without that information, a dashboard can display a visually convincing raster while giving an operator no way to determine whether a reported change is environmental or a processing artifact.
Coordinate Alignment Is the Hidden Work
Most LiDAR integration problems appear after the derivative has been computed. LiDAR is often delivered in a local State Plane coordinate system using a NAD83-based EPSG definition. Satellite imagery may arrive in WGS84, commonly represented as EPSG:4326. The operational dashboard may render in Web Mercator, EPSG:3857. These systems are not interchangeable merely because every layer has latitude and longitude somewhere in its metadata.
Alignment requires a deliberate decision about the shared coordinate index. That index can include asset geometries, sensor locations, imagery footprints, raster tiles, and derivative cells. Horizontal datum, projection zone, vertical reference, units, axis order, and epoch can all affect the result. A vertical mismatch is particularly easy to miss because a raster can look correctly placed in plan view while its elevation values are offset.
Reprojection and resampling also add error. A CHM generated in a projected local CRS may be resampled into a Web Mercator tile grid for display. Nearest-neighbor resampling preserves categorical values but can look blocky. Bilinear or cubic methods produce smoother surfaces but can alter peaks, edges, and narrow features. Resampling a derivative twice is worse than defining a target grid once and producing or reprojecting the layer into that grid with known rules.
The point is not that LiDAR is harder than every other data source to integrate. Teams underestimate the coordinate alignment work because the first visual overlay often looks acceptable. A few meters of displacement can be operationally significant when a vegetation alert is associated with a conductor, road edge, parcel boundary, or sensor location. The pipeline needs automated checks for bounds, expected units, CRS identifiers, tile alignment, and control features before a derivative reaches an operator.
Change Detection Needs a Baseline, Not Just Two Flights
Change-from-baseline monitoring is often described as a raster subtraction problem. In one common vegetation workflow, the current CHM is subtracted from a baseline CHM, and an alert rule is applied when height change exceeds a threshold near an asset. The calculation is straightforward:
change = current CHM - baseline CHM
The interpretation is not. The two rasters must use compatible cell size, horizontal alignment, vertical units, and processing assumptions. If one flight has a different ground classification quality or substantially different point density, the difference surface may reflect acquisition conditions rather than physical change. Areas with insufficient returns should be marked as unknown rather than silently treated as zero.
Thresholds should also be tied to the operational question. A five-foot increase in vegetation height may be relevant near a transmission line but not across a broad forested area. A threshold can be applied to absolute height change, height above a conductor or terrain model, distance to an asset, or persistence across multiple observations. Alert logic may require a minimum contiguous area, a minimum number of valid cells, or confirmation from another data stream.
Consider a transmission corridor operator receiving quarterly LiDAR flights across 180 miles of right-of-way. The operational target is to publish updated CHM layers within 48 hours of flight delivery and flag vegetation encroachment near selected assets. The first flight produces a plausible derivative, but the LiDAR is in a State Plane NAD83 zone while existing ArcGIS layers and inspection assets were assembled under different CRS assumptions. If that discrepancy is discovered after thresholding and alert generation, the team has to revisit tile boundaries, asset intersections, and the baseline comparison. The derivative computation was not the schedule risk. Coordinate reconciliation was.
That workflow also illustrates why alert records need more than a map location. Each alert should retain the baseline date, current acquisition date, derivative versions, threshold, valid-data percentage, and the spatial relationship to the monitored asset. An operator can then distinguish a repeatable vegetation signal from an isolated cell created by a processing or alignment issue.
Serving Derivatives in a Live Workspace
Once a derivative has passed quality checks, it needs a delivery format suited to the dashboard. Cloud-Optimized GeoTIFF, or COG, is a practical choice for raster derivatives because internal tiling, overviews, and HTTP range requests allow clients to retrieve only the portions needed for a view. A CHM can be published at several resolutions, while a change raster can be queried or rendered only around assets with active monitoring rules.
Point clouds still have an important role in investigation. An analyst may need to inspect returns around a flagged tree, verify a classification decision, or examine whether a structure was captured. That does not mean the full LAZ or LAS file should be loaded into the primary dashboard for every user. The live workspace can use derivative rasters for routine navigation and retain links to the source cloud for targeted review.
Operational latency has several components: file delivery, decompression, ground classification, rasterization, reprojection, quality control, publication, cache availability, and alert evaluation. A stated 48-hour delivery objective should account for all of them. It should also define what happens when a tile fails validation. Publishing a partial derivative without an explicit coverage indicator can create more risk than delaying the entire affected area.
LiDAR itself is not real-time in the way a telemetry feed is. Flights have acquisition schedules, weather constraints, processing costs, and irregular cadence. Cost per flight can make frequent collection impractical, and DEM or DSM accuracy depends on point density and ground classification quality. CRS mismatches can create substantial rework even when the source data is otherwise excellent. The useful design is therefore a system that combines periodic LiDAR evidence with more frequent satellite imagery and sensor observations, while preserving the acquisition date and confidence of each layer.
Where Larx Fits in the Pipeline
Larx ingests LiDAR in LAZ and LAS formats, including datasets conforming to the LAS 1.4 standard, and can compute derivatives or accept derivatives produced by an existing processing pipeline. Those outputs can be aligned to a shared coordinate index alongside satellite imagery and sensor data, with the alignment rules retained as part of the layer workflow.
In the live workspace, teams can surface CHM layers and change-from-baseline rasters with the other operational context used to review an asset or location. The purpose is not to make a point cloud behave like a dashboard layer. It is to keep the source cloud available for technical inspection while presenting the smaller, indexed derivatives that support recurring decisions.
LiDAR derivatives are worth the pipeline complexity. The question is who owns that pipeline, including classification assumptions, CRS validation, resampling policy, baseline management, and failure handling. In current geospatial tooling, the difficult part is rarely drawing the raster. It is preserving enough lineage and spatial discipline that an operator can trust what the raster says, and can explain why it says it.