[pdal] Riegl extrabytes stripped

[Pete Gadomski]

Andrew,

Here's a 43 point las file w/ Riegl's extra bytes that I use for
developing against this stuff. I was *not* able to reproduce the OP's
issue — `pdal translate -i 1.2_1_extra_bytes.las -o out.laz
--writers.las.forward=vlr --writers.las.extra_dims=all && pdal info
--metadata out.laz` reported the presence of the extra bytes vlr, and
the extra bytes were present on each point. However, `pdal info -p 0
out.laz` did not report the values stored in those extra bytes
(Reflectance, Amplitude, and Deviation) — not sure if that's supported
ATM.

The VLR description is also changed from "RIEGL Extra Bytes" to "Extra
Bytes Record", not a big deal but may surprise some end-users who
expect a "forward" option to forward without change.

HTH,
Pete

On Mon, Oct 3, 2016 at 6:25 AM, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
> On Mon, Oct 3, 2016 at 6:28 AM, Kristian Evers <kreve at sdfe.dk> wrote:
>>
>> Hi.
>>
>>
>>
>> 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:
>>
>>
>>
>> “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.”
>>
>>
>>
>> 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.
>
>
> 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.
>
> Without a sample data file, I really don't know what's going on or why the
> data isn't being forwarded as expected.
>
>>
>> The extra-bytes in this case contains data that PDAL has no way of knowing
>> how to reconstruct properly.
>
>
> 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.
>
>>
>> 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).
>
>
> Waveform data is explicitly not supported by PDAL (we don't support point
> formats 4, 5, 9 and 10).
>
>> 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.
>
>
> 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.
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.2_1_extra_bytes.las
Type: application/octet-stream
Size: 9860 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20161003/322322eb/attachment-0001.obj>