[pdal] Riegl extrabytes stripped

[Kristian Evers]

Sure, I totally agree with that. I think what confused me here was that I knew that the VLR and extrabytes were related (though PDAL does not know that) and just assumed that the extrabytes would be passed along when adding the writers.las.forward=vlr option. Now that those two things have been decoupled in my mind I think it is very reasonable what PDAL does. And I believe my two initial questions has been answered very nicely.


1.       No, it would not make sense change the behavior regarding the LASF_Spec VLR’s

2.       Yes, I had overlooked the extra_dims option in the las reader/writers

This has been a very fruitful discussion for me. As per Howards suggestion I am working on a tutorial that explains this stuff in more detail and hopefully others will find this easier in the future.

Thanks,

Kristian

Fra: Andrew Bell [mailto:andrew.bell.ia at gmail.com]
Sendt: 3. oktober 2016 18:19
Til: Kristian Evers
Cc: pdal at lists.osgeo.org
Emne: Re: [pdal] Riegl extrabytes stripped



On Mon, Oct 3, 2016 at 9:52 AM, Kristian Evers <kreve at sdfe.dk<mailto:kreve at sdfe.dk>> wrote:
Ah, there it is!

--readers.las.extra_dims="amplitude=uint16,pulse_width=uint16"

I completely missed that option. I expected PDAL to just transfer the complete data records when running a basic read-write pipeline, but the way it works makes sense when you think about the format-independent nature of PDAL. It is a bit cumbersome to use the extrabytes in las version earlier than 1.4. For now I am stuck with version 1.3 and will just have to pay extra attention when reading/writing files.

It's hard to know what should be handled as the "normal" case.  When you're just working with LAS, it seems like PDAL should know what to do, but even then it's not clear.  As an example to go with your case, if you're using PDAL to construct some extra dimension that you wanted written out as extra bytes with each record, you certainly don't want the LAS_Spec/4 VLR forwarded or the existing extra bytes just tacked on.  We try to make the common things easy, but sometimes what's common for one person isn't for others.  Perhaps other times we just didn't anticipate well.

--
Andrew Bell
andrew.bell.ia at gmail.com<mailto:andrew.bell.ia at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20161003/4d94385d/attachment.html>