recovering flight line information with LAStools

[Martin Isenburg]

Hello,

Katri Tegel from Arbonaut recently asked: I'm facing the problem where
flightline-ID is missing from points; there are for example 4
flightlines but their ID is the same "1". I imported them in TerraScan
using "Line numbers: Use from file". Do you know is there any way to
deduce the ID later on, like using time information? The trajectories
are .sol files in degrees while las files are in projected coordinates
- i can export them as txt to ESRI software, convert them to points
and project them, but don't know a way to export them back to .trj.
Any help is most welcome. :)"

With LAStools it can be done as follows:

(1) check the distribution of gps time stamps and find a good interval
size (experimentally) with lasinfo:
>> lasinfo -i mixed.laz -histo gps_time 50
[...]
gps_time histogram with bin size 50
bin [483500,483550) has 388873
bin [483550,483600) has 827130
bin [485300,485350) has 1567042
bin [486100,486150) has 1006605
>> lasinfo -i mixed.laz -histo gps_time 1000
[...]
gps_time histogram with bin size 1000
bin [483000,484000) has 1216003
bin [485000,486000) has 1567042
bin [486000,487000) has 1006605
[...]

(2) split the LiDAR files based on the found gps time interval and
thereby put all points from one flight line into one file with
lassplit:
>> lassplit -i mixed.laz -by_gps_time_interval 1000 -o lines.laz
>> dir lines*.laz
4,528,891 lines.00484.laz
5,818,122 lines.00485.laz
3,867,728 lines.00486.laz

(3) put the resulting files back together into one tile while keep the
flight line information with lasmerge:
>> lasmerge -i lines*.laz -files_are_flightlines -o fixed.laz

Optionally - before merging the files - you could first sort each
flight line into gps time order with lassort:
>> lassort -i lines*.laz -gps_time -odix _sorted -olaz

Regards,

Martin @rapidlasso

--
http://rapidlasso.com - fast tools for lost LIDAR lines

[Ted Rakel]

Hello,

 

I have a terrascan .bin file and I'm trying to find out when the data was aquired.  There's nothing in the file name to indicate when it was aquired.  I tried what you describe here and the output is listed below.  Can you please tell me if it's possible to infer when this data was aquired from the output below.  I've tried putting the gps times into several on line gps to utc tmie converters but I must be doing something wrong.

Thanks

 

C:\Users\trakel\Documents\testing\PRJ>LAStools\bin\lasinfo.exe -i -v "C:\Users\trakel\Documents\testing\PRJ\Lidar data\PRJ bin files\115-1\PRJ_000001.bin" -histo gps_time 200
lasinfo for C:\Users\trakel\Documents\testing\PRJ\Lidar data\PRJ bin files\115-1\PRJ_000001.bin
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:          'LAStools (c) by rapidlasso GmbH'
  generating software:        'via LASreaderBIN (150526)'
  file creation day/year:     159/2015
  header size:                227
  offset to point data:       227
  number var. length records: 0
  point data format:          1
  point data record length:   28
  number of point records:    12610121
  number of points by return: 0 0 0 0 0
  scale factor x y z:         0.01 0.01 0.01
  offset x y z:               0 0 0
  min x y z:                  1898871.56 11409992.75 4230.46
  max x y z:                  2006906.69 11613749.47 5007.21
reporting minimum and maximum for all LAS point record entries ...
  X           189768484  200754977
  Y          1140970414 1161609855
  Z              414471     503900
  intensity           0        255
  return_number       1          2
  number_of_returns   1          3
  edge_of_flight_line 0          0
  scan_direction_flag 0          0
  classification      2         30
  scan_angle_rank     0          0
  user_data           0          0
  point_source_ID     0        166
  gps_time 0.000000 64873.441800
re-reporting LAS header entries populated during read pass:
  number of points by return 11468548 1141573 0 0 0
  min x y z                  1897684.84 11409704.14 4144.71
  max x y z                  2007549.77 11616098.55 5039.00
WARNING: 2339730 points outside of header bounding box
gps_time histogram with bin size 200
  bin [0,200) has 994867
  bin [60400,60600) has 123704
  bin [60600,60800) has 813451
  bin [60800,61000) has 599234
  bin [61000,61200) has 302832
  bin [61200,61400) has 986350
  bin [61400,61600) has 925122
  bin [61600,61800) has 291128
  bin [61800,62000) has 660610
  bin [62000,62200) has 526680
  bin [62200,62400) has 204935
  bin [62400,62600) has 570950
  bin [62600,62800) has 252725
  bin [62800,63000) has 303441
  bin [63000,63200) has 128825
  bin [63200,63400) has 339882
  bin [63400,63600) has 477537
  bin [63600,63800) has 323058
  bin [63800,64000) has 855313
  bin [64000,64200) has 802685
  bin [64200,64400) has 441864
  bin [64400,64600) has 749807
  bin [64600,64800) has 797464
  bin [64800,65000) has 137657
  average gps_time 57747.4
