Earth Viewer Details

How did you do that in HTML?

The HTML documents form only the skeleton of the Earth viewer. They assemble a request which is sent, using the CGI mechanism, to a server application written in C. The server, given the viewing parameters you selected in the HTML file, creates a GIF image of the requested view, then returns an HTML document which references the GIF file as an in-line image. Fields in the form of this result document are initialised to the parameters passed in with the request. To better understand what's going on, view the source of the result of a query. Note that since the source is custom-generated for each query, it will be different every time.

Okay, I just looked at the source. What's with this cache directory?

Ahhhh.... That's interesting. Since we want to return the result of the query as an in-line image, it must reference an external GIF file. (If the query server returned the GIF file directly, we wouldn't be able to embed it in the form that allows subsequent queries. Furthermore, Mosaic would spawn an external viewer for the image rather than show it on the page.) So, having to write a separate GIF file raises the issue of where it goes and how to keep the system from being clogged with leftover images. My answer to this problem is to create GIF files in the cache directory with unique names generated based on the process ID of the server program. As each file is written, an at job is queued to delete it five minutes later. This way the image files are automatically cleaned up.

Is source code available for the server program?

Of course. Look in the ftp://ftp.fourmilab.ch/pub/kelvin/earthview/source directory. The server isn't terribly easy to install, since you have to put some pieces in your cgi-bin (or whatever) directory, others in your Web document server area, and then fix links all over the place, both in the C code (since it creates HTML on the fly) and in the documents. Then, of course, there's the CPU time that will be eaten as folks start using your server. A 320╫320 pixel globe image takes about 6 seconds of CPU time on the Sun SPARCStation 2 currently running the server.

Aha! That's why it's so slow!

In part... To keep my machine from getting utterly bogged down by Earth viewer requests, all globe renderings are run as Unix nice processes, with a priority level set depending on the size of the image requested according to the formula:

    nice = 6 + (size / 100)

where size is the image size in pixels. Thus larger image requests are performed in the background with regard to smaller ones. The image rendering time goes as the square of the size. Since all requests are nice, if my machine is busy with regular work, everything will slow down. This rarely happens, since the machine on which the server is running is used almost exclusively as a file server, not a crunch machine. Also, my network connection is 64 kbps, not one of those hulkin' T1 lines, and may become congested if lots of requests arrive at once. Finally, if you're in the Western Hemisphere or Asia, recall that it takes a while for the data to get back and forth from your client to the server in Switzerland.

Switzerland, eh? Anywhere near CERN?

Next door by Los Angeles standards, but rather far away by Swiss reckoning. We're north of NeuchΓtel, the emerging Silicon Valley of central Europe, about 80 minutes by train from Geneva, the home of CERN. Like CERN, we're in la Suisse romande, the French speaking region of the country. Take a tour of Switzerland, thanks to the University of Geneva. Science fiction fans may be amused to note that the building housing the server which sent you this document was the model for the evil Roger Coolidge's robot lab in Rudy Rucker's novel The Hacker and the Ants. Of course, Roger got what was coming to him. Or did he...?

Where'd you get the idea?

From the Xerox PARC MapViewer. Since Home Planet already contained all the needed logic, making a Web version seemed like a cool thing to do.

What algorithm do you use to generate the images of the Earth?

It's a straightforward ray tracing algorithm. Project vectors from eye at the given view point toward each pixel on the projection plane. If the ray intersects the sphere of the Earth, calculate which pixel in the texture map image corresponds to that point on the sphere, then set the pixel in the resulting image to that colour. Note that we can't just do a simple texture map, since what you see is not a half-sphere, but an accurate representation of the view from the given altitude--as you get lower, the horizon becomes closer.

How do you calculate the day and night regions of the Earth?

The position of the Sun with respect to the Earth is calculated by the algorithm given in Jean Meeus' Astronomical Algorithms. Once the position of the Sun is known, the terminator (line separating day and night) is simply the circle where the plane perpendicular to the Earth-Sun vector and passing through the centre of the Earth intersects the globe, which is straightforward to calculate. Then it's simply a matter of colouring the hemisphere away from the Sun in subdued shades. (Actually, this is done by flipping the high-order bit of the pixels in the bitmap, the colour palette having been craftily composed as a day half and night half.)

How do you get the current cloud cover from weather satellites?

Almost all the work is actually done by the University of Wisconsin-Madison Space Science and Engineering Center, which assembles a "World-wide Composite" from infrared images from GOES, METEOSAT, and GMS satellites every three hours, and makes the image available on their Gopher server. This image displays the whole globe in the Mollweide equal-area projection. I re-project the data in this image into the Mercator projection expected by Earth viewer (the pale blue regions near the poles represent areas for which no image data are available). This image is then overlaid on a cartoon image of the Earth which distinguishes ocean, continental, and icecap areas. In this process, the contrast of the original weather satellite image is enhanced to show the cloud patterns more clearly. This composite image becomes the image map from which views of the Earth are projected. The original Mercator re-projection is also made available as the "IR clouds" image option, as it displays more fine detail than the more attractive composite.

