las header scale and offset

[David Pont]

I am seeing some strange values reported by lasinfo for some laz files that look a bit suspicious. The file was geo-referenced into NZMG for us, a local lat long type system, but be aware when it comes to geographic coordinate systems I'm just a klutz so go easy on me. Can someone confirm that the scale and offset values in a las header are intended to be applied to each point stored in the file? And this allows points to be stored in a convenient numerical representation (pre- scale and offset) ?

Here is a section of the lasinfo output for one of the laz files I am looking at:

  scale factor x y z:         0.0001 0.0001 0.0001
  offset x y z:               1920046.3021993292 5742518.4886667607 257.63722801525546
  min x y z:                  1920026.7375 1920026.7375 1920026.7375
  max x y z:                  1920083.3896 5742489.3566 1920083.3896
LASzip compression (version 2.2r0 c2 50000): POINT10 2
reporting minimum and maximum for all LAS point record entries ...
  X    -195647     370874
  Y    -429097      91072
  Z      -9710     309879

- The values below "reporting minimum and maximum..." just look plain wrong. I would expect these to be ranges of point values, ie not scaled and offset. Perhaps the large coordinate values have overflowed?

- Next, min x y z seem to repeat the min x value. It does look like a correct min x value. 

- Finally I presume "min x y z" and "max x y z" report the scaled and offset point values?

If I can get clear about these questions I might be able to figure out if the file is good or bad, or am I looking at it wrong?

  regards, Dave

[David Herries]

Dave

Where did you get nzmg georeferenced las files from? Are you sure they were not nztm and someone has converted them incorrectly, as nzmg has not been widely used for over a decade!

Thanks
David Herries

Sent from my Windows Phone

---

From: David Pont
Sent: ‎24/‎09/‎2014 5:36 p.m.
To: last...@googlegroups.com
Subject: [LAStools] las header scale and offset

--
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

[David Pont]

Hi Dave,

  yes a typo on my part, realised as soon as I posted, it is of course NZTM.

Re reported las header values. An old version of lasinfo on my laptop was responsible for the repeated x_min values.

Apart from that all is in order, I just did not understand the values being reported. The min and max are the unscaled unshifted values held at the point level - so yes they look just as they should. And the x_min etc are scaled and shifted values, in NZTM (not NZMG ;-).

  cheers, Dave

[David Herries]

Thanks Dave

 

Our team likely geo-referenced those LAS files if working on a recent NZ dataset, if so, any questions let me know.

 

Cheers

 

 

David Herries     Interpine Group Ltd

Mobile:      021 43 5623   DDI:  +64 7 350 3209 or Australia 0280113645 ext 721

[Martin Isenburg]

Hello,

after Dave sent me the file and I had a closer look it turns out that those repeated x_min, x_min, x_min values were a bug in a older version of LAS/LAZ exporting from Trimble Real Works (TRW). I was since contacted and Trimble reassured me that the bug has long been fixed after this had been discovered on this mailing list back in June:

http://groups.google.com/d/topic/lastools/g-hMi__GLTk/discussion

In the end, Dave sent me his LAZ file and I ran it through lasinfo and lasvalidate. The respective reports are attached.

D:\lastools\bin>lasinfo -i 2014-07-31_13-02-37_GR.laz -odix _info -otxt

WARNING: end-of-file after 117000 of 10283139 points

D:\lastools\bin>lasvalidate -i 2014-07-31_13-02-37_GR.laz -oxml

This is version 140923 of the LAS validator. Please contact

me at 'martin....@rapidlasso.com' if you disagree with

validation reports, want additional checks, or find bugs as

the software is still under development. Your feedback will

help to finish it sooner.

WARNING: end-of-file after 117000 of 10283139 points

needed 0.14 sec for '2014-07-31_13-02-37_GR.laz' fail

What Dave wanted to do is translate the points in this file to the origin. Because these points are in the NZTM projection they have huge coordinates. The x coordinates (= Eastings) are around 1,900,000 meters and the y coordinates (= Northings) are around 5,700,000 meters. When we want to translate by such huge distances we can *not* simply use '-translate_xyz' because this will break the fixed-point notation (i.e. offset and scaled integers) that the LAS/LAZ format uses to store large numbers. We also must "move the offset" to somewhere near to where the points will be located after the translation.

Instead of simply doing

