We have moved! Please visit us at ANTHROECOLOGY.ORG. This website is for archival purposes only.

Dec 26 2011

Ecogeo versus spline codes

There was one last thing that I did for the error analysis. 

Going through the raw ply data set from Herbert Run Spring 2010 in an arbitrary coordinate system, I picked out the locations of 5 buckets that were in the shape of an X on campus:
100, 102, 108, 111, 114.

Using ScanView like before, I was able to pick out each location for these buckets by individually chosing points within the area where a bucket should be that appeared to be a part of a clump of orange. I took the average of each x,y,z coordinate for each set of points to obtain an approximate center of where the buckets should be located in the arbitrary coordinate system generated when the point cloud was made. I then paired these coordinates with the referenced locations of where each specific bucket is located in GPS coordinates. 

This data was used by a different python code ecogeo4.py, which is also a way of getting the 7 Helmert parameters needed to transform arbitrary point cloud into the correct GPS coordinate system. This code takes one parameter text file which should be in the following format:

arbitraryX arbitraryY arbitraryZ realX realY realZ,

one point per row, seperated by spaces not tabs.  

Using the 5 buckets mentioned before, I ran the ecogeo code to obtain a new set of helmert parameters. I then used the applyHelmert python code to transform a list of the locations of the buckets in the raw point cloud, consisting of just 14 points.

This yielded data similar to the process of using the spline.py code. The z direction is still inverted, which is the coordinate that most of the error is coming from. The x and y directions are very good.
For the tranformed x values verses the expected x values, the trend line y = 1.0008x - 265.39, with an R2 of 0.9998.

For the y values, y = 0.9998x + 3372.5, also with an R2 of 0.9998.

The z coordinates are odd with a trend line of y = -0.2557x + 68.562 and an R2 of 0.1563, which is really bad not only because the data is inverted, but it seems to be quite unrelated. 

This data resulted in root mean square errors of distances between actual bucket locations and predicted bucket locations of 2.354 in the XY plane, 9.045 in the Z direction and an overall error of 9.346.

The result I recieved with the spline code had RMSE errors of 4.198 for XY, 95.167 for Z and 95.299 overall. Obviously the spline code does a much worse job converting the data in the z direction than this ecogeo code does, but in the xy plane, the errors aren't too far off.

Overall, the spline code seems to work almost as well as the ecogeo code did with this small data set in the x and y directions, but there is still the confusion with the z direction due to inversion.

Dec 17 2011

TLS scanning at UMBC

We have been having an exciting time in New Jersey and Baltimore working with aTerrestrial Laser Scanner (TLS; Riegel VZ400) for generating high quality 3D reference datasets for validation of Ecosynth data.  We are in the lab today because of windy conditions, working on post-processing and data management of the large amounts of data collected in New Jersey and in the photo studio at UMBC.  I thought it would be a good time for a short update post.

These pictures are from our test setup of mobile scaffolding that we will use for gaining an elevated perspective on several open grown trees for TLS scanning.  The plan is to set up the scaffolding at each of the 4 orthogonal scan stations with the TLS mounted on the platform as shown.

The tower platform is about 2m above the ground and the TLS scanning head is about 3m off the ground.  The tower can be moved by 3-4 people to each of the scanning positions, after the TLS equipment has been taken down!

We have also configured the TLS for WLAN control, meaning that we can operate scanning and review data wirelessly.  This should be useful for when we attempt TLS scanning from the bucket crane.