improving FWF wording of LAS 1.4 specification

33 views
Skip to first unread message

Martin Isenburg

unread,
Jun 20, 2015, 11:25:41 AM6/20/15
to The LAS room - a friendly place to discuss specifications of the LAS format
Hello,

The description of the FWF part of the LAS 1.3 (points types 4 and 5) and LAS 1.4 specifications (points types 4, 5, 9, and 10) seems insufficient to properly implement the attachement of waveforms to discrete returns. That RIEGL, Trimble, and Optech needed help to fix their LAS FWF exporters to match those of the Leica ALS XX software (which I assumed to be the "gold standard" as Paul Galla from Leica pretty much single-handed designed the FWF extension for LAS many years ago) made it  already clear that the FWF part of the specification was not detailed enough.

The need to improve the FWF part of specification was just reinforced dramatically now that also Leica has sent me some non-specification-conform LAS FWF data exported from their new CloudPro software. When not even the company that originally designed the format can get it right in a new product release then there really must be a short-coming in the wording of the specification.

I think including a simple illustration would already help tremendously. Attached you find my first draft for such an illustration. Do you find any errors or have any suggestions for clarity?

Regards,

Martin @rapidlasso

PS: Careful, this may be just another "exceedingly clever business strategy" of mine ... (-;

LAS_FWF_illustration.png
LAS_FWF_illustration.pdf

Evon Silvia

unread,
Jun 22, 2015, 12:38:29 PM6/22/15
to las...@googlegroups.com
It looks like a pretty good conceptual illustration, but to check the math wouldn't I need the XYZ Scale and Offset values from the LAS header? I thought the X(t), Y(t), and Z(t) fields were relative to the scaled values, not the integral values.

I see that all three points "share" a waveform data packet in that they all have the same offset. I haven't noticed that Leica implemented their LAS 1.3 output in this manner, but I coded my software to handle it this way anyway. Out of curiosity, have you observed this practice of "shared" waveform data in other sample datasets? It seems to me to be an obvious space-saver.

Evon

--
--
You are subscribed to "The LAS room - a friendly place to discuss the the LAS or LAZ formats" for those who want to see LAS or LAZ succeed as open standards. Go on record with bug reports, suggestions, and concerns about current and proposed specifications.
 
Visit this group at http://groups.google.com/group/lasroom
Post to this group with an email to las...@googlegroups.com
Unsubscribe by email to lasroom+u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "The LAS room - a friendly place to discuss the LAS and LAZ formats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasroom+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Martin Isenburg

unread,
Jun 29, 2015, 4:16:38 AM6/29/15
to The LAS room - a friendly place to discuss specifications of the LAS format, Paul....@leicaus.com
Hello,

It looks like a pretty good conceptual illustration, but to check the math wouldn't I need the XYZ Scale and Offset values from the LAS header? I thought the X(t), Y(t), and Z(t) fields were relative to the scaled values, not the integral values.

I agree that me reporting the unscaled / untranslated raw integer X / Y / Z values can be miss-leading here. I changed the figure by replacing the currently reported  raw integer X / Y / Z coordinates for each point with the already scaled and translated x / y / z fixed-point coordinates.

I see that all three points "share" a waveform data packet in that they all have the same offset. I haven't noticed that Leica implemented their LAS 1.3 output in this manner, but I coded my software to handle it this way anyway. Out of curiosity, have you observed this practice of "shared" waveform data in other sample datasets? It seems to me to be an obvious space-saver.

I have not paid particular attention to that. I had assumed that Leica would export it like that but this is not that easily accomplished. For example, the (not very well promoted) extension to the WPD (or is it WDP) parts of a LAS FWF of the LASzip compressor does not support such shared waveforms but will compress one waveform copy for each return, effectively de-referencing any shared waveforms. The LAS specification does not make a recommendation here so I guess either would be fine. A sentence or two on the two existing possibilities should probably be added to the specification. 

Or maybe lets ask Paul Galla from Leica who authored the LAS FWF extension originally. Paul ... is (are) the waveform segment(s) allowed to be shared by its returns?

Martin @rapidlasso
Reply all
Reply to author
Forward
0 new messages