Laser Altimeter Measurements of Earth's Moon

These images are available in the following formats
600x450/gltm2b_f.gif	600x450/gltm2b_b.gif
600x450/gltm2b_f.jpg	600x450/gltm2b_b.jpg
600x450/gltm2b_f.png	600x450/gltm2b_b.png
900x675/gltm2b_f.gif	900x675/gltm2b_b.gif
900x675/gltm2b_f.jpg	900x675/gltm2b_b.jpg
900x675/gltm2b_f.png	900x675/gltm2b_b.png
gltm2b_f.iv	gltm2b_b.iv
gltm2b_f.wrl	gltm2b_b.wrl

The 1994 Clementine mission to the moon included a LIDAR laser altimeter to measure lunar topography. This data file provides the resulting measurements, as described in this data definition. A HoloDraw script produced the above VRML models and images from the LIDAR data.

The vertical lines (mostly green) illustrate the path of the spacecraft as it orbited the moon in a North-South direction. Each individual colored dot represents one laser pulse fired at the moon and returned to the spacecraft. By knowing the position of the spacecraft, and measuring the time it takes for the laser pulse to bounce off the moon and back to the LIDAR instrument, we can calculate the elevation of the lunar surface to within about 40 meters (120 feet).

However this technique is not perfect. Sometimes the return pulse is detected earlier or later than we think it should be. So the points are color coded as follows:

Sometimes when you use HoloDraw to plot your data in 3D with color coding, you find patterns you may not have expected. This in turn can lead you to discoveries beyond what you were expecting when you collected the data. For example, in the plots above, you can clearly see patterns of color, including regions of blue, yellow and red. If errors in the detector function were random, you would expect these colors to be randomly distributed. Instead, the yellow-to-red bands are grouped horizontally near the equator and again at about 40 to 50 degrees South.

What does it mean? Is there something in the operation of the spacecraft or instrument that perturbs the LIDAR at about the same places on every orbit? Or are we inadvertently measuring some structural feature of the moon?

Notice also a blue area near 30 degrees North 170 degrees West. If this appeared only in one orbit (one vertical line) we might conclude that something odd happened to the instrument during that part of the flight. After all, there are plenty of other places where data is missing, resulting in a dark vertical band. A visible vertical artifact, aligned with the flight path, is what we would expect to see if there were a brief problem or abnormal condition. But this blue area persists across several orbits. One might suspect that it is geographically coordinated with some feature on the moon itself.

So, while the purpose of this mission was to collect laser altimetry data, did we unexpectedly collect other significant data as well? If so, would we have ever noticed it if we didn't make a color plot of the data values?

Educational Uses

Educators are welcome to use these images. If you have a GeoWall, you can show the .iv or .wrl files to a classroom or lecture hall of students wearing 3-D glasses. Or, you can rotate the .wrl globe in a web browser with a free VRML plug-in. If that won't work for you either, you can insert the .png images into a PowerPoint presentation. Go back to the top of this page for links to all of these file formats.

In addition to the above comments about the laser, here are some more general points that could be made:

