laszip point format in header

[Amoureus, Luc [FGBV]]

Hey Lastools

 

Recently we had to deliver a large dataset LAS data zipped to LAZ so we used laszip (recent release) to do this (makes sense, doesn’t it)

Before delivery we checked the complete LAZ dataset with lasinfo and could not find anomalies

Unfortunately the control party of the client reported us that the field ‘Point Data Record Format’  in the delivered LAZ files is wrong…

 

The LAS we created has Point Data Record Format = 1, I checked the header (with a hex viewer) and see indeed at position 104 (hex 68) the file contains a byte with value (hex) 01  

I checked the LAZ created by laszip the same way and noticed that at position 104 in the file the byte now has value (hex) 81

 

Now I might be wrong… but I thought that laszip would keep the header of the LAS unchanged, allowing Laszip (or other code based on the laszip library) to be able to get the necessary basic information from the header needed to unzip the file. It seems the control party is using the same assumption here and comes to the conclusion our LAZ is wrong (and we would need to adjust this for the final delivery).

 

I checked the LAS and LAZ again, tested the LAS->LAZ and LAZ->LAS and checked lasinfo based on the LAS and the LAZ but it seems standard behavior to change point data record format 1 in LAS to 81 in LAZ

 

Below a screen capture of a binary comparison (Beyond Compare) between the LAS and LAZ header, differences are marked red, at byte 104 (hex 68) I placed and extra marker to show the issue.

Notice there are a few more differences (offset to point data and number of variable length records)

 

Question: Is this a bug or is this expected behavior of laszip/LAZ format ?

            In the latter case, would you have some documentation we can send to the client to advise the control party to change their code

 

thanks

 

Luc

 

 

Kind regards,

Fugro Geospatial B.V.

 

ir. Luc Amoureus

R&D Manager

 

Telephone: +31 (0)70 31 70718 / Mobile: +31 (0)6 20 36 98 94 / Fax: +31 (0)70 31 70750

E-mail: l.amo...@fugro.com / Website: www.fugrogeospatial.com

Address: Dillenburgsingel 69, 2263 HW Leidschendam /

P.O. Box 3000, 2260 DA Leidschendam, The Netherlands

Trade Register Nr: 27152156 / VAT Nr: NL803757955B01

 

 

[Martin Isenburg]

Hello Luc,

that is exactly the expected behaviour. The LAZ file changes the Point Data Record Format by adding 128 (i.e. bon y turning the highest bit of the 8-bit Point Data Record Format field) in order to prevent folks from simply renaming *.laz files to *.las files (or vice versa) and then reading corrupt content. A valid LAZ file has the highest bit of the Point Data Record Format set and stores the point type in the lower 7 bits. A LAZ file also has one additional VLR, namely the one that specifies the LASzip compression parameters. These two changes together define a valid LAZ file. Both changes - the turned-on bit as well as the extra VLR get automatically undone when reading LAZ files through the decompression DLL (LASzip.dll) or when decompressing with laszip.exe ...

Both these changes are documented in the ASPRS paper (and also in the open source code)in "Section III. THE LASZIP COMPRESSOR" on page 3. The ASPRS paper can be downloaded via http://laszip.org or via the direct link here.:

http://lastools.org/download/laszip.pdf

Regards,

Martin @rapidlasso

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe

[Howard Butler]

On Jul 14, 2014, at 8:24 AM, Amoureus, Luc [FGBV] <L.Amo...@fugro.com> wrote:

> Now I might be wrong… but I thought that laszip would keep the header of the LAS unchanged, allowing Laszip (or other code based on the laszip library) to be able to get the necessary basic information from the header needed to unzip the file. It seems the control party is using the same assumption here and comes to the conclusion our LAZ is wrong (and we would need to adjust this for the final delivery).

The beauty of Martin's approach is that it allows software that can consume LAS headers to continue to do metadata-type activities with them. This includes VLRs and eVLRs. There's no accidental consumption of the point data though.

Another approach might have changed the magic characters to LAZF or something. It wouldn't have had the convenience that sliding over the record id does, however.

The control party is mistaken in this case.

These types of issues, along with the once that my company encountered while developing a JavaScript LASzip decompressor, illustrate the need for some sort of standardization/specification effort for LAZ. We need a technical document, deeper than Martin's overview-style paper, that goes into the nuts and bolts of how to write LAZ data. Is there an organization with enough stake in LAZ to see this need and is willing to support it?

Howard

[Luc Amoureus]

Thanks Martin

I already thought this would be expected behavior and it all makes sense... I will inform our counterparts to improve their software according to the provided documentation 

Luc