Why such a large difference between overlapping LiDAR DEM values?

Question

Background:

Using Arc Desktop 10.5.1, I have been tasked with mosaicking two adjacent LiDAR rasters (I'll call them A and B). They were flown, processed and supplied under contract by different vendors, A in 2013 and B in 2015.

Each raster was accompanied by a detailed project report, signed off by a professional land surveyor. Both projects used surveyed, GPS ground control points. Reported accuracy and RMSE values are all less than 0.1 feet.

Both rasters were supplied to me in the same CRS, with identical cell sizes (three feet), both single band, 32-bit floating point. To ensure that both rasters align, I snapped B to A .

A and B share a common boundary. They overlap along that boundary, with the overlapping width varying between ~ 300 - 600 feet.

The problem:

I expected the elevation values between the two projects to be very similar. However, where they overlap, the cell values for A and B differ, ranging from -96 to +57 feet (!)

Please allow me to restate this: If I select a point within the overlap zone, the reported elevation values for A and B may differ by as much as 96 feet.

How is this huge range (153') in elevation values between the two rasters possible when so much professional attention was given to each of the two projects?

Answer 1

Any of a number of issues could cause the irregularities you are observing. What strikes me most is that you are comparing two derived LiDAR products in raster format. You will need to compare the following between A and B to get a sense of the differences you are observing:

1. What vertical datum was used? Units?
2. Did the vendor sign off on the accuracy of the LiDAR point cloud data or the derived raster products (DEMs).
3. What sort of pre-processing was done on the point cloud data (outliers, classification, filtering scan line angles, dealing with overage, etc)? If the point cloud data had sloppy preprocessing or classification, you will see variations in derived products.
4. Who created the derived LiDAR products? Was it the vendor or some GIS tech with little experience?
5. What algorithm was used to create the DEMs? These interpolation methods can vary widely.

Without knowing the answers to 1-5, I suspect you will find differences in preprocessing of point cloud data or the interpolation method used to generate the derived DEM. If you cannot answer the above questions, I would advise comparing the raw point cloud data.

Answer 2

@Aaron brings up some good general QA/QC practices when receiving LiDAR data from a vendor. However, such a large variation between your two rasters of over 100' when both LiDAR datasets were recently collected and all due diligence was followed points to the following causes:

1) For starters, both datasets are likely on NAVD88 vertical datum since they were recently collected, but are you sure both rasters are in the same VERTICAL units? A large elevation discrepancy could be the result of one having vertical values in feet and the other in meters. If you're using ArcGIS Desktop, stream in the USGS Topo map service and see where the contours are at. These are usually displayed in feet and should give you the ballpark elevation you would expect your data to be at. You can also use Google Earth and this Verge plugin to approximate a NAVD88 orthometric height at your site - http://www.metzgerwillard.us/verge/verge.html

2) If your units are both the same, then I'd bet this is your problem: You say you're comparing the overlap of the DEM's, but are you sure there are actually LiDAR points in the areas you are looking at? Rasters are perfect rectangles but LiDAR acquisition swaths are not. In your rectangular raster, the flight path may have cut a diagonal across it since you are at the edge of the project limits. Then the DEM was probably interpolated with Natural Neighbors binning to fill everything in, so you may be comparing interpolated voids in the data at these overlaps.

3) Not as likely, but a third potential issue is that one of the DEM's was run with both the ground and non-ground points and is a DSM. If you run the contours, you can identify these since the contours will be very jagged and irregular as they go up and over trees, buildings, etc. I doubt this is the problem though but I've seen it before.