How does the satellite tracking work?

The satellite tracking code was lifted directly from a package called N3EMO Orbit Simulator developed by Robert W. Berger, N3EMO. It calculates the current position of a satellite from its Keplerian elements (see below), by solving the equation of Kepler in the classical manner for computing orbits. Once the geocentric rectangular coordinates of the satellite are known, it's a snap to calculate the latitude and longitude of the point beneath the satellite and its altitude above Earth's surface.

What do all those numbers mean in the "orbital elements" panel for satellite tracking?

They're Two Line Elements (TLEs), also called Keplerian Elements or just "Keps", in NASA/NORAD format. Data for each satellite consists of three lines in the following format:

AAAAAAAAAAA
1 NNNNNU NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNN-N +NNNNN-N N NNNNN
2 NNNNN NNN.NNNN NNN.NNNN NNNNNNN NNN.NNNN NNN.NNNN NN.NNNNNNNNNNNNNN

Line 0 is a eleven-character name.

Lines 1 and 2 are the standard Two-Line Orbital Element Set Format identical to that used by NORAD and NASA. The format description is:

Line 1
Column     Description
------     ---------------------------------------------------
 01-01     Line Number of Element Data
 03-07     Satellite Number
 10-11     International Designator (Last two digits of launch year)
 12-14     International Designator (Launch number of the year)
 15-17     International Designator (Piece of launch)
 19-20     Epoch Year (Last two digits of year)
 21-32     Epoch (Julian Day and fractional portion of the day)
 34-43     First Time Derivative of the Mean Motion
        or Ballistic Coefficient (Depending on ephemeris type)
 45-52     Second Time Derivative of Mean Motion
           (decimal point assumed; blank if N/A)
 54-61     BSTAR drag term if GP4 general perturbation theory
           was used.  Otherwise, radiation pressure coefficient.
           (Decimal point assumed)
 63-63     Ephemeris type
 65-68     Element number
 69-69     Check Sum (Modulo 10)
           (Letters, blanks, periods = 0; minus sign = 1)

Line 2
Column     Description
------     ---------------------------------------------------
 01-01     Line Number of Element Data
 03-07     Satellite Number
 09-16     Inclination [Degrees]
 18-25     Right Ascension of the Ascending Node [Degrees]
 27-33     Eccentricity (decimal point assumed)
 35-42     Argument of Perigee [Degrees]
 44-51     Mean Anomaly [Degrees]
 53-63     Mean Motion [Revs per day]
 64-68     Revolution number at epoch [Revs]
 69-69     Check Sum (Modulo 10)

All other columns are blank or fixed.

Example:

NOAA 6
1 11416U          86 50.28438588 0.00000140           67960-4 0  5293
2 11416  98.5105  69.3305 0012788  63.2828 296.9658 14.24899292346978

Satellite X is in the wrong place. Where did you screw up?

I'm far from infallible, but odds are the problem is out-of-date orbital elements. Orbital elements are only valid for a short time after they are published (they're called osculating elements since they "kiss" the actual orbit only around the time they're issued). Get up-to-date elements from the database sources listed at the bottom of the satellite page and the results will probably be correct. If you're a Space Shuttle observer, recall that the Shuttle maneuvers maneuvers frequently during many missions, and each Orbital Maneuvering System burn changes the orbit and invalidates prior elements. As a result, you don't need up-to-date elements, you need up-to-the-minute ones for the Shuttle. Other satellites also maneuver occasionally, but not as frequently nor as substantially.

Wasn't it a lot of work to build this program?

Actually, only a couple of days. Most of the code was lifted almost directly from Home Planet and, in addition, I was able to stand on the shoulders of many others who developed freely available code or algorithms the program employs; if I've failed to acknowledge any contributor, please accept my apologies and let me know of any lacunµ so I can properly cite their contributions in the next release. I developed Home Planet to be a title in the Autodesk Science Series, following Cellular Automata Lab and James Gleick's CHAOS: The Software. When new management arrived at Autodesk, one of their first actions was to terminate the Science Series, along with a number of other products, some profitable, which did not "meet the business model". I obtained the rights to Home Planet and decided to place it in the public domain. Since then, in my spare time, I've been mining the man-year I invested in its development to build public domain Windows and Web tools. This isn't the last.

My Whatever browser doesn't work with Earth viewer.

We're a long web away from total compatibility among browsers. I've tested Earth viewer with NCSA Mosaic Version 2.4 and Netscape 1.0N (both primarily on the Silicon Graphics version, though also less extensively on Windows) and had no problems. Your browser must support forms and in-line graphics. I use a few of the HTML extensions in Netscape to make things a little prettier and faster for users of that browser, but they appear, as designed, to cause no problems to other browsers which simply ignore them per the HTML spec.

How can I download images I create as GIF files?

Just click on the image (or the "IMAGE" placeholder if you have a text-only browser) to download it via FTP. Since images expire five minutes after they're created, be sure to download soon after the image appears.

Return to Earth viewer