>> las2las -i 2014-07-31_13-02-37_GR.laz ^

                  -translate_xyz -1920059.926 -5742498.991 -271.776 ^

                  -repair_zero_returns ^

                  -odix _bad -olaz

we also must move the offset to roughly where the points will be located after such a huge translation (here we use the origin) with '-reoffset' as shown below

>> las2las -i 2014-07-31_13-02-37_GR.laz ^

                  -translate_xyz -1920059.926 -5742498.991 -271.776 ^

                  -reoffset 0 0 0 ^

                  -repair_zero_returns ^

                  -odix _good -olaz

This was also explained (in parts) in these earlier threads:

http://groups.google.com/d/topic/lastools/HDwvY5Y_S0Q/discussion

http://groups.google.com/d/topic/lastools/7FEgu6o2nZw/discussion

http://groups.google.com/d/topic/lastools/u4fB1czYlSU/discussion

The result is a beautifully translated and reoffset LAZ file for which the lasinfo report is attached again.

D:\lastools\bin>lasinfo -i 2014-07-31_13-02-37_GR_good.laz -odix _info -otxt

Regards,

 

Martin @rapidlasso

 

--

http://rapidlasso.com - fast tools to defluff your LiDARs

[Jonah Sullivan]

I had a similar problem when using LAStools for an unintended purpose: multibeam sonar.

 

The search area for the MH370 spans UTM zones 46-50 so I tried converting all of the XYZ sonar returns into LAS format, then projecting to World Mercator (EPSG 3395).

 

It didn't work, but now I think I know why.

[Martin Isenburg]

Hello Jonah,

What is the presumed accuracy for the multibeam sonar points? You are able to store a much larger spatial extend in a LAS/LAZ file if you lower the resolution with higher scale factors. They may also compress much better, which could be important if LAZ was used to send the aquired sonar points (via low bandwidth transmission links) from the ships surveying the ocean to the data processing centers on land ... (-;

However, even with the default centimeter resolution (scale factors of 0.01) and a properly chosen offset (in the center somewhere) you can cover a square area of 4 billion centimeters in both Easting and Northing direction. That equals an area of 40 million by 40 million meters or 40,000 by 40,000 kilometers. A quick look at my frequent flyer account accruals shows that all my transcontinental Star Alliance flight segments fall well below these distances ... (-:

However, you mention the World Mercator (EPSG 3395) projection [1] so you operate in decimal degrees. Here we need scale factors (typically 1e-7 is used) that assure that coordinate increment in scale factors in degrees (!) are - when translated to (centi- or deci-)meters (!) - sufficiently small to store the expected precision in the data. The translation from increments in decimal degrees to increments in (centi- or deci-)meters varies *greatly* depending on where you are. To be safe you should look at all possible smallest and largest increments in (centi- or deci-)meters that occur for all possible decimal degree increments in longitude and latitude value-pairs within the MH370 search area and then pick scale factors that assure the minimal increments in (centi- or deci-) meters are met everywhere.

Cheers,

Martin

PS: A whole different discusssion is whether the World Mercator (EPSG 3395) projection [1] is a suited projection for such a large-scale area.

[1] http://spatialreference.org/ref/epsg/wgs-84-world-mercator/

[David Pont]

Hi Martin,

  a quick status report: using the -reoffset flag was the critical bit I had missed. Many thanks for your help, I have now processed 2 input files successfully and I've learned a bit more about coordinates and offsets.

  regards, Dave

[Jonah Sullivan]

I don't know what the vertical accuracy is, I assume it is several metres so a z-scale factor of 1 would be sufficient. I reckon horizontal scale factors of 5 or even 10 wouldn't degrade the data, especially derived raster grids.

 

Footprint or cell size (based on beam divergence) calculation follows this formula (written in python):

 

footprint = math.tan(math.radians(.5)) * abs(depth) * 2

 

where .5 is the beam spread in degrees and depth is in metres, the final multiplication by 2 is to account for two-way travel.

 

In this area typical footprint size is from 40m to 100m.

 

I attached a script that I use with LASinfo.exe to find the maximum depth (shallowest reading since depth is a negative number) within a folder containing LAS files and return the smallest footprint or cellsize (rounded to a multiple of 5).

 

Also, World Mercator is a projected coordinate system with the linear unit in metres, so the values may get very large (min/max= -20037508.3428, 20037508.3428), but an offset somewhere near the AOI should do the trick.