How to increase the accuracy of derived height above ground

[Jung-kuan Liu]

Hi everyone,

I used lasheight.exe to derive height above ground followed the below command line, which would derived cm-level accuracy of derived height. Does anyone knew how to get mm-level or higher accuracy of it? Thank you very much!

I did apologize if this issue has been discussed.

"lasheight -i site1_g.las -o site1_h.las -store_as_extra_bytes"

--

Ernie

[Martin Isenburg]

Hello Jung-Kuan,

this is an interesting question. Can you send us a lasinfo report of 'site1_g.las' ... ? Please run the following command and attach the resulting text file to your answer:

lasinfo -i site1_g.las -odix _info -otxt

There is an unfinished discussion thread that we may need to revive. Karl Heidemann of the USGS raised some interesting points here. Before the "height above ground" stored as "extra bytes" becomes more or less a standard we should think about how much flexibility we need to provide for the range and the resolution of the height values.

Maybe read up on this discussion here and then try to convince us why we may need to support mm of higher precision and maybe include your suggestion for how to implement this:

http://groups.google.com/d/topic/lastools/3nrYXs4KfzQ/discussion

I'd certainly be interested in revisiting and solving this issue in the coming weeks.

Regards,

Martin

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

[Michez Adrien]

Hi,

I'm using lasgrid to rasterized canopy height model, in Belgian Lambert 72 - EPSG 31370

lasgrid runs normally and results are visually looking fine but I got this message :

" GeogGeodeticDatumGeoKey: look-up for ellipsoid with id 14 not implemented "

Could someone give me more information ? Is this problematic ?

Regards,

Adrien

[Jung-kuan Liu]

Hi Martin,

Attached please find the lasinfo report for this las file. It had been classified by using Lasground. The original file was converted from Polyworks file (.ply) in CloudCompare, which was matched point clouds from PhotoScan (a Photogrammetry Software). The source images was taken by a regular camera mounted on a UAS with ~1 cm ground resolution. That is why we need have mm (or higher) horizontal accuracy to detect features we are looking for and apply these features to point cloud classification process. We really appreciated your efforts on Lastools and hoped you can sole this issue soon. 

Best Regards!

--

Ernie

[Martin Isenburg]

Hello,

these are some crazy scaling values (0.1 micrometersresolution in x/y and ) in the lasinfo report of your LAS/LAZ file:

  scale factor x y z:         0.000000105941814 0.000000105163902 0.000000003700317

This stores each number with about 0.1 micrometers resolution in the x/y plane and with about 4 nanometer resolution in z. You need that much? (-; You can fix the scaling to something more reasonable with 

las2las -i site1.laz -rescale 0.001 0.001 0.001 -o site1_mm.laz

I assume you have processed those LAS/LAZ files with an older version of  Cloud Compare? I suggest you update to the latest version that now has a feature to preserve the original scaling of the points as discussed earlier:

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

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

For the latest version of LAStools (150516) I have simply added a new option '-store_precise_as_extra_bytes' for creating mm height above ground extra bytes. This is probably not the ultimate way of doing it but I think we are closing in on a solution. Here how to use it:

============================================================
============================================================

============================================================

The original way was storing heights very compact (using signed 2 byte short integers) with centimeter resolution: 

lasheight -i ..\data\fusa.laz ^

               -store_as_extra_bytes ^

               -o fusa_h_cm.laz

lasinfo -i fusa_h_cm.laz

[...]

  generating software:        'lasheight (150516) commercial'

[...]

  number var. length records: 2

  point data format:          1

  point data record length:   30

[...]

variable length header record 2 of 2:

  reserved             43707

  user ID              'LASF_Spec'

  record ID            4

  length after header  192

  description          'by LAStools of rapidlasso GmbH'

    Extra Byte Descriptions

      data type: 4 (short), name "height above ground", description: "vertical point to TIN distance", scale: 0.01, offset: 250

LASzip compression (version 2.3r0 c2 50000): POINT10 2 GPSTIME11 2 BYTE 2

[...]

las2txt -i fusa_h_cm.laz ^

           -parse xyz0 ^

           -stdout | more

277999.97 6122342.20 64.35 14.46

277999.97 6122342.53 64.30 14.41

277999.52 6122339.74 63.09 13.16

277999.55 6122340.05 62.88 12.94

277999.53 6122340.41 63.00 13.06

[...]

============================================================
============================================================

============================================================

The new alternate way is storing heights less compact (using signed 4 byte integers) with mm resolution:

lasheight -i ..\data\fusa.laz ^

               -store_precise_as_extra_bytes ^

               -o fusa_h_mm.laz

lasinfo -i fusa_h_mm.laz

[...]

  generating software:        'lasheight (150516) commercial'

[...]

  number var. length records: 2

  point data format:          1

  point data record length:   32

[...]

variable length header record 2 of 2:

  reserved             43707

  user ID              'LASF_Spec'

  record ID            4

  length after header  192

  description          'by LAStools of rapidlasso GmbH'

    Extra Byte Descriptions

      data type: 6 (long), name "height above ground", description: "vertical point to TIN distance", scale: 0.001, offset: 0 (not set)

LASzip compression (version 2.3r0 c2 50000): POINT10 2 GPSTIME11 2 BYTE 2

[...]

las2txt -i fusa_h_mm.laz ^

           -parse xyz0 ^

           -stdout | more

277999.97 6122342.20 64.35 14.457

277999.97 6122342.53 64.30 14.406

277999.52 6122339.74 63.09 13.160

277999.55 6122340.05 62.88 12.945

277999.53 6122340.41 63.00 13.056

Obviously the LAZ file with mm heights above ground "extra bytes" is less compressible as the LAZ file with cm heights.

dir fusa_h*

1,244,418 fusa_h_cm.laz

1,306,403 fusa_h_mm.laz

Regards,

Martin @rapidlasso

--

http://rapidlasso.com - fast tools for heights in your LiDARs

[Martin Isenburg]

Hello,

sorry for the late response but I was travelling a lot. This is not a big problem (besides a missing GeoTIFF tag for TIF exports). However, if you request color-picture output (e.g. '-false' or '-gray') in PNG or JPG formats then you cannot expect the corresponding KML file to put the image on exactly the right place in Google Earth as the underlying ellipsoid is different from WGS84. But I have added the missing switch to set the proper GeoTIFF tag in any generated geo-referenced TIFF content and this will be in the next release (see geoprojectionconverter.cpp) so the tag will be populated and the WARNING will disappear.

Regards,

Martin @rapidlasso

--