• Notice that the orbit track lines appear to be parallel on the flat map, but on the sphere image the tracks converge at the poles. This illustrates that you cannot always rely on a flat map to accurately portray spatial relationships. When mapping a sphere, measurements are commonly expressed in degrees, but a degree is not always the same size everywhere. Degrees near the poles are smaller (encompass less of the surface) than near the equator.
• To get an accurate sense of spatial relationships on a sphere, you should view it in 3D (the right column of images). However, it is not possible to see the entire surface of a sphere at once. Half of it will always be hidden from view if it is projected in true 3D space. To observe features and patterns that may cover the entire surface, you might need a flat map. That allows you to see all sides at once, but does introduce the spatial distortion near the poles, discussed above.
• Notice that the white grid lines on the sphere are not square, but taper closer together nearer the poles. This also shows that degrees are not the same size everywhere, and thus can be troublesome when used to measure spatial features or relationships.
• Although the flat map makes it look as if most of the moon's surface was studied at equal resolution, the sphere makes it clear that the sample density is much greater as we approach the poles. This commonly happens with measurements taken from orbit. As the spacecraft circles the planet, it will pass over some areas much more often than others.
• Rotate the sphere to look at the North or South poles, and you will see blank spots in the data. This is because the spacecraft was not in a circular orbit. Instead, the elliptical orbit passed closer to the moon at about 30 degrees North and South, and moved farther from the moon in the polar regions. The spacecraft was too far from the moon to take an accurate laser measurement, so these areas are blank.
• You might also think you see some relatively blank areas near the equator, both East and West of 0 degrees longitude. Can you correlate these blank areas with lunar features? If so, what might we be able to learn from these patterns?
• If you zoom in very close to the VRML images, you can see clusters of points corresponding to laser measurements, and large gaps between them. The horizontal gaps represent the distance between subsequent orbital tracks. But the along-track gaps are places where no laser measurement was taken. Perhaps the laser was not fired, or perhaps it did not detect a usable return pulse. This illustrates some of the difficulties with planetary surveys from orbit. Data may be incomplete or flawed for any number of reasons. If you see an allegedly complete map, it could be that someone has filled in the gaps using interpolation or some other method of guessing what the data might have been had the measurement been successful. You should always beware of over-reliance on interpolated data. You don't want to base significant conclusions on numbers that were artifically generated to fill in the blanks. One good way to avoid this error is to get the cleanest data you can (data that hasn't been altered to obscure irregularities) and plot it using a tool like HoloDraw. When you look at the real data, you can be more confident about what regions can support reliable conclusions, and where you need to be more careful.
• Compare the image quality of the .gif, .jpg and .png images above. Does this help you decide what image format to use for your images?

How These Images Were Made

You too can make images like this from your data files. To get started, download a free copy of HoloDraw, and install a free VRML plug-in in your web browser. Then, take a look at this script to see how you can combine HoloDraw programs to assemble images like these.

Here is a copy of the script, in case you have trouble downloading the link above:

#!/bin/sh
# filename:  gltm2bpr.sh
# author:    Marvin Simkin
# date:      2005-01-26
# purpose:   extract laser bounce points from file

# the source data gltm2bpr.tab comes from
# http://pds-geosciences.wustl.edu/geodata/clem1-gravity-topo-v1/cl_xxxx/topo/gltm2bpr.tab

# columns are documented at
# http://pds-geosciences.wustl.edu/geodata/clem1-gravity-topo-v1/cl_xxxx/topo/gltm2bpr.lbl

# we are interested in columns:
# 2: LONGITUDE: East degrees of the laser bounce point
# 3: LATITUDE: Degrees +North or -South of the laser bounce point
# 5: RELATIVE ELEVATION: meters +above or -below a 1738 km radius sphere
# 7: BIN: Did the laser trigger before (0), inside (1-4), or after (5) the range window

# trigger 0 is blue
echo 'color = 0 0 1' > gltm2bpr.draw
cut -f2,3,5,7 -d',' < gltm2bpr.tab |
  grep '0$' |
  awk ' BEGIN { FS = "," } { print "point:" $1 " " $2 " " $3 } ' >> gltm2bpr.draw

# trigger 1 is green
echo 'color = 0.0 1.0 0.0' >> gltm2bpr.draw
cut -f2,3,5,7 -d',' < gltm2bpr.tab |
  grep '1$' |
  awk ' BEGIN { FS = "," } { print "point:" $1 " " $2 " " $3 } ' >> gltm2bpr.draw

# trigger 2 is green-yellow
echo 'color = 0.50 1.0 0.0' >> gltm2bpr.draw
cut -f2,3,5,7 -d',' < gltm2bpr.tab |
  grep '2$' |
  awk ' BEGIN { FS = "," } { print "point:" $1 " " $2 " " $3 } ' >> gltm2bpr.draw

