normalizing LiDAR point cloud with lasheight and -replace z (LAStools)

ab.mor...@gmail.com

unread,

Jul 24, 2016, 7:26:03 AM7/24/16

to LAStools - efficient tools for LiDAR processing

I have a problem with lasheight.

when I use it, (with -replace z to normalize the point cloud) the height of points are changed (distroyed heights: with/without drop below height) as shown in the above image (top: lasheight result without -replace z, and bottom: lasheight result with -replace z).

without -replace z every thing is ok, but the normalized point cloud isn't obtained.

I don't want these height changes.

I use lastools in QGIS 2.16.0 Nødebo.

Number of points ~ 10,000,000.

lasinfo result:

reporting all LAS header entries:

file signature: 'LASF'

file source ID: 0

global_encoding: 0

project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000

version major.minor: 1.2

system identifier: 'libLAS'

generating software: 'BCAL LidarTools, IDL 8.3'

file creation day/year: 205/2016

header size: 227

offset to point data: 399

number var. length records: 2

point data format: 3

point data record length: 34

number of point records: 10087141

number of points by return: 10087141 0 0 0 0

scale factor x y z: 0.000000335839844 0.000000499992188 0.000000037939995

offset x y z: 31515000 5686500 42.900001525878906

min x y z: 31515000 5686500 42.900001525878906

max x y z: 31515335.83984375 5686999.9921875 80.839996337890625

variable length header record 1 of 2:

reserved 0

user ID 'LASF_Projection'

record ID 34735

length after header 56

description 'GeoKeyDirectoryTag'

GeoKeyDirectoryTag version 1.1.0 number of keys 6

key 33922 tiff_tag_location 34736 count 1 value_offset 0 - key ID 33922 not implemented

key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected

key 1025 tiff_tag_location 0 count 1 value_offset 1 - GTRasterTypeGeoKey: RasterPixelIsArea

key 2052 tiff_tag_location 0 count 1 value_offset 9001 - GeogLinearUnitsGeoKey: Linear_Meter

key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree

key 3072 tiff_tag_location 0 count 1 value_offset 32631 - ProjectedCSTypeGeoKey: WGS 84 / UTM 31N

variable length header record 2 of 2:

reserved 0

user ID 'LASF_Projection'

record ID 34736

length after header 8

description 'GeoKeyDoubleParamsTag'

GeoDoubleParamsTag (number of doubles 1)

0

reporting minimum and maximum for all LAS point record entries ...

X 0 1000000000

Y 0 1000000000

Z 0 1000000000

intensity 0 0

return_number 0 0

number_of_returns 0 0

edge_of_flight_line 0 0

scan_direction_flag 0 0

classification 0 0

scan_angle_rank 0 0

user_data 0 0

point_source_ID 0 0

gps_time 0.000000 0.000000

Color R 0 0

G 0 0

B 0 0

number of first returns: 10087141

number of intermediate returns: 0

number of last returns: 10087141

number of single returns: 10087141

WARNING: for return 1 real number of points by return (0) is different from header entry (10087141).

WARNING: there are 10087141 points with return number 0

WARNING: there are 10087141 points with a number of returns of given pulse of 0

histogram of classification of points:

10087141 never classified (0)

Please help me.

Thank you.

Martin Isenburg

unread,

Jul 25, 2016, 5:11:49 AM7/25/16

to LAStools - efficient command line tools for LIDAR processing

Hello Ab,

Before you can use lasheight you will need to classify the ground points. The lasinfo report does not show any points classified as ground. However, without ground points there should not be any output. So I assume you did run lasground before running lasheight. I seem to see *extreme* edge effects in your output (lower picture). To analize this further you would need to send me the ground-classified LAZ file that you used as input to lasheight. I think a very poor ground classification (due to the small x/y extend of this data set) is the culprit.

Maybe try the following sequence of LAStools commands:

las2las -i input.las -rescale 0.01 0.01 0.01 -auto_reoffset -o fixed.laz

lasground -i fixed.laz -step 2 -o ground.laz

lasheight -i ground.laz -replace_z -o normalized.laz

But the lasinfo report also exhibits a number of little nastinesses in your LAS file that I have marked in red below. They are

(a) using of point type 3 instead of 0 for points without colors or GPS times wastes 14 bytes containing just zeros per point (34 bytes instead of 20)

(b) horrible scale factors store each coordinate with sub-micrometer resolution (a human hair is 40 - 120 micrometer)
(c) poor choice in offset for z (a reasonable choicewould be 0)

(d) return numbers and numbers of return are all zero (but maybe that is in fact "good practice" if this was multi-return LiDAR and the information about return counts has been lost ... good discussion for "the LAS room" or the LWG committee)

On Sun, Jul 24, 2016 at 7:10 AM, <ab.mor...@gmail.com> wrote:
>
> I have a problem with lasheight.
> when I use it, (with -replace z to normalize the point cloud) the height of points are changed (distroyed heights: with/without drop below height) as shown in the above image (top: lasheight result without -replace z, and bottom: lasheight result with -replace z).
> without -replace z every thing is ok, but the normalized point cloud isn't obtained.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

> I don't want these height changes.
> I use lastools in QGIS 2.16.0 Nødebo.
> Number of points ~ 10,000,000.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

ab.mor...@gmail.com

unread,

Jul 25, 2016, 12:00:11 PM7/25/16

to LAStools - efficient tools for LiDAR processing

Hello,

Thanks for your attention.

It seems "las2las -i input.las -rescale 0.01 0.01 0.01 -auto_reoffset -o fixed.laz" line -that I didn't use it- solve my problem.