overview over number of returns of given pulse: 2988504 8762809 858808 0 0 0 0
histogram of classification of points:
          517065  ground (2)
              31  noise (7)
          842292  keypoint (8)
          152544  rail (10)
          123408  road surface (11)
        10007140  overlap (12)
           47367  wire guard (13)
             533  wire conductor (14)
          919741  Reserved for ASPRS Definition (30)
real max x larger than header max x by 0.000000
real min x smaller than header min x by 0.000000
real max y larger than header max y by 0.000000
real min y smaller than header min y by 0.000000
real max z larger than header max z by 0.000000
real min z smaller than header min z by 0.000000

[Martin Isenburg]

Hello Ted,

your input is a BIN file that is on-the-fly converted to a corresponding LAS file based on my best guess / understanding of the BIN format. The min max GPS time range for the LiDAR points in your file definitely suggests that the time stamps are GPS week time:

gps_time 0.000000 64873.441800

so without knowledge about *which* GPS week the points were acquired this does not help much. This week is GPS week 1849.

Maybe there is some additional information in the header of the BIN file. I know that the BIN format stored for each point a 4 byte time stamp that is assumed to be GPS week seconds. The storage format is a 32 bit unsigned integer where each integer step is 0.0002 seconds. But maybe the 'time' field in the BIN file header encodes the GPS week? Would make sense if it did ...

Martin @rapidlasso

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

[DJ Lehto]

Hi Ted:

 

Martin is right.  That looks to be GPS week time.  So you only are able to figure out what day of the week it was flown on without know what GPS week it was captured in.  However further to that, I think part of your file had data imported that did not contain timestamps or you have bad/corrupt records in the file.  That is why you see the 0.000000 time.  One other note about bin file timestamps is that old bin files stored only up to 4 decimal precision in the time and not 6 like LAS files do.  That means you can have duplicate timestamps in your file depending on the system that acquired it.  For example if that system was able to record multiple returns during acquisition you will have pulse that are very close together and the 4 decimal precision is just not enough to make each pulse unique in time. 

 

D.J. LEHTO, CGS

Production Manager

GeoDigital

 

O: +1 613 820 4545 x286

M: +1 613 668 8522

E: dle...@geodigital.com

 

Suite 140 | 1 Antares Dr.

Ottawa, ON K2E 8C4 | Canada

 

geodigital.com

 

 

[Susana Gonzalez]

Hi Martin,

I am following the steps in this post to recover flight lines from a VUX1 dataset.

The problem is that every time that I change the parameter -by_gps_time_interval in lassplit I get a different answer.

How can I decide which one is the right one to use? Attached some lasinfo (-histo gps_time 50, 200 and 1000)

Thanks

Susana

[Martin Isenburg]

Hello Susana,

looking at your time histogram with 50 second bins I see the blocks of times marked below. By using 50 second bins we can only detect gaps in GPS times that leave an *entire* 50 second bin empty. For plane surveys I usually do the analysis successfully with 10 second bins. As (copter) drone has much shorter turnaround time than a fixed-wing aircraft I would expect that we'll have to use smaller and not bigger time intervals. So I suggest trying to use 5 seconds or even only 2 seconds as a parameter to the '-by_gps_time_interval' option of lassplit when splitting the file. Maybe provide more lasinfo reports with this granularity if you need further help.

http://rapidlasso.com/lassplit

http://lastools.org/download/lassplit_README.txt

Regards,

Martin @rapidlasso

----------------[start]----------------

  bin [387300,387350) has 51951

  bin [387350,387400) has 95891

------------[50 sec break]-------------

  bin [387450,387500) has 195546

  bin [387500,387550) has 278733

------------[50 sec break]-------------

  bin [387600,387650) has 312669

-----------[600 sec break]-------------

  bin [388200,388250) has 10077

  bin [388250,388300) has 112055

-----------[100 sec break]-------------

  bin [388400,388450) has 1203

  bin [388450,388500) has 272345

------------[50 sec break]-------------

  bin [388550,388600) has 174101

  bin [388600,388650) has 110510

  bin [388650,388700) has 69763

  bin [388700,388750) has 93826

  bin [388750,388800) has 408586

  bin [388800,388850) has 17283

  bin [388850,388900) has 57394

-----------------[end]-----------------