If I remember correctly, sphere.exe raytraces 1 pixel for each 16x16 box of the screen, saves off the (x,y,z) coordinates hit, and then in a later stage, interpolates (all 3 axes) to fill in the box. The interesting part is how I map this (x,y,z) directly to a 2D texture. It was more of a research concept than anything useful. There are many better ways to do texture-mapping on a sphere.
.. explain the basic method by which your globe.exe program works ..
You are correct in that I don't use an inflexible triangle-only rendering API such as OpenGL. I wrote my own rendering code for Globe. Your ideas are interesting, but they all seem to avoid writing your own polygon rasterizer. Anyway, I'll explain my algorithm:
It works a lot like a polygon scanline filler. First, I transform each line segment of shoreline to camera coordinates. Still in 3D, I clip it to the front half of the camera space. Then I project the vertices to 2D. I finish clipping to the 4 edges of the screen in 2D coordinates. At this point, I do something similar to a Bresenham line algorithm - although in this case, I only care about 1 pixel per scanline. I calculate these x-coordinates and save them to a list. Each scanline can hold up to 512 crossings. (512 is some arbitrary I chose - it never seems to get close to exceeding it.)
I calculate the boundary of the Earth's sphere separately. For each scanline, I calculate the left and right sides of the sphere - there are 0, 1, or 2 intersections. I solve a quadratic equation for each scanline. I hold these left and right points in another table.
Now, I have all the info I need to render the screen. I visit the pixels in consecutive order (top->bottom, left->right), only rendering sections inside the earth's disc. For each scanline, I sort its crossings. As I plot the pixels, I swap the color green<->blue whenever I pass one of these crossings.
I use a trick for hidden surface removal. Press 'Caps Lock' inside Globe and you'll see a bunch of circles. These regions act like bounding boxes - except they are circles. Using some math, I can quickly check whether any part of these circles are visible from your view. If it is not, then I skip all line segments inside it. This speedup is very helpful for the high resolution shorelines when you are on the surface of the earth.
One thing I did not discuss is how I determine the starting color for the first scanline, and also the starting color at the left of each scanline. In fact, I haven't found a perfect solution to it. (Perhaps you've noticed blue and green swapping occasionally) Currently, what I have is an ugly hack that works most of the time. Transparent mode (press 'T') has no such issues, but it runs a lot slower because it can't take advantage of the bounding circles trick.
.. not a one-for-one mapping of the 2D euclidean bitmap to the
I assume you mean Mercator projection? If so, that's not hard to render. In fact, I have a demo of it inside EVALDRAW.ZIP (http://advsys.net/ken/download.htm#evaldraw). Look at: "DEMOS\GLEARTH.KC"
.. interface it with a GPS device ..
Have you looked into Google Earth? It's much higher quality than my old globe program. I know it supports some GPS devices. The problem, I guess, is how you give it an internet connection when you're on the road.