r-lidar / lidR

Airborne LiDAR data manipulation and visualisation for forestry application
https://CRAN.R-project.org/package=lidR
GNU General Public License v3.0
606 stars 132 forks source link

lasnormalize bug on lidR 2.0 #184

Closed tiagodc closed 6 years ago

tiagodc commented 6 years ago

Hi there, I've been trying to run lasnormalize with the DTM as input for ground reference and I've been getting the following error:

Error: 1 points were not normalizable because the DTM contained NA values. Process aborded.

It happens even if I remove or replace the NAs in the DTM raster object - which was generated using the grid_terrain function. I only got it to work when setting the DTM pixel resolution to 5m or more, for higher resolutions the error happens recurrently.

Hope it has an easy fix! If a data sample is necessary for reproducing the error I can share the point cloud.

Cheers

Jean-Romain commented 6 years ago

Were does your DTM come from ? If it comes from an external source it is not a bug but a feature. If the DTM comes from grid_terrain I must fix that (again).

What happened here is that 1 point was not associated with a pixel of the DTM. This point is likely to be on the very edge of the DTM.

  1. If the DTM come from an external file it means that your DTM does not encompass your data (error of a single point).
  2. If the DTM comes from grid_terrain the problem comes from the fact that the ground points don't encompass all the other points and thus the DTM can't encompass all the points. To fix that I added extra interpolation within a additional buffer but maybe in your case this buffer is too tiny because your data have a weird shape or a locally low point density or any other data specific issue I was not able to predict.
tiagodc commented 6 years ago

The DTM was generated using grid_terrain - all data processing was done in lidR actually.

The point cloud I'm using is from terrestrial laser scanning, so the point density is very high around the scanner, and gets progressively lower at the edges. Here follows an image:

image

Jean-Romain commented 6 years ago

Ok I got it, your point cloud is very weird compared to regular ALS data. This is, with no doubt, the explanation for your issue. I guess in this image red are ground points and blue are others. Using version 2.0 you can try to enforce the positioning of the interpolation providing a raster instead of a number to the parameter res

# make a raster that encompass the point cloud
layout = raster(extent(las))
res(layout) = 5

# Force to interpolate in these pixels
dtm = grid_terrrain(las, res = layout, algorithm = kriging(k = 10))

Obviously you will get some very very weak elevation prediction in pixels that are far from ground points (potentially outside of the point cloud itself, for example on bottom left of the picture) and weak prediction in pixels that are not well covered by ground points (for example blue points on the right side of the picture) but you won't have points that fall in a non interpolated area.

Notice that lidR was not designed for TLS. Some stuff migh work but the amount of data generated by TLS is so huge that it is almost impossible to play with TLS in R

tiagodc commented 6 years ago

OK, that should solve it. Thanks!