LIDAR Data from a Tunnel, major problem.

[Tim Rothwell]

Hi

This is quite an involved issue, hopefully my explanation will make sense:

We have have used the Trimble MX2 mobile mapping system to scan some under ground tunnels (four in total including a trial tunnel). For two of the data sets the files are OK (although slightly distorted ) but for the other two the data is heavily distorted (see attached images the OVal image is distorted and the roundish image is what it is supposed to look like) the Tunnels vary in  length from 100m (test tunnel) to 18km and are 2.6m diameter. Originally the data was processed with an SBET (trajectory) file generated via POSPac. Unfortunately the POS data for the two failed tunnels was corrupt and there is no way to regenerate them and absolutely no chance of re-scanning the tunnels as they are now full of water! I have been attempting to get help from Trimble in this matter but so far they have fallen short.

However during my investigations I found that  I could produce LAS files from the Trident capture database (.LA20 files) without the need for any trajectory files (SBET), this has lead me to believe that it is using data contained within the capture database and indeed there is a table within the database that contains coordinates that define the route of the tunnel in Lat/long format. Unfortunately this data is missing or insufficient for the failed tunnels, but we do have the means of generating this data using an EDM survey we carried out two years ago.

I tried this for the two failed tunnels but it did not work leading me to believe that there is something within the LA20 files (and the resulting LAS files) that is causing the problem, hence my interest in looking at the feasibility of editing the LAS files within LAStools.

Geographical positioning is not as important as the need to get the correct shape of the tunnel, so (and I know it may be a tall order) can any one suggest a method of editing the data within LAStools that will correct this problem?

Thanks

Tim

[Tobias K Kohoutek]

Hi Tim,

I don't have a solution for LAStools available but,

if you say you do have Lat and Long position of the data capture are you sure those are correct without the sbet?

I mean if I look at your tilted (ellipsoidal) point cloud and compare it with the images that show Trimble MX2 search, it seems like the scanner was mounted tilted and not orthogonal towards the tunnel axis. If so, and if your data capture positions are correct, you would need the tilting angle of the scanner and you should be able to transform the ellipsoidal point cloud to a circular one for each capture point.

Or, you add all together to a line, which would be the tunnel axis and then you should see the complete tunnel as well as a tube in which ground and ceiling don't match at the beginning and end of the tunnel due to tilted mount of the scanner.

Just an idea so far.

Cheers,

Tobias

[Martin Isenburg]

Hello Tim,

Interesting challenge you have there. Maybe someone from Trimble could confirm whether those Trident *.la20 files are - as I am assuming - very similar to LAS files but using the (never ratified) 2.0 specification. There was a time when Trimble Trident used the *.las extension for those files causing a lot of confusion as they appeared as if they were an ASPRS file standard when they in fact were a Trimble Trident format. See this discussion here:

http://groups.google.com/d/topic/lastools/tfl_0-8cY0A/discussion

and this one here:

http://groups.google.com/d/topic/lasroom/ljHEaX_47Nw/discussion

Looks like they did follow through and have renamed those files.

Assuming those *.la20 files that you have are files in the (never ratified) LAS 2.0 format then you could write your own parser to peek inside by implementing (parts of) the (never ratified) LAS 2.0 format. I seem to remember that it used to be linked from here

http://www.asprs.org/committee-general/laser-las-file-format-exchange-activities.html

but I found a copy here 

http://www.lidar.com.tw/docs/asprs_las_format_v20_proposal.pdf

Then you should be able to recover the coordinates and reconstruct - at least an averaged trajectory - from the points in your *.la20 file assuming they are correct in there. But that may not be the case as the error may have occurred earlier. In a follow up (personal ) message you wrote that "One way I looked at trying to fix this was to use the trajectory from the successful section for the post processing within Trident. Surprisingly this worked, but only for 4km of the length then the rest of the point cloud data was distorted. We have looked at attempting to collect trajectory data to use but this is proving quite difficult to arrange."  So maybe parsing the contents of the *.la20 files will help you but I am not familiar with the exact workflow you were sketching out there.

Regards,

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