2

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?

  • 2
    Are you sure you're comparing like for like? That is, are you comparing ground points in one dataset to the canopy points of another dataset? How were the rasters created? Do the pixels represent the average point value? Maximum? Minimum? There could be any number of reasons why these values are different. what about units? Is one dataset in metres and the other in feet? In my experience, even when there is a lot of professional attention given to things, people still miss stuff. – Fezter Apr 3 '18 at 0:43
  • 3
    You may be working with two different vertical datums. – Jeffrey Evans Apr 3 '18 at 0:48
  • It sounds like one is ellipsoidal heights and the other in a local datum, just as @JeffreyEvans suggests. Read any metadata or report you have and look for the height datum; apart from height do buildings/roads align in the X and Y? – Michael Stimson Apr 3 '18 at 1:11
3

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.

  • I would second @Aaron's last sentence. When in doubt about processed data, go back to the raw version. – Techie_Gus Apr 3 '18 at 5:00
  • Thanks to all of you - good ideas. I'll look into this over the next few days and report back. – Stu Smith Apr 3 '18 at 15:04
1

@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.

  • As promised, a report: both lidar DEMs are NAVD88 Geoid 03, bare earth, identical vertical units, feet. I don't have access to the original point cloud or pre-processing steps. I neglected to mention in OP that the overlap area mean difference between the DEMs = 0.46 feet, with Std Dev = 2.19. BUT! Upon further review: the area is steep and densely forested. The greatest elevation differences between the two DEMs occurs on steep forested slopes. But very little difference (about +/- 0.1 feet) where roads occur, open to the sky. Thus IMHO the two are very close, differ due to trees/terrain – Stu Smith Apr 24 '18 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.