problems with normalize_intensity and gpstime

[wiesehahn]

I try to normalize the intensity of LAS data but still struggle.

sensor <- track_sensor(las, thin_pulse_with_time = 0.001, Roussel2020(interval = 0.5, pmin = 50))
lasnorm <- normalize_intensity(las, range_correction(sensor, Rs = 2000, f = 2.3))

results in the same error as reported in #548 (3 coordinates detected in the sensor positions, parameter 'elevation' is not considered. Error: 'gpstime range from the sensor does not contain gpstime range from the point-cloud)

I can see that gpstime is provided with two decimals in the LAS file (is that normal?) while sensor$gpstime is rounded to 0.5 (I guess because we told the algorithm to do so with interval = 0.5. So I tried to change the interval to 0.01 to give two decimals, but this results in no sensor observations with pmin = 50. I had to fiddle around with it until I got a lot of sensor positions with pmin=5 (is it problematic to use a low number like that?).

So I got a lot of sensor positions with two decimals using sensor <- track_sensor(las, thin_pulse_with_time = 0.001, Roussel2020(interval = 0.01, pmin = 5)) but the error remains because range(las$gpstime) is -1.00 55688.52 and range(sensor$gpstime) is 53918.44 55227.10.

Do I have to filter the pointcloud by gpstime in advance to get rid of the pulses with -1?

[Jean-Romain]

Please share your problematic dataset and a reproducible example. I can't answer without testing myself.

[wiesehahn]

Ok, sorry for not checking this earlier. The reason was not the decimals of gpstime but some strange points with gpstime -1. Using filter = "-drop_gps_time_below 0" when reading the data solved this issue.

[Jean-Romain]

This is definitively not a legit gpstime.

[wiesehahn]

I just tried with further files and ran into the above mentioned error again. This time I figured out that 78 points had a much lower gpstime (265599) than the others (>113498325). These points are somehow erroneous, when reading the lasfile I get

Warning messages:
1: Invalid data: 78 points with a return number equal to 0 found. 
2: Invalid data: 78 points with a number of returns equal to 0 found.

I was able to process the file by adapting to filter = "-drop_gps_time_below 265600", however I want to process an entire catalog and I dont know if this is always related to gpstime.

What would be an appropriate way to process these files anyway? I think I would simply filter all files at read time which could not be processed by normalize_intensity(). Is there something like -drop_return_number 0 or -drop_invalid_data? Or is it better to filter after reading, e.g. prior or inside the normalize_intensity() function?

[Jean-Romain]

If you have corrupted points that are corrupted in very different way from file to file you can hardly construct a consistent set of rules. You must check your files one by one to identify the specific problem of each one. To get a list of the filters

readLAS(filter = "-h")

[wiesehahn]

Unfortunately the data is not provided in a gold standard form but checking each of the tiles is maybe not the best idea with over 50.000 of them. :)

Thanks for the list of filters, I will try to construct some rules and hope for the best.

[Jean-Romain]

Definitively not doable indeed.