Re: laszip support for "native" LAS 1.4?

18 views
Skip to first unread message

Martin Isenburg

unread,
Aug 29, 2017, 1:45:11 PM8/29/17
to Jordan, Tom, last...@googlegroups.com, The LAS room - a friendly place to discuss specifications of the LAS format, Ingersoll, Mark
Hello Tom.

what you describe as "problems" is exactly how the "LAS 1.4 compatibility mode" of LASzip was working. New point types in LAS 1.4 format were "recoded" into a LAS 1.2 representation with the best corresponding older point type. This allowed (a) immediate compression of new LAS 1.4 content with the proven LASzip compressor and (b) any software to read the content - even older legacy software that did not yet support the new LAS 1.4 point types.

Since then we've also released the "native LAS 1.4 extension" of LASzip. If you download the latest version of LAStools (170828) you will find that laszip.exe compresses your LAS 1.4 files with this new "native LAS 1.4 extension" that was sponsored by NOAA thanks to great efforts by Kirk Waters to make funding available (unless you specify '-no_native').

Note that how if you compress your LAS 1.4 files with the latest laszip.exe coder this line in your lasinfo report 

LASzip compression (version 3.0r3 c2 50000): POINT10 2 GPSTIME11 2 BYTE 2

will change to

LASzip compression (version 3.1r0 c3 50000): POINT14 3

The problem is that most software out there will take a while until they also support this newer version of LASzip so many of your users will have to decompress the LAZ files anyways until their software is updated with the newest DLL.

Note that your scale and offset values are not the most desirable ones. A coordinate resolution of 0.01 millimeter is more than excessive for airborne LiDAR. And the offset values are not quantized to the coordinate resolution. I suggest adding these two options here to your command line

laszip -i *.las -rescale 0.01 0.01 0.01 -auto_reoffset 

and your scale factors and offsets will go from

  scale factor x y z:         0.00001 0.00001 0.00001
  offset x y z:               1620499.9950000001 6628499.9950000001 460.625

to something more suitable such as

  scale factor x y z:         0.01 0.01 0.01
  offset x y z:               1620000.00 6620000.00 0.00

and your files will compress significantly better as a coordinate resolution that is stored in increments of 0.01 millimeter is really just a bunch of random numbers from whatever was left in the low order mantissa bits of the arithmetic processing unit after all the floating-point math was done. And that is impossible to compress (because it is basically meaningless white noise).

Regards,

Martin @rapidlasso

On Tue, Aug 29, 2017 at 3:22 PM, Jordan, Tom <tjor...@harris.com> wrote:

Martin,

Based on your announcement “Rapidlasso Announces LASzip “Compatibility Mode” For LAS 1.4”, it appears the laszip has supported a 1.4 to 1.2 “compatibility mode” for nearly three years. However, I don’t see an option for native 1.4 support in laszip.README

 

The problems we are having with this are:

·         We extract metadata reported by lasinfo to enter each LiDAR tile into a catalog database.

o   The lasinfo report on a LAZ file created by laszip with a LAS1.4 input file has the following issues for us:

§  Reports a “version major.minor:   1.2”,  instead of 1.4, and

§  the “*_extended” fields are missing, and

§  the histogram of classified points is missing

·         Our customer contract requires us to deliver classified tiles in LAS 1.4 format, with a web delivery option. These files use the extended 256 classifications of point data record format 6.

o   Naturally, a compressed format is preferable for web delivery. LAZ would be ideal, but the missing items from lasinfo (listed above) cause contractual issues for us. It would appear that we delivered the tiles in LAS 1.2 format and without classifications.

o   Customer software designed to process the extended classifications in LAS 1.4 would not work. Is there a workaround for this?

o   Our customers would therefore have to unzip the LAZ file to process the tile. This defeats the purpose of zipping as LAZ.

 

Is there a version of laszip that supports LAS 1.4 natively? If not, it appears that the only alternative is to use a neutral format such as zip, or gzip for our LAS 1.4 files. This would force the customer to unzip them prior to processing these files, thus, prevent support calls that would otherwise result from them trying to process these LAS 1.4 files in “compatibility mode” LAZ format.

 

I created the LAZ file from a LAS 1.4 file (16206628.las) as follows:

laszip -i 16206628.las -o 16206628.laz

 

Attached are the lasinfo outputs of both files.

 

Tom Jordan, MSCS
Software Engineer

Geospatial data processing and visualization

Space and intelligence systems / HARRIS CORPORATION

Melbourne, FL / HTC-C3014

 


Martin Isenburg

unread,
Aug 29, 2017, 3:56:00 PM8/29/17
to Jordan, Tom, The LAS room - a friendly place to discuss specifications of the LAS format, LAStools - efficient command line tools for LIDAR processing, Ingersoll, Mark
Hello,

You are using a version that was released before 170828 and that uses the compatibility mode as the default way to compress new LAS 1.4 point types. In those older versions you still need to add the keyword '-native' to the command line. Run this to find out your version:

laszip -version

See the latest changes here. 


Regards,

Martin @rapidlasso


On Aug 29, 2017 1:07 PM, "Jordan, Tom" <tjor...@harris.com> wrote:

Martin,

Thank you for your rescale recommendation of:

laszip -i 16206628.las -rescale 0.01 0.01 0.01 -auto_reoffset 

 

That reduced the LAZ file size to just 64% of LAZ made without  the rescaling option. And yes, 1 cm (0.4 inch) precision should be more than sufficient.  Good catch!

 

However, the “LASzip compression” is not what you expected. Lasinfo reports this:

LASzip compression (version 3.0r3 c2 50000): POINT10 2 GPSTIME11 2 BYTE 2

 

> Martin Isenburg wrote:

> Note that how if you compress your LAS 1.4 files with the latest laszip.exe

> coder this line in your lasinfo report

>     LASzip compression (version 3.0r3 c2 50000): POINT10 2 GPSTIME11 2 BYTE 2

>

> will change to

>     LASzip compression (version 3.1r0 c3 50000): POINT14 3

 

I believe I am using the latest version of LAStools since the first line in the CHANGES.txt file is:

“26 July 2017 -- las2tin: now supports DXF format as output option for the generated Delaunay TIN”

(I see that ‘LASzip DLL: “native LAS 1.4 extension”‘ was introduced 25 April 2017.)

 

Also I’m still seeing these issues with the lasinfo output on this LAZ file generated with laszip:

1.       “version major.minor:   1.2”,  instead of 1.4

2.       the “*_extended” fields are missing

a.       lasinfo correctly reports this for the original LAS1.4 file:

  start of waveform data packet record: 0

  start of first extended variable length record: 0

  number of extended_variable length records: 0

  extended number of point records: 78585827

  extended number of points by return: 78585827 0 0 0 0 0 0 0 0 0 0 0 0 0 0

                     ...

  extended_return_number          1      1

  extended_number_of_returns      1      1

  extended_classification         1     81

  extended_scan_angle          2500   2500

  extended_scanner_channel        0      0

b.       Those sections are missing from the lasinfo of the LAZ file.

 

3.       the histogram of classified points is missing

a.       lasinfo correctly reports this for the original LAS1.4 file:

  histogram of extended classification of points:

             112  extended classification (70)

             733  extended classification (72)

             757  extended classification (80)

              32  extended classification (81)

b.       That section is missing from the lasinfo of the LAZ file.

 

Both lasinfo outputs are attached. Am I doing something wrong?

 

Thanks

Reply all
Reply to author
Forward
0 new messages