In a previous issue of the True View Bulletin, I discussed LIDAR point “noise” and our EVO-based smoothing algorithm.
As a reminder, “noise” is an indication of how closely point data matches a known surface. We should more properly speak of this in terms of measurement precision, which is sort of the inverse of noise (high noise and low precision, high precision and low noise).
Ideally, we would set a laser scanner on a fixed tripod and shoot a perpendicular planar surface at a distance equivalent to our flying height from the scanner. For kinematic, spinning systems such as drone LIDAR, this is not a practical setup.
Instead we can examine a planar surface in the LIDAR project and measure the noise. We get a good heuristic feel for this by looking at a thin profile slice over a hard, planar surface such as a paved road. Most of the vertical point envelope will be noise. Figure 1 shows a profile I have cut along a hard surface road of data from a True View 515. The grid size is 10 cm x 10 cm. You can see we have peak-to-peak excursions of perhaps 12 cm.
Precision is not measured as a Peak-to-Peak (PTP) figure but rather the standard deviation to the mean (average) surface. Of course, we also have this tool built in to EVO. Testing the surface area where the profile was collected, we see a standard deviation of 3.63 cm (Figure 2). This is actually quite good for a 32 beam scanner! You’ll also note that the density is 676 points per meter squared so we are in the overlap region of multiple strips.
In some projects, this level of noise is objectionable. To address these situations, we include a tool called a Moving Least Squares Estimator in True View EVO. To make it easer to say, we just call it a point cloud smoother! This algorithm steps through a data set and tries to create a local surface. If successful, it fits local points to the surface, If it is not successful, it leaves the points as they are. The real beauty of this algorithm is that no parameters need be tuned and it does not smooth things you do not want to be smooth (such as wires). So far, I am just repeating what was discussed in a prior bulleting. Now for the new stuff!
A natural questions is “what does this do to project network accuracy?” Recall, network accuracy is a comparison of the data to a know reference network. We measure vertical “error” by sampling the project area using a method independent of the sensor. At GeoCue, we typically paint marks or use ceramic tiles to “signalize” these check points and then precisely measure their locations using a Global Navigation Satellite System (GNSS) Real Time Kinematic (RTK) rover (we recommend against leveling for collecting vertical control/check but that is the subject for a different article). We then look at the difference between these check points and the point cloud by taking essentially the average of the absolute value of these differences (the differences being called “residuals”). Since, mathematically, the absolute value is difficult to work with, we instead take the square root of the sum of the squared residuals. This final method is termed Root Mean Square Error (RMSE) and is the standard way to measure network accuracy, as quantified in the American Society for Photogrammetry and Remote Sensing (ASPRS) accuracy standards. Again, tools for doing these measurements and reporting results are built in to EVO.
We will use a True View 515 data set collected over our GeoCue campus in Triana, Alabama as our test data set. Figure 3 shows the distribution of checkpoints (they show as red/white crosses) for the project.
We flew this test flight using the True View 515 at a nominal flying height of 75 meters above ground level (AGL) at a speed of 5 m/s using a multirotor platform. The flight line pattern is shown in Figure 4 where the points have been colorized by flight line (Point Source ID). You can see in this figure that a number of check points are in regions covered by up to four overlapping flight lines. Other than the factory sensor calibration, I have done no processing whatsoever to change the geometry of these data (e.g. I have not run geometric correction tools on the data).
Running a network vertical accuracy test on these checkpoints provides the results of Figure 5 (again, these data were computed by the EVO “Control Points Reporting” tool. Note that I used 19 check points so this is a fairly good statistical sample.
The mean error of the data is -1.1 cm. This implies there may be a -1.1 cm systematic “bias” in these data. If we have sufficient check points (in this case, we do), we can justify removing this bias from the data, again, using a tool built in to True View EVO (this is the subject of another paper!). The total error range is 11 cm. Finally, the litmus test is the RMSE. For this project, you can see it is 3.2 cm. This is really quite good. Thus with an unadjusted True View 515 sensor, we are seeing precision of 3.63 cm at 1 σ (Figure 2) and a network accuracy of 3.2 cm RMSE. This is an excellent result for multiple flight lines from a 32 beam scanner!!
However…. as we discussed above, for some projects the “noise” level is objectionable. This is where our smoothing algorithm comes in. This tool (Figure 6) is implemented as an EVO “Point Cloud Task” and is very straight forward to use as there are no user adjustable “tuning” parameters.
On this small data set of my example (about 20 acres), it took less than 2 minutes to process. After processing, the smoothed LAS data are written to new files. This gives you the opportunity to do easy before-after comparisons. Figure 7 shows a profile in the same location as that of Figure 1 but this time with the smooth data. It really does not get any better than this!!.
I reran our precision tool on this smoothed data at the same patch as before. The results, shown in Figure 8, show a new precision level of 0.55 cm or 5.5 mm at 1 σ. This is about as good as one could hope to get!
That is all wonderful news but the question remains – did I degrade network accuracy in the process of data smoothing (a sad truth for many algorithms)? Well, this is easy to test. I just run the same set of checkpoints against this new smoothed data set using the EVO Control Points tool. The result is shown in Figure 9. Notice the mean error has decreased to 9 mm and the RMSE to 1.4 cm. Also note that the overall error range has reduced to 3.7 cm.
Now the reduction in overall project mean error might be a coincidence but even if it were not, it would not be of much concern since, with sufficient check points, we are justified in removing this bias. The important thing is the reduction in RMSE since RMSE is the overall network vertical accuracy assessment of the project. This reduction in RMSE is primarily due to a reduction in the vertical standard deviation (Sz in the accuracy report). You can see that Sz reduced from 3.0 cm in the raw data to 1.0 cm in the smoothed data.
Now one final comment on this. Many data smoothing algorithms destroy “fine” feature detail in the smoothing process. If you are interested only in a ground model, you might not care about this. However, for general purpose point cloud data that will be used for a variety of feature collection tasks, a significant degradation in point cloud detail is unacceptable. In Figure 10 I show a 3D view of a satellite dish that sits on top our machine shop. The left image is of the raw data whereas the right image is from the smoothed point cloud. Note that we do not observe any degradation in the detail of the smoothed data set. The dish is still fully preserved and the antenna protruding upwards to the right from the bottom of the dish looks to be unchanged.
So, the bottom line here is that you can safely use the EVO Point Cloud smoothing tool to reduce the noise in a LAS data set without a negative impact on network accuracy or point cloud “conformance.” There are many reasons to run EVO as your preferred point cloud processing tool. I think this one tool alone justifies the modest investment.