Re: [PulseWaves] Waveforms in WDP format

[Martin Isenburg]

Hello Mohsen,

let me get the bad news off my chest first. You will not find any emitted (aka outgoing) waveforms in the LAS 1.3/1.4 FWF format because the waveform extension of the LAS format does not provide the capacity to store this. The lack of this capacity was a large part of the motivation for creating PulseWaves ...

The relationship between LAS points and the wavedatapackets is fairly well described in the specification. Here some pseudo code how to get the XYZ position of a waveform sample for a return with the coordinates XYZreturn[3] and the wavepacket with the direction XYZt[3] and the location and temporal spacing. Look into the source code of laswaveform13reader.cpp which is part of LAStools' LASlib for more details:

BOOL LASwaveform13reader::get_sample(U32 s_count, F64 *XYZsample, I32 &sample)
{
  if (s_count < nsamples)
  {
    F32 dist = location - s_count*temporal;
    XYZsample[0] = XYZreturn[0] + dist*XYZt[0];
    XYZsample[1] = XYZreturn[1] + dist*XYZt[1];
    XYZsample[2] = XYZreturn[2] + dist*XYZt[2];
    sample = samples[s_count];
    return TRUE;
  }
  return FALSE;
}

If you use lasview.exe to view a file in LAS 1.3 FWF format you can "turn on" the viewing of a subset of the waveforms (right click for pop-up menu or press the hot-key capital 'W'). What you should look for are areas where the pulse generated multiple returns. The "red-colored" high-intensity parts of the otherwise green waveforms should then always coincide with the LAS points. You may want to extract a subset to look at with this little "trick".

las2las -i las13.las -o las13_sub.las -subseq 0 1000
laszip -i las13_sub.las -o las13_sub.laz -waveform
lasview -i las13_sub.laz

and to "look" as the ASCII waveform contents run

las2txt -i las13_sub.laz -o las13_sub.txt -parse xyziaWV
and
las2txt -i las13.las -o las13.txt -parse xyziaWV

obviously the latter will take forever and create a humongous file for large inputs but CTRL^C is your friend here.

I am not a big friend of LAS 1.3 FWF. I just had a double traumatizing experience at the NCKU in Taiwan that received one delivery of LAS 1.3 FWF from Optech where an non-specification conform version of the LAS 1.3 format was used that had 243 instead of 235 bytes in the header. It seemed the format was corresponding to an early working draft (non-ratified) of the LAS 1.3 format. They also received one delivery from RIEGL where all the waveform direction vectors were pointing the wrong way. However, that was a reasonably easy fix because LAStools has an on-the-fly transform for that:

lasview -i las13_flipped.las -flip_waveform_direction

Regards,

Martin @LaserPulseWaves

--
http://pulsewaves.org - no emitted wave left unstored

On Sun, Mar 10, 2013 at 4:26 PM, Mohsen Azadbakht <m.aza...@gmail.com> wrote:

Hi,

 

I'm working on Full-waveform LiDAR data in my research.

The data that I’m working on is a LAS 1.4 file with an external wavefom set (in WDP format)

The problem is about the waveforms in WDP format. I can’t figure out the correct format of saving the waveforms related to the records in the LAS file.

I was wondering if you had any documents about the format of waveforms in *.WDP files (external VLRs).

I've already tested LASTOOS and PULSEWAVES to read the header file and other useful information. In addition, I've read LAS Specification documents (V. 1.3 & 1.4) from ASPRS.

I need to have all waveforms (both emitted & backscattered pulses) as well as other useful information (scan angle, lat, long,...) from the LAS file. The relation between points in LAS format and waveforms in WDP files is not clear to me.

 

Information from the wavepacket is as follw:

 

Wavepacket Index   1  1

                     Offset  0  0

                     Size     200  200

                     Location    0.00447582   100000

                     Xt              -9.72150e-013  1.04614e-012

                     Yt              -7.56717e-012  8.12185e-13

                     Zt              -1.90327e-012  1.45418e-012

Regards,

Mohsen Azadbakht

--
--
Post to "PulseWaves" by email to pulse...@googlegroups.com
Unsubscribe by email to pulsewaves+...@googlegroups.com
Visit this group's message archives at http://pulsewaves.org
 
---
You received this message because you are subscribed to the Google Groups "PulseWaves - no pulse left behind" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pulsewaves+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Thomas Knudsen]

On Monday, March 11, 2013 9:08:53 AM UTC+1, Martin Isenburg wrote:

I am not a big friend of LAS 1.3 FWF. I just had a double traumatizing experience at the NCKU in Taiwan that received one delivery of LAS 1.3 FWF from Optech where an non-specification conform version of the LAS 1.3 format was used that had 243 instead of 235 bytes in the header. It seemed the format was corresponding to an early working draft (non-ratified) of the LAS 1.3 format.

Actually this is in conformance with the LAS1.3 R10 specification, as approved 2009-07-14 and available from http://www.asprs.org/a/society/committees/standards/asprs_las_spec_v13.pdf

The 243 bytes, rather than 235, come from an extension of  the "Number of points by return" array from 5 to 7 elements, and hence from 20 to 28 bytes.

It is, however, a bug in the specification, since chapter 1 of the spec ("Purpose, scope, and applicability"), under the header "Compatibility with LAS 1.2" states that "One unavoidable change has been made to the Public Header Block; Start of Waveform Data Packet Record. This long, long has been added to the end of the block and thus little or no change will be needed in LAS 1.2 readers that do not need waveform data".

So the intention was definitely to be backwards compatible, but the normative text defining the "Public Header Block", Table 4.3, clearly states (if you sum up all the field sizes), a header of 243 bytes.

The blunder was corrected in R11 of the spec, dated october 24 2010, but still listed as "approved 2009-07" (http://www.asprs.org/a/society/committees/standards/LAS_1_3_r11.pdf ), so from july 2009 to october 2010, the LAS 1.3 spec was wrong, and appeared to support up to 7 reflections per pulse.

What a mess! - future standards archaeologists will probably find material for dozens of scientific papers on this subject :-)

[Alex Yeryomin]

On Thursday, January 23, 2014 11:50:15 PM UTC+7, Thomas Knudsen wrote:

What a mess! - future standards archaeologists will probably find material for dozens of scientific papers on this subject :-)

Thomas, totally agree.


I have just processed a sample using Optech LMS 2.4.0.12689, which is the current official customer release version, to LAS 1.1, 1.2, 1.3 and 1.4 formats. lasinfo reports the next statistics (I removed unrelated parts):

  version major.minor:        1.1
  system identifier:          'ALTM Pegasus HA500'
  generating software:        'OptechLMS'
  file creation day/year:     19/2014
  header size:                227

  version major.minor:        1.2
  system identifier:          'ALTM Pegasus HA500'
  generating software:        'OptechLMS'
  file creation day/year:     19/2014
  header size:                227

  version major.minor:        1.3
  system identifier:          'ALTM Pegasus HA500'
  generating software:        'OptechLMS'
  file creation day/year:     19/2014
  header size:                235

  version major.minor:        1.4
  system identifier:          'ALTM Pegasus HA500'
  generating software:        'OptechLMS'
  file creation day/year:     19/2014
  header size:                375

All headers' size are in accordance with the latest LAS specifications.

As I can remember, Optech LMS has never written 245 bytes to LAS file header. That's strange... Martin, could you please send me a file with a wrong header size or at least the full report using lasinfo.