Re: [LAStools] Internal waveform data not getting stored

[Martin Isenburg]

Hello Evon,

the only three LAStools that can deal with full waveform data are
las2txt, laszip, and lasview. I have not tried this but you should be
able to do this by using laszip with a combination of the
'-keep_every_nth 20' filter with the '-waveform' option.

laszip -i LDR110907_172633_4.LAS ^
-keep_every_nth 20 ^
-waveform
-o LDR110907_172633_4_subsampled.LAZ

It will, however, store the waveforms to a separate compressed WPZ
file. Alternatively you can request uncompressed output from laszip.
The waveforms will then be stored to a separate WPD file. LAStools are
so memory efficient because they do as much of their computations in a
streaming manner as possible. Writing points and waveforms to a single
LAS file with the waveform block at the end is (in general) an
operation that cannot be streamed (unless some assumptions are made up
front).

laszip -i LDR110907_172633_4.LAS ^
-keep_every_nth 20 ^
-waveform
-o LDR110907_172633_4_subsampled.LAZ

Also see this discussion for a similar operation on LAS 1.3 FWF files:

https://groups.google.com/forum/#!topic/lastools/T7EBS8zfLAA

Regards,

Martin @rapidlasso

On Thu, Sep 19, 2013 at 1:18 AM, Evon Silvia
<esi...@watershedsciences.com> wrote:
> Hello all,
>
> I have a 1GB LAS 1.3 file with waveform data stored internally. The file's
> pretty old and straight from Leica's ALSPP so no PulseWaves option, sadly. I
> can submit if required, but it's pretty big...
>
> I'm trying to subsample (and compress, eventually) it using las2las to make
> it a more manageable size, but the output file does not retain the waveform
> data and I get a strange error. Am I getting the syntax wrong or is there a
> bug?
>
> las2las -i LDR110907_172633_4.LAS -o Every20.las -keep_every_nth 20 -v
> reading 4254716 and writing all surviving points ...
> WARNING: header->start_of_waveform_data_packet_record is 242541719. writing
> 0 instead.
> total time: 0.661 sec. written 212735 surviving points.
>
>
> Thanks!
> Evon
>
> --
> Evon Silvia Geomatics Specialist
> P: 541-752-1204 | E: esi...@wsidata.com | W: wsidata.com
> WSI Corvallis, OR WSI Portland, OR WSI Oakland, CA
> 517 SW 2nd St., Suite 400, Corvallis, OR 97333
>
>
>
> --
> Download LAStools at
> http://lastools.org
> http://rapidlasso.com
> Be social with LAStools at
> http://facebook.com/LAStools
> http://twitter.com/LAStools
> http://linkedin.com/groups/LAStools-4408378
> Manage your settings at
> http://groups.google.com/group/lastools/subscribe

[Martin Isenburg]

Hello Evon,

looks correct and sorry for the many warnings. (-: You are always
skipping 19 points so that the offset into the waveform file does not
increase by one times the size of the last waveform packet (as it
would be expected for a sequential read) but by about 20 times that
size. So yes, the offsets will change and "move closer together". You
should be able to visualize (and thereby check) the resulting LAS/WDP
file pair with the pulseview.exe viewer from PulseWaves that offers
native read support of LAS/WDP FWF files via on-the-fly conversion to
PulseWaves.

Regards,

Martin @rapidlasso

On Thu, Sep 19, 2013 at 5:49 PM, Evon Silvia
<esi...@watershedsciences.com> wrote:
> Hello Martin,
>
> Thank you for your response. It appears to work as expected (I think?),
> except that the output produces a series of warnings as follows:
>
> WARNING: gap in waveform offsets.
> WARNING: last offset plus size was 237167676 but new offset is 237171516
> (for point 1413680)
> WARNING: gap in waveform offsets.
> WARNING: last offset plus size was 237171772 but new offset is 237175612
> (for point 1413700)
> (etc)
>
>
> Since the waveform offsets are supposed to change due to the point order and
> sequence changing, is this describing expected behavior or another issue?
>
> Evon