mfsch
commented
5 months ago After taking another look at the LAS spec, I saw that the header does include the header size separately from the point-data offset, which means it is possible for a v1.2 reader to correctly read a v1.4 file as long as it doesn’t use any new features.
I guess that means that the “correct” behavior for a reader is to attempt reading files with unsupported future version numbers and skip extra header data? As for #109, that would mean that writing v1.4 files with legacy support would generally be fine as older readers should still read them correctly? I guess writing v1.2 files is still safer though since some readers might bail when they see a version number they don’t know.
I still wonder if it would make sense to mention these things explicitly in the legacy compatibility section, i.e., that consumers should attempt to read any LAS version and skip unknown header bytes, though that may be obvious to others.
What is the issue about?
Inquiry about the specification
Issue description
I’m trying to understand what the considerations with regard to backwards compatibility of the v1.3 and v1.4 specifications were. Since they both introduced additional fields in the public header block, it is impossible to correctly read the VLRs of v1.3/v1.4 for a reader that is only aware of v1.2, no matter whether the v1.4 file is making use of any of the new features. Why then does the v1.4 format retain the “legacy” number of points, if it is anyway not possible to write a v1.4 file that can be parsed correctly by a v1.2 reader?
If the new header fields had instead been placed after the VLRs, just before the point-data offset, it would be possible to write v1.3 & v1.4 files that can be parsed correctly by a v1.2-aware reader, as long as none of the new features are used. But as the spec is defined now, we might as well think of v1.2, v1.3 and v1.4 as completely separate formats, no? Or is this meant to accommodate processing tools that do not need CRS/VLR data but only support v1.2?
If I am understanding this compatibility issue correctly, then the “legacy compatibility” section of the spec is a bit misleading to me. In particular, it mentions that a v1.4 writer should only write VRLs and no EVLRs if it wants to maintain backward compatibility, but how can an older reader read v1.4 VLRs if it is not aware of the new starting position of VLRs? Are these compatibility considerations just meant to make it easier to implement partial support for a newer format, e.g. explicit support for v1.4 files but not for EVLRs?
It looks like the discussion in #109 is somewhat related.