<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 3, 2016 at 6:28 AM, Kristian Evers <span dir="ltr"><<a href="mailto:kreve@sdfe.dk" target="_blank">kreve@sdfe.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="DA" link="blue" vlink="purple">
<div class="m_-1979222928945909850WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I have some laz-files that incoorporates Riegl’s extrabytes waveform extension [0]. I am running the files through a PDAL pipeline but unfortunately the VLR header and extrabytes are stripped from the resulting files.
 This behavior of writers.las is documented on the webpage [1]. The forward options description ends with:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:65.2pt"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#404040;background:#fcfcfc">“VLRs can be forwarded by using the special value ‘vlr’. VLRs containing the following User IDs are NOT forwarded: ‘LASF_Projection’,
 ‘LASF_Spec’, ‘liblas’, ‘laszip encoded’. These VLRs are known to contain information regarding the formatting of the data and will be rebuilt properly in the output file as necessary. Unlike header values, VLRs from multiple input files are accumulated and
 each is written to the output file. Forwarded VLRs may contain duplicate User ID/Record ID pairs.”<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#404040;background:#fcfcfc"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#404040;background:#fcfcfc">The Riegl extrabytes are stored with user ID “LASF_Spec” and record ID 4. I accept that it is necessary to treat some VLR’s differently than others,
 but I don’t think this is one of them.</span></p></div></div></blockquote><div><br></div><div>The LASF_Spec is defined in the LAS 1.4 specification and needs special handling by PDAL.  In order to support LAS 1.4, PDAL needs to write arbitrary dimensions to the output as extra bytes and also needs to be able to construct the LASF_Spec VLR to reflect the data in the extra bytes.</div><div><br></div><div>Without a sample data file, I really don't know what's going on or why the data isn't being forwarded as expected.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DA" link="blue" vlink="purple"><div class="m_-1979222928945909850WordSection1"><p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#404040;background:#fcfcfc"> The extra-bytes in this case contains data that PDAL has no way of knowing how to reconstruct properly.</span></p></div></div></blockquote><div><br></div><div>I don't believe this is true.  The VLR should describe the data on input, which should allow it to also properly reconstructed on output.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DA" link="blue" vlink="purple"><div class="m_-1979222928945909850WordSection1"><p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#404040;background:#fcfcfc"> I believe something similar happens when storing waveform data as specified in LAS v. 1.3 since it is also defined
 as VLR’s with user ID “LASF_Spec” (and record ID in the interval 100-355).</span></p></div></div></blockquote><div><br></div><div>Waveform data is explicitly not supported by PDAL (we don't support point formats 4, 5, 9 and 10).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DA" link="blue" vlink="purple"><div class="m_-1979222928945909850WordSection1"><p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif";color:#404040;background:#fcfcfc">I would much prefer the extrabytes attached to each record just be forwarded like any other VLR and extrabytes data. A way to do this would be
 to only ignore VLRs with certain user ID’s that matches data that PDAL knows how to construct properly at write-time.</span></p></div></div></blockquote><div><br></div><div>PDAL is handling formats other than LAS.  The current handling allows data read from some other format to be properly written to a LAS 1.4 file, using the LASF_Spec VLR and extra bytes to store data not supported by the native LAS point formats.  In order to diagnose your issue, I need to examine the data in more detail.</div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</div></div>