Open Remi-C opened 7 years ago
Without going all the way to fullwaveform, a similar issue already arises for multireturn lidar scans, where some attributes are constant among the echo points generated by the same emitted pulse (nb of echoes, time, position of the lidar, direction of the pulse...) and other attributes are not shared (range, x , y , z , intensity, classification, waveform samples...).
Point clouds are usually exported by replicating the pulse attributes on all the echo points (thereby losing the information of the set of emitted pulses that had no return, which helps detecting the sky in MLS or TLS scans, but that is another question...).
A possible compression could be to use rle dimensional compression on all pulse attributes, but that is suboptimal (the RLE length which is indeed the number of echoes, is repeated for each pulse dimension independently).
I think a promising possibility is to model that as pairs of pcpatches
PulseWaves has been over this ground too https://groups.google.com/forum/#!forum/pulsewaves Is there opportunity for reuse of that rather than making something new?
Is there no (-gasp-) doc in PulseWaves? @mbredif in most use case you don't want your multi-echo points to be second class citizen (having to process something to get them for instance). In multiple return scenario, the several returns are several successive points, therefore their shared attributes will be efficiently compressed, but XYZ will be hard to compress. This multi echo stuff would be very annoying if we were using delta compression (which is the obvious next todo for increasing compression perf btw). For an urban scene with ground lidar, I get about 1/30 points with multi echo. However for an aerial lidar over trees I get 2/3 of points with multi echo. Cheers
Would it be possible to simply include the waveform values along with the rest of the point dimensions?
For example, in our data the return waveform is an array of 528 values. Could we just insert the 528 values as individual dimensions (r_1, r_2, r_3, ..., r_528), in addition to the usual X/Y/Z? We don't need to do anything fancy with the waveform, like finding peaks or extracting pieces of it - we just need to get the full waveform back for any points/laser shots of interest.
Would there be an advantage to storing all the waveform values in a single dimension, as suggested in Option#2 above?
Due to question on the mailing list, 2 potential options to store fullwaveform lidar data in pgpointcloud.