# trigger 3 is yellow
echo 'color = 1.00 1.0 0.0' >> gltm2bpr.draw
cut -f2,3,5,7 -d',' < gltm2bpr.tab |
  grep '3$' |
  awk ' BEGIN { FS = "," } { print "point:" $1 " " $2 " " $3 } ' >> gltm2bpr.draw

# trigger 4 is orange
echo 'color = 1.00 0.50 0.0' >> gltm2bpr.draw
cut -f2,3,5,7 -d',' < gltm2bpr.tab |
  grep '4$' |
  awk ' BEGIN { FS = "," } { print "point:" $1 " " $2 " " $3 } ' >> gltm2bpr.draw

# trigger 5 is red
echo 'color = 1.0 0.0 0.0' >> gltm2bpr.draw
cut -f2,3,5,7 -d',' < gltm2bpr.tab |
  grep '5$' |
  awk ' BEGIN { FS = "," } { print "point:" $1 " " $2 " " $3 } ' >> gltm2bpr.draw

# raise the floor 1738000 meters (1738 km)
drawmove.pl 0 0 1738000 < gltm2bpr.draw |
  # optimize points of the same color
  drawmash.pl |
  uniq > gltm2bpr.mash

# --------------------------------------------------------------------------
# flat

# set bounding box attributes and corners
echo 'color = 1.0 1.0 1.0; fontheight=200; point:0 -90 1738000, 360 90 1738000' |
  drawbbox.pl -B30+10/30+10/0 |
  # no viewpoints yet
  egrep -v 'speed|viewpoint' > flat/gltm2bpr.box

cat gltm2bpr.mash flat/gltm2bpr.box |
  # accomodate units of measure meters vs. degrees
  drawsize.pl 1 1 0.0001 > flat/gltm2bpr.sized

# make better viewpoints by reading the resized data
drawbbox.pl < flat/gltm2bpr.sized |
  egrep 'speed|viewpoint' > flat/gltm2bpr.view

cat flat/gltm2bpr.sized flat/gltm2bpr.view |
  # VRML 2 for web browsers
  drawwrl.pl > flat/gltm2bpr.wrl

cat flat/gltm2bpr.sized flat/gltm2bpr.view |
  # VRML 1 for GeoWall
  drawiv.pl > flat/gltm2bpr.iv

# --------------------------------------------------------------------------
# ball

# make a solid surface so we don't see points from the other side
echo 'color = 0.1 0.1 0.1; polygon: 0 -90 1700000, 360 -90 1700000, 360 90 1700000, 0 90 1700000' |
  drawchop.pl x=10+10 y=10+10 |
  drawball.pl > ball/gltm2bpr.surface

# set bounding box attributes and corners
echo 'color = 1.0 1.0 1.0; fontheight=1500; fontjust=CENTER; point: 0 -90 1800000, 359.9 90 1800000' |
  drawbbox.pl -B30-360/30-450/0 |
  # no viewpoints yet
  egrep -v 'speed|viewpoint' |
  # chop the box for drawball.pl
  drawchop.pl x=10+10 y=10+10 |
  # and make it round
  drawball.pl > ball/gltm2bpr.box

# make better viewpoints by reading the ball
drawbbox.pl < ball/gltm2bpr.box |
  egrep 'speed|viewpoint' > ball/gltm2bpr.view

# the first 3 files have already been made into ball-shape
# but the data file hasn't yet, so do it now
( cat ball/gltm2bpr.view ball/gltm2bpr.box ball/gltm2bpr.surface;
  drawball.pl < gltm2bpr.mash ) |
  # VRML 2 for web browsers
  drawwrl.pl > ball/gltm2bpr.wrl

( cat ball/gltm2bpr.view ball/gltm2bpr.box ball/gltm2bpr.surface;
  drawball.pl < gltm2bpr.mash ) |
  # VRML 1 for GeoWall
  drawiv.pl > ball/gltm2bpr.iv

This is a Unix shell script. If you are using an operating system that is not very good at following scripted commands, you may have to perform most of the above steps manually. Nevertheless, you can still use HoloDraw to produce 3D images like this.

Written by Marvin Simkin Filename gltm2bpr.html Last updated April 14, 2005