I am cc-ing "the LAS room" on this one as this would be the right
place to continue this discussion should it be necessary.
>> Because PDAL does not support "extra bytes" in LAZ (or LAS) files it will
>> crash if you open LAZ files containing "extra bytes". This is trouble-some
>> because "extra bytes" are exported to the LAZ format, for example, by
>> RIEGL's RiPROCESS to store attributes such as echo width and normalized
>> reflectance values.
> But why would PDAL support extra bytes for LAS 1.2 and 1.3?
Extra bytes have been with the LAS format since day 0. In the LAS
header there is a field that specifies the point format being used (0,
1, 2, 3) and then there is a field that specifies the size of each
point record. Should the point size implied by the point type be
smaller than the specified point record size any reader had to either
skip those "extra bytes" if it did not know how to interpret them or
load them into a separate attribute field assuming there was some way
for it to know what they meant.
The only thing that is new with LAS 1.4 is that there is now a way to
descriptive those extra bytes in the specification. Hence, unknown
arrays of "extra bytes" become suddenly meaningful to anyone via the
LASF_Spec VLR with user_ID 4. Because it does not hurt to put unknown
VLRs into earlier versions of the specification (they could safely be
ignored but may as well be parsed if known) RIEGL also put their
"extra bytes" descriptions into earlier versions. And so does LAStools
and probably a few other softwares ...
> As something of a newcomer to the LAS world, I have always found the idea of
> "extra bytes" rather confusing. Until LAS 1.4, the LAS specifications say
> nothing about including extra bytes with the point data, instead indicating
> that extra information should be stored in the VLR and EVLR records.
If you have extra information that is per point such as an "echo
width" you need something like "extra bytes" to avoid IO hampering
file seeks. VLRs and EVLRs are better suited to store information that
is per file such as projection information, spatial indexing,
compression parameters, additional mission info ...
> seem to imply that point records should be of a standard, fixed length, and
> so, by my interpretation, the inclusion of "extra bytes" would actually be a
> violation of the LAS specification for versions 1.0 through 1.3.
If point records were meant to be a standard fixed size as implied by
the point type then the inclusion of the point record size would have
not been a redundant source for error. While the concept of "extra
bytes" per point is not explicitely stated in the spec in earlier
versions it has always been there ... just like the potential presence
of this additional information that does not clash with anything
written in the specification:
// if the header_size is larger than implied by the version
// if the offset_to_point_data is larger than the combination of
header size and all VLR sizes
- fast tools to play with large LiDARs