Convert LAS FWF data file in discrete

94 views
Skip to first unread message

Mauro Assis

unread,
Dec 6, 2016, 3:48:08 PM12/6/16
to LAStools - efficient tools for LiDAR processing
Hi,

I´ve some FWF LAS data. For each file data, I´ve the LAS v1.3 file and the corresponding WDP file. I´d like to see those LAS files discrete data in Fusion, Fugroviewer or another free LAS viewer, however, they don´t open it. Fugroviewer tells it doesn´t support FWF data (but I´m interested only in discrete view). I converted the file to LAZ, as Fugroviewer support this format, and I got the following error message: Program supports zipped point type 0~3 only!

Is there another way to convert LAS "FWF" file to discrete?

Tks in advance,

Mauro Assis

Martin Isenburg

unread,
Dec 6, 2016, 5:19:54 PM12/6/16
to LAStools - efficient command line tools for LIDAR processing, PulseWaves - no pulse left behind, The LAS room - a friendly place to discuss specifications of the LAS format
Hello Mauro,

given that we just met in Brazil and looked at similar data together I assume that those are the LAS 1.3 FWF files collected with a Trimble Harrier 68 (that uses a RIEGL Q680i under the hood) and exported by Trimble LPMaster that we had talked about. I still have one of those flight-lines on my laptop and a lasinfo report is attached.

The LAS 1.3 FWF stores LiDAR as points that are still *discrete* returns. What makes LAS 1.3 different from LAS 1.2 is that two additional point types were introduced, namely point data format 4 and 5 that store *additional* 29 bytes of information with each discrete return that are called "wave packet". Point type 4 is basically point type 1 with these 29 additional bytes and point type 5 is basically point type 3 with these 29 additional bytes.

The lasinfo report tells me that you have point type 4. Or in other works point type 1 (which is 28 bytes per point) plus these 29 additional bytes (which sums up to 57 bytes per point).

[...]
  point data format:          4
  point data record length:   57
[...]

These *additional* 29 bytes of information (aka "wave packets") describe the which waveform type is referenced, its storage location in the corresponding WDP file, the size of the waveform on disk, the location of the return within the waveform, and the direction vector. You find this in the lasinfo report as well (some of the values look a little odd)

[...]
  Wavepacket Index    1 3
             Offset   0 7498667680
             Size     160 480
             Location 5566.77 228567
             Xt       -1.#INF 1.#INF
             Yt       -1.#INF 1.#INF
             Zt       -8.79543e+030 4.30256e+031
[...]

For pulses with multiple returns this leads to *a lot* of redundant information as each discrete return has to repeat these 29 bytes (albeit only location changes). This makes full waveform storage in LAS 1.3 FWF especially in forestry a very verbose adventure and was one of the reasons for creating the PulseWaves format (http://pulsewaves.org).

Back to your question.


With las2las you can simply strip out these 29 additional bytes by downgrading each return from point type 4 to point type 1:

las2las -i NP_T-356_FWF.las ^
            -set_point_type 1 ^
            -odix _gone. -olaz

The resulting lasinfo report is attached. But this does not remove the 10 wave packet descriptors (7 of which are unused dummies) that are stored as VLRs in the LAS header. A more clean solution would be to remove all VLRs and then add the projection VLR back in. At the same time we should lower the resolution that the coordinates of each point of this tropical forest scan are stored with from the current mm to a more reasonable cm (for airborne scanning). This will also lead to much better LASzip compression). So in your case the improved command would be:

las2las -i NP_T-356_FWF.las ^
            -rescale 0.01 0.01 0.01 ^
            -remove_all_vlrs ^
            -epsg 31980 ^
            -set_point_type 1 ^
            -odix _really_gone -olaz

The resulting lasinfo report is attached. Also note the difference in compressed file size because we added '-rescale 0.01 0.01 0.01'. By throwing out pure error information far below the scanner noise, hence numbers that are the mere result of what happens to be in the floating points registers after doing a lot of math with the laser range, IMU, and GPS measurements, we get a file that is over 50 MB smaller.

 274,695,592 NP_T-356_FWF_gone.laz
 220,257,950 NP_T-356_FWF_really_gone.laz

Regards from Istanbul,

Martin @rapidlasso


NP_T-356_FWF_info.txt
NP_T-356_FWF_gone_info.txt
NP_T-356_FWF_really_gone_info.txt
Reply all
Reply to author
Forward
0 new messages