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


Apr 09 2012

First Test of PVC Markers


On Thursday 4/5/2012 Jonathan and I went to HR with 2 other students to attempt to lay out the PVC pipe that will mark the 5x5 meter grid. Our plan was to lay a reference string between 2 of the serveyed points in the 25x25 meter grid. Once this was done we could measure 5 meters along this line with our wooden poles, string, and line levels to help ensure accuracy. We secured a string between the two wooden poles measured at 5 meters We would than insert PVC poles like the ones to the left at these 5 meter marks. However when we finished our first 4 points and came to the known survey point we were anywhere from 10 to 30 cm off. This was too much inaccuracy and we quickly saw that the string connecting the two wooden poles could flex, this being our cause of inaccuracy, we determined we needed a more rigid material to connect the poles. Back at the lab we found some thin metal wire and after attatching this to the wooden poles and retesting the same strategy as before the accuracy was greatly improved, at most we had a 1 to 2 cm innaccuracy with most of the corner points we plotted landing directly on the survey point.

Mar 27 2012

Topography and the Mapping Grid

There has been a new data sheet designed to address the specific needs of the forest we are working with. Because the method for mapping the trees has changed, the data sheets also needed to be altered. We are returning to the previous used method of laying out a 1x1 meter grid within our 5x5 meter grid. Once this is complete the location of the trees will be marked on the graph found on the data sheet. There has also been a "codes" column added to the data sheet to represent trees that may need special attention. This could include a leaning stem, a stem broken below breast hight, or as seen in the picture multiple stems from one trunk forming below breast height. However, before the trees can be mapped the grid must first be sectioned into 5x5 meter squares. Jonathan, fellow students, and I are hoping to get one of the 25x25 meter plots sectioned off so we can begin to test our tree mapping stratgies. We are also tackling the problems we may face concerning drastic elevation changes. In summary we have all of our supplies ready and in bags we just need to find a time to get dirty and see how our ideas work.


 

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.

Feb 11 2011

Rising Popularity of the R Programming Language

According to a recent analysis of the search hit popularity of the top 100 programming languages, the R Statistical Computing language, has surpassed both MATLAB and SAS.

I first read about this from the Revolutions blog, a blog dedicated to posting news and content about R, and was happy to see from the survey report charts that the free R software has such relatively high popularity compared to similar languages.  It is worth noting here that the popularity difference is slight due to the fact that this survey counts many languages that are more popular than either R, MATLAB, or SAS. R (#25) had a popularity of 0.561%, MATLAB (#29) 0.483%, and SAS (#30) 0.474%.  Meanwhile Python (#4) has a popularity of about 7%, C (#2) about 15% and Java at #1 with about 18.5%.  The Revolutions blog also makes the important point that the methods used to compute these stats may be a bit controversial, but the stats still serve a purpose.

I first learned R from taking a graduate level statistics course at UMBC, Environmental Statistics 614, and have developed my skills with the programming language to help with data analysis and preparing graphs and figures for papers.  I used R to perform the data analysis and generate the non-map figures for our first paper on Ecosynth and will continue to do so for future publications.

I have only used MATLAB to execute a camera calibration program for my Computational Photography class last semester and I learned a bit of SAS programming for my Multivariate Statistics course last year.  I think both have their uses, but I am really fond of the relatively light-weight size and 'cost' of R.  I am also interested in adding in the scientific and numerical programming functions of Python, SciPy and NumPy.  The SAGE project utilizes SciPy and NumPy to establish a robust free and open-source alternative to for-pay analytical tools like MATLAB, and is also increasing in popularity.  

Free open-source revolution!  This makes me want to put up a post about open-source GIS software...