Validity of extra bytes at end of header

[esilvia]

Is it valid for LAS files to insert bytes between the end of the last VLR and the beginning of the point data records? LAS 1.4 R15 reads thus: Although it explicitly says not to extend the header record, it doesn't mandate that Offset to Point Data = Header Size + sum(VLR Size). It shouldn't affect a high quality LAS reader, but I can see it impacting poorly written readers that mistakenly expect the point records to begin immediately after streaming the last VLR, rather than relying on the Offset to Point Data.

I know of at least two software companies that leverage this ambiguity to inject non-VLR information into the header. I'm sure there's others and I'm not calling them out as making a mistake... they're just examples.

TerraScan has a long history of appending exactly two bytes to the end of the LAS header, after the VLRs but before the point data begins, presumably because the original LAS 1.0 header had a marker at the start of the point data record.

GeoCue also inserts additional bytes between the end of the last VLR and the start of the first point record, between a couple hundred bytes and tens of thousands of bytes. I haven't taken the time to dig deeper, but the samples I've seen don't appear to be undocumented VLRs.

So is this valid or no?

[esilvia]

To be clear, in the examples I've seen the LAS header size is still the standard value as required... it's just that there are undocumented bytes when the Offset to Point Data is greater than you'd expect from adding up the header size plus all of the VLRs.

[rapidlasso]

Yes This is valid. @lgraham-geocue has done that for years as far as I know. Always allocate 1024 or 2048 bytes fot the LAS header (even if no of few VLRs) so you can rewrite existing VLRs and/or add missing VLRs in place without a complete rewrite of the LAS or LAZ file..

[dpev]

This is a good idea, but it would be better for the committee to define a standard 'padding' VLR for that purpose.

On Fri, 24 Apr 2020, 11:17 am Martin Isenburg, notifications@github.com wrote:

Yes This is valid. @lgraham-geocue https://github.com/lgraham-geocue has done that for years as far as I know. Always allocatio 1024 or 2048 bytes fot the header so you can rewrite existing VLRs and/or add missing VLRs in place without a complete rewrite.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ASPRSorg/LAS/issues/91#issuecomment-618749474, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3GI4YKBFG2VAOM4QQLOHTRODSCJANCNFSM4MPR5OPA .

[abellgithub]

If you feel the need to say that point data can start at any position after the VLRs, so be it, but the train has already left the station, so you're just clarifying what's already done in practice, and I think supported by all readers.

[rapidlasso]

You go and tell @lgraham-geocue that all the LAS files his software has exported over the past 10 years are no longer specification-conform. (-; I had one laser war with Lewis. I do not want another one. My next laser war will be a cause more worthy then a small LiDAR point cloud format detail. That was just for practice. But I have not yet decided. Either the corrupt military-industrial complex, the abusive for-profit jail system, the destructive monoculture farming, or all three. (-;

[manfred-brands]

The Offset to Point data field allows skipping VLRs if one is only interested in core information. If we only would accept directly joining points that would make that field void. So yes, I also think it is valid.

[dpev]

I'm not disputing the validity. Currently, geocue uses the feature quite nicely to add/remove vlrs without a rewrite. Several other softwares could do the same, or maybe they put something else there, but they can't interoperate because they don't know what the data in that gap is. A standard vlr for this purpose means more interoperability, and coupled with a recommended pad size las files produced with the vlr can be modified by all software.

On Fri, 24 Apr 2020, 11:39 am manfred-brands, notifications@github.com wrote:

The Offset to Point data field allows skipping VLRs if one is only interested in core information. If we only would accept directly joining points that would make that field void. So yes, I also think it is valid.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ASPRSorg/LAS/issues/91#issuecomment-618754534, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3GI44C2X6QSZQYVLWC5XTRODUVNANCNFSM4MPR5OPA .

[esilvia]

I'm not disputing the validity. Currently, geocue uses the feature quite nicely to add/remove vlrs without a rewrite. Several other softwares could do the same, or maybe they put something else there, but they can't interoperate because they don't know what the data in that gap is. A standard vlr for this purpose means more interoperability, and coupled with a recommended pad size las files produced with the vlr can be modified by all software.

LAS 1.4 added the Superseded VLR (section 4.4 in R15), which is meant to allow the "deletion" of a VLR in-place without rewriting the entire file. I suppose it could also be used as a padding VLR if one wanted to create room to "insert" a VLR after the fact.

Nevertheless, I'm inclined to instead endorse the current practice by adding this "padding" between the VLRs and point data in Table 1 of section 2 and modifying the description of Offset to Point Data to account for the potential of this "junk" padding. Or would that be too confusing and I should just leave well enough alone?