Redwood forests- with Earth’s tallest trees, one of the most impressive natural ecosystems on Earth.   For Arbor Day, Save the Redwoods League worked with Google Earth Outreach to model old-growth redwoods on Google Earth.  Great work- check out the kml in Google Earth!  A great example of what citizen science can do to raise awareness.

Makes me think of our Earthwatch Project in Huang Cun China this summer- can we create visualizations of the ancient village landscapes of China?  These are every bit as impressive and nearly as ancient as Redwood forests.   Can citizen science raise global awareness of these?

Agisoft’s Photoscansoftware is simply amazing!

The picture at left is an orthorectified photo mosaic over our Knoll research site on the UMBC campus generated by Photoscan automatically using only input photos that I took with the Hexakopter.  For reference, each Hexakopter photo covered less than a 10th of the area observed in this scene. 

An orthophoto is a photo that has been mathematically distorted based on the differences in elevation of the scene so that everything appears ‘flat’, or it appears that the camera was right above each point in the photo.

Photoscan uses similar computer vision technology that Bundler and Photosynth use to automatically recreate the 3D structure of a scene from only photos.

The professional version of the software also makes it very easy to georeference the scene to a geographic coordinate system, making it possible to easily view in a GIS software … or in Google Earth.

Here is a link to a Google Earth image file that Photoscan generated from our photo set, enjoy (35MB kmz file)! 

I am working on getting some 3D output to Google Earth next.

The GPS tracks for the Mikrokopter were somewhat mystifying.  The altitude of calibration didn't seem to be zero, and the altitude of height didn't seem to be programmed correctly.  GPS is relatively weak on the Z dimension compared to X and Y,  but this didn't look like random noise.  We understand that Google Earth's DEM isn't perfect, but even the flight paths were distorted.  Viewing them in Google Earth by default, they exhibited a strange curve that seemed to follow the terrain at height.  When you tried to put it relative to the ground (Above Ground Level) the GPs track started in midair, and when you tried to put it in an absolute frame (Above Mean Sea Level) the track disappeared into the ground.

Initially I thought that things were simply measured relative to the GPS calibration site.  The offset mode in Google Earth, the natural place to go to fix this, does not work.  Assuming that you want a flat surface at a fixed elevation AGL or AM, Google strips altitude information and replaces it with a fixed amount which produces, respectively a flat surface for AMSL or a mirror image of the digital elevation model for AGL.  Examining the data in plaintext, I saw that the first elevation recorded was 6 meters or so... not alleged ground level of 49 meters where Navi-Ctrl was calibrated, *or* sea level.

The air-pressure-based altimeter only makes things more mysterious, because it’s difficult to tie the numbers to the elevation.  According to a post on the MK website, the altimeter measures ticks that are adjustable in height with a default of 22.5 ticks per meter.  Examination of the data suggests that it, unlike the GPS tracks, does zero out when the Navi-Ctrl is calibrated.  Further investigation of its accuracy is pending.

It turns out, the GPS unit we have in the MK records according to the WGS datum.  This is an ellipsoid, which approximates the earth with a simple equation-derived curve stretching in a slightly-less-than-spherical fashion from the poles to the equator.

Since we entered the era of GPS and satellite determination of location, we've realized that an ellipsoid doesn't work very well for altitude in relation to sea level.  The Earth's entire mass determines gravity levels, which results in a sea surface which smooths out to fill a particular gravitational level.  Unfortunately, that mass isn't homogenously distributed, even if we can average it out to a very precise center-of-mass.  There are significant regional distortions to the density of the earth, and thus to the iso-gravity surface we call mean sea level.  Correcting for these results in a gravity measurement of MSL called a Geoid.

The standard international geoide for representing elevation relative to MSL seems to be WGS84 + EGM96.  This is what Google Earth uses, and why none of the tracks fit well.

I eventually settled on GPX Editor, which allows you to select the track and shift altitude, to fix this.  But what altitude to use?  A website run by the NGA gives us the answer: http://earth-info.nga.mil/nga-bin/gandg-bin/intptW.cgi .  At Herbert Run, Latitude 43.257389 & Longitude -76.705690 offers a Geoid height of: -34.73 Meters.

Given the low resolution and accuracy of Google's DEM this is most suitable for flat areas rather than the steep hills at Herbert Run, but it's a large improvement when viewed in Google.

GPX Editor:

The corrected result:

Google has an elevation profile tool that could be useful: