This is a work-in-progress, or perhaps work-in-purgatory might be apropos. The underlying algorithm is fairly accurate when the correct longitude and latitude is entered, but there is no easy way to get that with the DS being sans GPS.

This was an attempt to simply allow one to point at your location on a map, then the program calculates your long/lat for you. There were two problems with this approach, one, the calculation is a bit off, Los Angeles is somewhere in the Mojave desert, for example. This might be easily overcome, but the second problem is that the local time zone needs to be used, and this is very difficult to estimate from a map, especially near the time zone border. (Which is often "all over the map.") Even with a high resolution image, a single pixel can be miles from the correct time-zone location.

The attempted solution was to use a hidden, underlying color-coded chart of time zones. A better solution might be to simply ask the users what Greenwich offset they are located in, but that's not very elegant.

The ultimate solution might be to add a GPS module to the interface. At a certain point, it becomes easier to carry around an iPhone or other device instead of using the DS, but the ultimate goal was to have the DS automatically begin bracketing shots a few minutes before and after sunrise/set. This would have been cool.

The source code also has functionality to predict moonrise/set as well, this is currently untapped. After trying a half dozen various algorithms, Keith Peter Burnett's example code was found to be the most accurate.

If anyone wants to give it a go, the basic structure is here for a head-start.

Attentions are elsewhere. I'm very ADDish. I'm planning a Astro shoot of the North America Nebula using the OCC astro program, a GH2, an Astrotrac, and a Canon 1-400 lens. I think the best bet for this program might be to eliminate the map, which was befuddled by the many wacky time-zone borderlines (don't want to miss the shot by an hour?).