Earth and Moon 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 an image of the requested view, then returns an HTML document which generates the image as an in-line Web request. 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.
Is source code available for the server program?
Of course. Look in the 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.
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 the server is busy with other work, everything will slow down.
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 from space. 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's 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 Web server. This image displays the whole globe in the Mollweide equal-area projection. I re-project the data in this image into the cylindrical 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 cylindrical 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 consist of three lines in the following format:
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.


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 just 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 Web and Windows tools such as Solar System Live, Your Sky, and the Earth and Sky screen savers for Windows.
Why do the images of the Moon lack detail around the terminator (day/night boundary)?
The Moon images are generated from an albedo database based on images returned by the Clementine lunar orbiter. Albedo measures the intrinsic reflectivity of the surface, so the entire map appears as if photographed with the Sun at the meridian, hence topographic features which are brought out by low Sun angles are absent from Moon Viewer's images. This issue is explored in more detail in a companion document.

Return to Earth and Moon Viewer

by John Walker