Using LASZIP and requirement to set “Reserved” value to Zero(0)

[milenajaniec]

What is the issue about?

No response

Issue description

Hi @esilvia Someone has emailed me asking why when they use LASZIP it would create a new VLR record and set the “Reserved” value to 43707 instead of Zero(0) (what we specify in the LAS standard). Would you happened to know: Why (and when) did we start require for the reserved value to be set to Zero(0)? Why 43707 value gets populated?

[abellgithub]

You should contact the provider of laszip.

[Jean-Romain]

The LASlib API from LAStools is writting the value 43707 in the reserved field

https://github.com/LAStools/LAStools/blob/master/LASlib/src/laswriter_las.cpp#LL581C20-L581C26

    U16 reserved = 0xAABB;
    if (!stream->put16bitsLE((U8*)&(reserved)))

To my knowledge there is nothing where it is documented and it does not seem to be used at read time

https://github.com/LAStools/LAStools/blob/master/LASlib/src/lasreader_las.cpp#L481

Anyway a LAZ file is not a LAS file and if the reserved field must be zeroed in a LAS file the standard (there is no standard) says nothing for a LAZ file. LAZ files are not forbidden to have non zero reserved field. If you decompress your LAS file the VLR will be removed leading to a LAS specification compliant file.

To me it is a residual of an old change and a value of 0 would work as well.

//     7 January 2017 -- set reserved VLR field from 0xAABB to 0x0 in DLL

https://github.com/search?q=repo%3ALAStools%2FLAStools%200xAABB&type=code

Yet @abellgithub is correct it is a question for LASzip but I doubt anyone will be able to answer this super specific question now.

[milenajaniec]

@Jean-Romain - thank you! Especially pointing out that technically LAZ files are not forbidden to have non zero reserved field. Evon shared ASPRS LAS 1.0 Format Standard May 9 2003 (PDF) as an old change. It seems that some folks might be replacing 43707 with zero (0) value afterwards? Seems that 43707 in compressed file would not cause any issue or be contrary to our specification.

[Jean-Romain]

@milenajaniec Nice you found it! It comes from the LAS 1.0 specification. You can see in the source code that all the hits for 0xAABB are also associated with 0 for backward compatibility e.g.

if ((laszip_dll->header.vlrs[i].reserved != 0xAABB) && (laszip_dll->header.vlrs[i].reserved != 0x0))
{
   sprintf(laszip_dll->warning,"wrong header.vlrs[%d].reserved: %d != 0xAABB and %d != 0x0", i, laszip_dll->header.vlrs[i].reserved, laszip_dll->header.vlrs[i].reserved);
}

To me it is a residual of LAS 1.0 and it could be 0. I'm assuming that Martin missed to change one specific line of code in 2017 because other occurrences were either changed to 0, commented or associated with an second statement to check if the value is either 0xAABB or 0

[esilvia]

Tagging Jochen at @rapidlasso. I don't believe this change would break anything, except perhaps a very strict and ancient LAS 1.0 parser. I'm not sure how rigorously LAStools is trying to maintain backward compatibility, or whether there's truly a LAS 1.0 write mode.

[rapidlasso]

Your right @esilvia, this would not break anything. I did not comment so far because @Jean-Romain said all to say - thanks! :)

[esilvia]

Discussed at today's LWG call. Sounds like @rapidlasso will be able to fix this bug without too much trouble.