This is an issue that was partly opened here and it was decided to open a new issue for it.
When using r.in.pdal to create a raster of return numbers it imports just the first 5. The produces map is correct but it lacks returns.
r.in.pdal -e -o input=point_cloud.laz output=point_cloud_return_number type=CELL resolution=1 dimension=returns
Majorly we find 5 reurns from LiDAR scanners. Modern RIEGL scanners can have up to 7 returns. PDAL shows 7 return values.
@marisn
I'm not certain if this is a bug (or do we want to tackle this). Looking at the PDAL code, it assumes for LAS files with version being >1.4 to always follow 15 return definition. As GRASS just reads the data provided by PDAL, doing otherwise would require to implement some kind of logic to what to display if there are no 15 returns in the data. Not worth it.
There are generally not 15 returns in the majority of data, but this is just the number of returns that the format 1.4 can store. I am not sure what do you mean by "logic to what display".
This is an issue that was partly opened here and it was decided to open a new issue for it.
When using r.in.pdal to create a raster of return numbers it imports just the first 5. The produces map is correct but it lacks returns.
r.in.pdal -e -o input=point_cloud.laz output=point_cloud_return_number type=CELL resolution=1 dimension=returnsMajorly we find 5 reurns from LiDAR scanners. Modern RIEGL scanners can have up to 7 returns. PDAL shows 7 return values.@marisn
There are generally not 15 returns in the majority of data, but this is just the number of returns that the format 1.4 can store. I am not sure what do you mean by "logic to what display".