Number of Points

[Mustafa Agah Öztürk]

Hello,

We've some LAZ files which have both 'number of point records' and 'legacy number of point records' in its header, and these values are different from each other. We wonder how would we know which one is correct? Which one should be used as number of points in such a this case?

Thanks in advance.

Regards,

Mustafa

[Martin Isenburg]

Hello,

Could you send one or more lasinfo reports (*) as well as the exact sizes (in bytes) of the corresponding files?

(*) http://rapidlasso.com/lasinfo

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

[Mustafa Agah Öztürk]

Hello,

It's 10.594.315 bytes (10,6 MB on disk).

Output of the lasinfo : 

lasinfo (180209) report for file1.laz

reporting all LAS header entries:

  file signature:             'LASF'

  file source ID:             32084

  global_encoding:            1

  project ID GUID data 1-4:   00000000-0000-0000-4844-564D0049492D

  version major.minor:        1.4

  system identifier:          'Riegl LMS-Q680i'

  generating software:        'RiProcess-TerraScan-LASToolbox'

  file creation day/year:     54/2014

  header size:                375

  offset to point data:       375

  number var. length records: 0

  point data format:          3

  point data record length:   34

  number of point records:    2025158

  number of points by return: 1610860 273370 102292 31727 6909

  scale factor x y z:         0.01 0.01 0.01

  offset x y z:               0 0 0

  min x y z:                  173000.00 172500.00 22.35

  max x y z:                  173499.99 172999.99 61.75

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

  extended number of points by return: 14979626 2100649 772554 242717 52509 0 0 0 0 0 0 0 0 0 0

LASzip compression (version 2.2r0 c2 50000): POINT10 2 GPSTIME11 2 RGB12 2

LAStiling (idx 24, lvl 3, sub 0, bbox 171000 171500 175000 175500)

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

  X            17300000   17349999

  Y            17250000   17299999

  Z                2235       6175

  intensity           1      65529

  return_number       1          5

  number_of_returns   1          5

  edge_of_flight_line 0          1

  scan_direction_flag 0          0

  classification      1          9

  scan_angle_rank   -16         31

  user_data           0          0

  point_source_ID 32084      32084

  gps_time 77191166.180701 77191175.957997

  Color R 256 65024

        G 256 65024

        B 256 65024

number of first returns:        1610860

number of intermediate returns: 141291

number of last returns:         1608036

number of single returns:       1335029

WARNING: real number of point records (2025158) is different from extended header entry (18148055).

WARNING: real extended number of points by return [1] is 1610860 - different from header entry 14979626.

WARNING: real extended number of points by return [2] is 273370 - different from header entry 2100649.

WARNING: real extended number of points by return [3] is 102292 - different from header entry 772554.

WARNING: real extended number of points by return [4] is 31727 - different from header entry 242717.

WARNING: real extended number of points by return [5] is 6909 - different from header entry 52509.

overview over extended number of returns of given pulse: 1335029 343882 212285 99387 34575 0 0 0 0 0 0 0 0 0 0

histogram of classification of points:

         1063137  unclassified (1)

          960946  ground (2)

            1075  water (9)

6 Haziran 2018 Çarşamba 15:52:55 UTC+2 tarihinde Martin Isenburg yazdı:

[Martin Isenburg]

Hello,

10,594,315 bytes divided by 2,025,158 points (as reported by the "number of point records" field) would mean around 5.23 bytes per point instead of the uncompressed 34 bytes of point type 3.  That would mean a compression down to 15% of the original size and that sounds about right.

10,594,315 bytes divided by 18,148,055 points (as reported by the "extended number of point records" field) means around 0.58 bytes per point instead of the uncompressed 34 bytes of point type 3.  That would mean a compression down to 1.7% of the original size and while it would be fantastic compression for LASzip to achieve I'm afraid it's not what happened. The number 18,148,055 points as reported by the "extended number of point records" field is wrong.

What likely happened that the software did not update this number. Did this happen in LAStools? If yes, I'd like to know the processing steps that created this so I can fix it. If not you may want to talk to whomever created these files about the software that was used.

You can try to fix the counters by running

lasinfo -i file1.laz -repair_counters

Regards,

Martin