flight altitude from gps time, z, and scan angle

[Mike Alonzo]

Hi --

I do not have information about the flight altitude of my lidar acquisition. I do have all the normal point-level attributes (X,Y,Z, scan angle, gps time, etc.).  It is my understanding that gps time should allow for reconstruction of flight altitude (from US Forest Service: "The GPS time of a pulse or return can be used to determine the distance in three dimensions between the return and the antenna of the laser instrument"). 

This makes sense if that time measures time-of-flight.  But it seems like gps time is actually raw seconds-of-week time, so I'm not sure how to get range info from this. Can one determine the time-of-flight simply by taking unique(gpstime) to remove multiple returns with identical gpstime and then subtracting the previous gpstime from the current one?

Thanks for any thoughts,

Mike Alonzo

UCSB Geography

[Ian Madin]

Did you get SBET files with your data? That would give aircraft xyz.

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

[Nick Vaughn]

Assuming you have multiple returns per pulse, I believe one methodology would be to use multiple returns for a given GPStime to compute a vector [dx,dy,dz] from the sensor to the returns.  Doing this for multiple GPStime values would give you several vectors which would nearly cross (you could compute find the shortest distance between the two vectors.  at the sensor altitude.  You could very roughly reconstruct your entire flight path this way.

Nick Vaughn
Carnegie Institution for Science
260 Panama St.
Stanford, CA 94305
USA
+1 650-843-9073
Skype: Nick_R_Vaughn

[Heidemann, Hans]

Call the vendor.

Flight altitude is a fundamental piece of lidar metadata. 

The project should not have been delivered to, nor accepted by the client without it.

Karl

H. Karl Heidemann, GISP

Physical Scientist, Lidar Science

U.S. Geological Survey

Mundt Federal Building

47914 252nd Street

Sioux Falls, SD  57110

605-594-2861

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

--

[Terje Mathisen]

Assuming you have gps time of each returned pulse, with sufficient (i.e.
sub-ns!) precision as well as x,y,z,angle with similar resolution, you
should indeed be able to calculate the flight path:

You first sort all returns into time order (if not already sorted), each
stripe of data gives a course flight path as the center of the stripe,
right?

The flying speed can be approximated pretty well by taking all the
points with scan angle straight down and using just these to calculate
the direction and speed (linear rms interpolation between those points.

Add in the side-scanning points with corresponding scan angle, and you
can calculate the flight altitude from the correspondence between angle
and sideways offset.

The result should be a meter-level or better flight path!

Terje
--
- <Terje.M...@tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Kirk Waters - NOAA Federal]

You might be able to get a rough idea of the altitude by looking at two points on opposite sides of a scan and their scan angles. I believe that would give you enough information about a triangle to solve for it. It would have some error since the scan angles aren't recorded with a lot of precision, but it would probably give you as close as the metadata would have been and you don't need time info. I agree with Karl that it should have been in the metadata though.

Kirk

--

Kirk Waters, PhD                           | NOAA Coastal Services Center

Applied Sciences Program          | 2234 South Hobson Ave
843-740-1227                                | Charleston, SC 29405    

www.csc.noaa.gov/digitalcoast

[Mike Alonzo]

Thanks, everyone.  I have located the SBET and trj files. I've never accessed information from these before though. Any suggestions of how to connect the flight data with the points?  My googling has only shown that most use of the SBET files is in vendor/proprietary software or possibly TerraScan.  Btw-- my ultimate goal here is to determine beam footprint on vegetation.

Mike

[DJ Lehto]

If you use Tscan you can create a macro that will link the time of the sbet to the points.  It’s done through the flightline number dropdown on the main tscan window its called the deduce lines command(also available as a macro step).  There are a couple of tips I would suggest before you do that.  First once you have the sbet loaded I would cut the turn around to create your individual strips per pass. Secondly remove little babits, I call those things the little pieces of the turnarounds that don’t have LiDAR associated to them from the newly cut sbet/trajectory.  Sometimes there is a great deal of them and can make a mission that has 10-15 actually lines look like there is 30-50 lines.  However that’s just personal preference, but it makes things cleaner and easier for debugging later. Thirdly renumber the trajectory so you have sequential numbering between overlapping flightlines (another preference).  Once you are happy with your sbet/trajectory folder now you can run the deduce lines macro or command either in a batch per file or on loaded points.  Few more tips/suggestion if you have more than one days of collection I would suggest first cleaning the sbet/trajectories for each mission first separately, also make sure you have unique numbering per mission don’t restart at 1 each time for each mission and finally combine the trajectory/sbets all into a new master folder before deducing time because if your provided blocked your data you most like have blocks that contain data from two different days because of overlap, however and this is a big however.  If your data is in gps time of week and not adjusted time you cannot deduce data that was flown on two days that are similar times of the week.  So for example, if you data was collected today being Wed. and then you have a bunch weather days and the next free time for collection happens to be next Wed.  you will have the potential to have similar GPS time of week time stamps in your data because GPS time of week resets every week to zero at rollover.  There are two options to make this work, first is to deduce each day individually if you can separate your block that have two similar days of the week collection or switch both your LiDAR data and sbets to adjusted GPS time as this will be a unique time. 

 

Sorry for the long answer there… and not really helping if you don’t have tscan.  However I don’t think it’s possible to calculate the size of the beam as it hits the object unless is a flat surface.  The reason being is that most system today fly with multiple returns shots to the system during the acquisition, so one shot can sometime return up to 10 or more different LiDAR hits just from that one shot from the system.  Most people usually only see 4 – 5 shots but the LIDAR system makers suggest they can do more.  I know using one of our older LiDAR systems that collects up to 5 returns per LiDAR shot is that we spec it at 30-40cm when it hits the flat ground flying at about 1000m agl and the spot size can elongate or shorten based on flying height and terrain slope. Therefore I don’t think it is possible to figure which part of the beam came off of the object because of those few reasons,  I could be wrong I have never been asked that question before.   However, your provider should be able to give you the theoretical beam footprint size, usually the LiDAR system vendors give out those parameter in their spec sheets so that the LiDAR spot size can be calculated theoretically as it hits a flat surface.  I could go on much longer about spot size but I don’t want bore you more. 

                                                                                                                                                                                                 

D.J. Lehto | Production Manager

GeoDigital International Inc.

1 Antares Drive, Suite 140 | Ottawa, ON | Canada K2E 8C4

tel: 613-820-4545 x 286 | cell:  613-668-8522

fax: 613-820-9772 | toll free: 1-800-231-4969

website: www.geodigital.com

 

__________________________________________________________________

CONFIDENTIALITY NOTICE This E-Mail transmission and/or the documents accompanying it is for the sole use of the intended recipient(s). If you are not an intended recipient, you may not review, use, copy, disclose or distribute this message or any of the information contained in this message to anyone. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this message and any attachments.

--