Questions are often asked about what sorts of new features might be added to Guide in the future. Some new features have already been added; you can click here to get updated Guide software and information about the new features.
The following list should give some idea as to things that are planned; some things that would indeed be good, but may not happen soon; and a few things that are wildly unlikely to happen. It is in no special order; when people suggest things, they are usually added to the list.
One warning, before you get your hopes up about these. The major restriction on all these will be time. Doing all of the things I want to do in Guide would take decades, by which time I would have thought of more things that I'd like to do that would take centuries, by which time I will probably be dead. In some cases, I have no real intention of doing the described task at all soon; I've added it, in part, to make sure I don't forget about it, or so that people will know it's at least been considered. Just printing this list consumes about 14 pages, which should give an idea as to the size of the backlog.
Still, I can guarantee that some of the more modest efforts described below will happen quite soon, and correspondingly upgraded software made available on this site. (In fact, many of them have happened, and have therefore been removed from this list.)
Dates will be used to indicate I've updated a subject.
You can already do some pretty nifty animations in Guide, to do such things as show the motion of a planet or asteroid over a given period of time, with the object remaining centered and stars drifting by in the background; or with the horizon "fixed", showing objects rising or setting over it; or with the stars fixed, and planets and asteroids drifting past as time goes by. And with the ability to create animation (.AVI) files, you can save and edit these.
However, you can't do more complicated activities, such as (say) slowly pan from one point in the sky to another, while the "camera" zooms in to a smaller field of view and the date/time changes. The ideal thing here would be to have the ability to define "key frames". Let's say, for example, that you wanted to make an animation starting with a wide field field of view looking just above the horizon, a bit before sunset, looking at the eastern horizon. (This is our initial location, "key frame 1".) Gradually, the sky darkens, and we see the full moon rise over the horizon. ("Key frame 2.") As twilight deepens, we zoom slowly in on the moon, until it consumes a substantial part of the field of view and we can see details on it ("key frame 3"). We hold this frame for a few seconds so the viewer can appreciate it fully, then simultaneously zoom out and pan over to a nearby constellation ("key frame 4").
In Guide, one ought to be able to do this by setting up each key frame, then going to "File... Save a Mark." You would then need to use a text editor, such as Notepad, to create a special file telling Guide how the animation between the four frames ought to go:
Wide view 0 120 Twilight begins 0 100 Full moon details 100 50 Orion view 150
The above file would tell Guide: "This animation starts out with the 'wide view' mark. Go smoothly to the 'twilight begins' mark, taking 120 frames to do so. Then go smoothly to the 'full moon' details mark, taking 100 frames to do so; when you get there, pause for 100 frames. Then go to the 'Orion view', taking fifty frames to do so. When you get there, hold that view for 150 frames."
Then you could tell Guide to create the AVI file, or to start showing you the animation at a given frame, and so on. You could edit the text file to insert additional frames. Overall, it ought to be an immensely powerful capability.
The idea for this began when I was asked about creating an animation for a TV show about TNOs. I envisioned something where one starts out with a viewpoint on the surface of the earth, and then appears to "rocket away" from the southern hemisphere. Earth would shrink in the field of view, and one would see the moon enter from one corner as we backed 'way out. When we got to the point where most of the inner solar system was visible, asteroids would be added, so you could see the appearance of the inner asteroid belt. We'd continue to recede from the earth and sun, seeing more of the asteroid belt, and perhaps the Trojans, then Jupiter and Saturn. As we receded further, the inner belt asteroids would be turned off and the TNOs would be turned on. Then the viewpoint would proceed to rotate: instead of viewing the solar system from directly below, we'd move to a viewpoint just below the ecliptic, so you could see the "doughnut" of TNOs (and the rest of the solar system) rotating before you. Finally, the viewpoint would come to a rest, and we'd start animating in time, so you could see the TNOs going around the sun.
(22 Oct 2002) Better ability to set arbitrary observing viewpoints:
At present, Guide's Location dialog makes it quite easy to set any viewpoint on earth, or other planets/sun/moon/natural satellites. It's also possible to set a viewpoint on an asteroid, comet, or artificial satellite/interstellar probe, and you can add an arbitrary offset to your viewpoint. Combine the two and you can, for example, tell Guide to show you a view from a point close to the Pioneer 11 probe, or a view from one of the five Earth-Moon Lagrangian points, or give a view of the solar system as seen from above, and so forth. However, none of this is especially straightforward, and none of it is documented (except quite informally, at the above links.)
There ought to be some decent way to specify such "unusual" locations. I can't say I've got this one very well puzzled out, but perhaps a floating dialog in which one can "back up"/"move forward", "move left/move right", "and "move up/move down" (i.e, move in steps of a desired size, in AU or kilometers) would be helpful. You also need to be able to specify if the offset rotates with the home planet (so that you always see the same face of the planet), or with the home planet's orbit around the sun (so that the angle between the home planet and sun stays constant, so that the home planet is always at the same phase), or if the offset stays fixed relative to the stars. This last is, at present, the only option; if you set an offset so that the home planet is occulting a given star, then the home planet stays between you and that star. It can (and usually will) appear to rotate relative to the star, and may go through a full set of phases.
All of this control seems, to me, to be necessary/highly desirable, and I'm holding off on implementing it until I come up with a non-user-abusive way of doing it (or see a good method in another program and decide to... ah... "borrow" that method.)
This one is quite low-priority, but I'm attempting to keep track of almost anything that might happen in Guide, rather than the things that are likely to happen.
If you use Guide's existing ability to offset your viewpoint and set an offset of, say, a million AU, you can see the universe as it would appear from a viewpoint about 16 AU from the earth. Stars will be properly shifted, with nearby stars nowhere near where they "normally" would be, more distant stars less affected, some stars closer and therefore brighter than they used to be, and so on.
At present, this is quite imperfect. The capability was "tacked on" to a program that treats stars as distant, 2-D objects. If you go so far that a given star is no longer sufficiently close to where it would be seen from Earth, Guide loses track of it and stops showing it. Still, it would be nice to take advantage of this "interstellar view" capability in a user-friendly manner.
Also, having read plenty of science fiction novels in which people accelerate toward a star, flip at the halfway point, and decelerate, I'd like to include the relativistic effects: time dilation, Doppler shift (stars get bluer in the forward direction and redden in the aft direction), and angular shift (stars tend to appear to bunch together in the forward direction). At present, Guide includes none of these effects. A time-lapse movie, in which you start out seeing a nearby star as it would appear from Earth, then watch as the stars start to contract around the target and turn bluer, then reverse the process (with the target star brightening as you approach), would look quite nifty.
: (22 Oct 2002) Some movie-making tools:
The recent addition of .AVI-making ability to Guide has made me think some more about how you specify the viewpoint in Guide. I'd like to be able to make the sort of movies places such as JPL do... ones where you see the viewpoint from, say, Voyager 2 in time-lapse form. During such movies, the view glides smoothly from one planet to the next, occasionally zooming in and/or out smoothly. In others, the sun might stay fixed at the center of the field of view, while the viewpoint zooms away from the sun to show the outer solar system, then goes around the solar system (basically, panning sideways.)
This would probably be handled using the key frames scheme described above.
(15 Oct 2002) Observation log/easy way to add notes for objects:
Quite a few astronomy programs now provide a means for adding your own observing notes. You might click on NGC XYZ, tell the program you wanted to add notes (or an image you'd taken of the object), and those notes would be added to your log. Later on, when you asked for info about that object, your notes would be shown.
I've mostly stayed away from adding such features to Guide. There are a few standalone observation logging programs out there, and from what their users tell me, they work pretty well. However, one thing I could do that might be somewhat helpful would be to take advantage of Guide's existing "user-added notes" capability (see page 66 of the Guide user manual for information about how to do this.) At present, to add notes for NGC XYZ, you need to edit the file ngc.not, find NGC XYZ in that file, and add/edit comments for it.
I may add in some sort of "Edit User Notes" menu option. Click on this, and Notepad (or the text editor of your choice) would pop up with the existing notes (if any) for that object. Edit them and save them, and Guide would revise ngc.not to have the updated comments. This would (a) make editing user notes simpler by a couple of steps and (b) make it more obvious that you can add your own notes at all (most Guide users, I'd wager, are unaware that the capability exists.)
Also important, in my humble opinion, is a means for exchanging user notes. It would be wonderful to click on NGC XYZ and see, not only the comments from assorted catalogs and perhaps my own notes, but also "Joe A. observed it with a 20-cm SCT and saw thus-and-such... Jane B. observed it with a 2-meter Newtonian and saw the following... Ed C. saw this with 7x50 binoculars..."
Right now, you can click on most objects in Guide, then on "Display", and get control over many aspects of how a dataset is shown (color, labelling, levels shown at, etc.) For at least some datasets, it would be convenient if a "symbol" button were provided. Click on this, and you would get a big dialog box showing the available symbols; select one, and Guide would switch to that symbol for the display of the given dataset. (A pretty large library of "common symbols" could be put together quite readily, though it would be possible for users to create their own, if they're willing to wade through the process of designing one's own symbols.) It would probably be convenient were these symbols to be resizable and, perhaps, rotatable.
This would then lead to use of symbols in overlays. Along with the current editing tools of "add text", "add lines", and "add circles", would be an "add symbols". You would choose the desired symbol, then click on the chart in the place(s) where symbols should go.
At present, user-added datasets, mark files, and the "miscellaneous" event table are "unclassified"; go to the 'Extras... Toggle User-added Datasets' option, for example, and you get a long list of every user-added dataset available to Guide (I'm currently getting 118 of them.) Some subdivision would be nice; example categories might be:
Atlas pages Photometric Galaxy Non-galactic DSO Star Binary star Radio sources Telescope calibration stars Other
...more or less. The exact nature of the categories isn't entirely clear, and probably won't be until the feature is used for a while; therefore, it will be necessary to make it quite flexible (so we can play around with it a little as the "logical" ordering emerges.)
Similarly, the 'mark' files have no organization whatsoever, and some people have a lot of them. One possible way to break them into manageable groups would be something like this:
'Full' Position-only Time-only Observer location only Datasets only Other
In this case, if you wanted to store a mark file that contained only the current RA/dec, you would use the 'position-only' category. I'd add some logic to Guide to let it know that, for a 'position-only' mark file, certain lines should be omitted from the mark file. Again, categories would be fluid, and it would be necessary to make them easily changed while we're figuring out a "good" way of doing it.
For the "miscellaneous" tables, reasonable groups might be:
Asteroid occultations Lunar occultations Transits and planetary occultations Other
(Right now, the "miscellaneous" tables are very heavy on lists of occultations. This may not always be so; when the time comes, it should be easy to add new categories.)
(2 Oct 2002) Better telescope control, including mechanical error correction:
Guide's current telescope control system arose from no coherent planning whatsoever, and I'm strongly inclined to rip it out and start over. Having done almost everything wrong in this area the first time, I now have a much better idea as to how to do it "right".
For users, there would be two practical benefits. First, the initial telescope setup would work much more smoothly, particularly for encoder-based systems. The current telescope alignment method is very error-prone. I envision one wherein you click on "Add Alignment Star", and a list of alignment stars currently above the horizon appears. (And planets, too; aligning on a planet is not only easy to do -- after all, planets are bright -- it gives you the chance to observe something interesting, as long as you've got the target centered.) Point your scope at an alignment star/planet, click on its name on-screen, and you're aligned on that object. Do it again, and you've got a two-star alignment.
Once this is done, Guide will know the difference between clockwise and counterclockwise on your scope, and subsequent alignments can be done, at least roughly, with one star.
Second, because all scopes would be treated as roughly similar objects, I could feed all of them through the mechanical error correction code. Thus, if you aligned on three or more stars, some of the scope mount errors would be removed. (I did a bit of work on this a few years ago, and developed a mathematical masterpiece and a user interface nightmare. I think this latter aspect can be fixed.)
Presently, you can click on an object in Guide from a viewpoint on the surface of the Earth and get times at which it will rise/set/transit and its altitude and azimuth. It would be nice, and probably not very tricky, to extend this to views from other planets. Some code would be needed to exclude ridiculous cases; for example, as seen from Tycho on the Moon, the Earth appears to move a little (due to librations), but never rises or sets or transits.
Right now, you can add images to Guide by using a function that is part of the Charon astrometry software. Other images can be added using Extras... DSS/RealSky Images... Add DSS Image..., but only if they are FITS images with WCS (World Coordinate System) header data. Fortunately, this covers a lot of images, especially those generated by professional astronomers. But one does get the occasional coordinate-less JPG image, or WCS-less FITS image.
For this occasional person who doesn't care about real accuracy but just wants to put the image on-screen and move it around until it "looks good", the CCD frame dialog is probably the way I'll wind up going. You could easily use this to get the image stretched out over the right amount of sky, then rotate it and shift it until you think it matches the star patterns pretty well.
The additions I'd have to make the user interface would be buttons in the CCD frame dialog. One would let the user say: "Bring up a file dialog, so I can select an image file to stretch over the CCD frame." The second button would say, "OK, I've got it positioned the way I want it now... so save it in this location."
It hasn't been a big priority, because most of the interest in doing such things came from people tracking asteroids, who needed to use Charon anyway. Lately, though, I've heard from a few people just pursuing 'pretty picture' CCD imaging. In such cases, a similarly 'pretty picture' method might be reasonable.
Guide supports all sorts of interesting tables, including some listing the stars in the currently-displayed area of sky. Some people have suggested that a way to get similar lists of variable stars, deep-sky objects, and so on would be pleasant.
At present, tables are added to Guide one by one, with custom code for each dataset. What's really needed is a "table generation routine" that can be generalized to handle almost any dataset, much as Guide's current "user-added dataset" lets you display almost any dataset.
I'm currently envisioning something like this. Suppose you wanted to make a list of quasars, or A2.0 stars, or variable stars. You would right-click on one of these objects. In addition to the current options such as "OK", "More Info", "Next", and "Display", there would be a "Make List" option.
Click on "Make List", and you would get a dialog box offering (at present) three controls. First would be a three-way selection: "full sky" (list objects from anywhere in the sky), "above horizon" (anything above the currently-visible horizon), or "on-screen" (only list objects in the current field of view). Second would be a magnitude limit control. (For some magnitude-less datasets, this option would be grayed out, just as it sometimes is in the "Display" dialog.) The third would give a list of items that could appear in the table (a set of checkboxes, sort of like the one currently available in "make an ephemeris"). For every dataset, RA/dec and/or alt/az could be shown; for almost all, a magnitude and/or object name could be shown. After that, the available columns in the table would vary depending on the dataset in question.
Set these controls and click "OK", and Guide would generate and display a list. You could then click on an entry in the list to recenter on that object, or print the list, or save it to a file (much as you can Guide's existing tables).
One possible way to do this would involve some extensions to the user-added dataset capabilities, which at present provide ways to specify what data gets shown when you click on an object, and what data gets shown when you ask for 'more info' about an object. In theory, extending this to include "showing what information is shown about an object when you make a table of that class of object" ought to be reasonably straightforward... it would just take time to implement it.
By default, the lists would include RA/dec (in the currently-selected format), alt/az, magnitude (if available), and object name. (Certain values computed from these, such as rise/set/transit times, alt/az, and ecliptic/galactic coordinates, might also be uniformly available.) A suitably energetic person could tell Guide that a whole slew of items should be listed, by adding lines to the .TDF file to tell which columns should be used. Something like this:
~t 1 15 t1l Object name ~t 16 10 t1 Alternative name ~t 26 5 #1 V magnitude ~t 31 5 #0 B-V ~t 36 10 R1 RA ~t 46 10 d1 declination ~t100 6 #0 PM in RA ~t106 6 #0 PM in dec ~t143 10 #0 Galactic longitude ~t153 10 #0 Galactic latitude
("~t" indicates that a table entry is about to be described; it's followed by the starting column and number of bytes used by that entry on each line. Next, you tell Guide if the entry is (t)ext, or an (R)A, or a (d)eclination, or just a number (#), so it knows how to sort that entry. Next, in column 12, comes a byte indicating which entries are to appear in the table; at present, the table would give the object name, alternative name, V magnitude, and RA/dec for each entry. In the above example, the "object name" gets an "l" in column 13, indicating that the objects are to be labelled on-screen by object name. Only one line can get an "l". Finally, the entry name is specified.)
The user would get the above list of possible entries, and could toggle them on/off ("I just want a list of the objects by name and magnitude", "I wanna see everything", etc.) You could also select one item on which to sort ("show the list in order of RA"), and/or one item to use in labelling ("by default, these guys are labelled by object name, but I'd prefer to label them by B-V, or by their alternative name.") It might be possible to use multiple labels ("show both object name _and_ magnitude").
Eric Broens has suggested that it would be helpful if one could also add one's own fields, based on one's own entries. A "note" field leapt to mind, but it could be other things as well.
The text vs. number vs. RA/dec flag would help in another possible improvement: in addition to magnitude and "above horizon" and similar constraints, it would be nice if one could add such almost arbitrary constraints such as (say, for variable stars)
per > 100 & magRange > 3 & dec > -15
The above query would restrict the table to include objects with periods greater than 100 days, with a range of at least three magnitudes, and which happen to be north of dec -15.
By the way, you might immediately think that this wouldn't help with 'built-in' datasets such as the asteroids and deep-sky objects shown by Guide. Oddly enough, though, this is not the case. Most of the built-in datasets get handled much as if they were user-added datasets (at least as far as the 'clicked-on' data and 'more info' data are concerned). If you look in ECANNED.DAT, you'll see much of the text that appears for built-in datasets.
At present, Guide does no real numerical integration of the orbits of asteroids and comets. For asteroids, this is sidestepped by providing orbital elements at a variety of epochs, covering a time span from 5 Jan 1941 to 8 Aug 2022. For dates close to the present, the elements used for asteroids are never more than 100 days out of date. In most cases, you can ignore the error inflicted by ignoring 100 days of perturbations, but it can cause trouble if the object does a close approach to a planet during that time. And people with high-precision applications (asteroid occultations, for example) are going to find trouble with ignoring perturbations, even for main-belt objects.
For comets, orbital elements are given for each apparition. For example, Guide has elements for P/Halley for the 1910, 1986, and 2061 apparition (plus many others). When displaying P/Halley, Guide uses the "closest" set of elements. Again, this is usually more than sufficient. For both comets and asteroids, this ensures good accuracy and speed (numerical integration tends to be slow).
Some recent changes in Guide have me thinking of two different solutions for numerically integrating objects. One is a program to integrate MPCORB.DAT to a desired epoch. A lot of people have already replaced Guide's "built-in" elements with those from MPCORB (click here for information about what MPCORB is). The file gives the elements in one, passably "current" epoch. Using the new program, you can integrate the entire file to a desired date, then use it in Guide.
But this can be slow (it takes a while to integrate that many asteroids, especially if you want to go back a few decades or centuries), and only asteroids are handled. This is where the second approach would be useful: you would right-click on an object (asteroid, comet, or spacecraft), go through "Options", then click on an "integrated object" button. Guide would then know that the object in question should be computed using numerical integration, rather than with the default two-body approach.
Put together, I think these two options would cover most numerical integration needs.
At present, Find_Orb has some rather nice (in my opinion) code for handling numerical integration. It's a little "embedded" into Find_Orb, but my plan would be to make it possible to separate it into a library that could be used by Find_Orb, Guide, and possibly Integrat.
It might be nice to junk the current 'data shown' dialog box in Windows, for something similar to the approach used in the DOS software. You would just have a long list of data types; click on one, and all the various options applying to that dataset would appear, plus some new ones:
--- Globular clusters --- ( ) On [x] Show labels [ Font ] ( ) Off [ color ] (*) Auto Mag limit: [10.9] ( ) Fixed Show at fields of view from [ .1] degree to [ 10] degrees [ OK ] [ Cancel ]
The 'on', 'off', and 'auto' options are similar to those in the current Data Shown dialog, as are the check-box for 'show labels', the button showing the color to be used and the edit box for setting the magnitude limit when 'auto' is specified. As before, the magnitude limit control would be grayed out if you selected 'on' or 'off'.
The new 'fixed' option is described here. New options have been added so you can specify a range of levels at which the given category of data is to be shown, and possibly a way to select the font to be used.
For certain types of data, more options would appear. For galaxy clusters, for example, you would have three radio buttons to select "Abell", "Zwicky", or "Abell + Zwicky" (same options currently in the Data Shown dialog). Asteroids would include the labelling options and control over the line of variation; planets, buttons to control 'full vs. normal precision'; and so on.
Furthermore (and here is where things really get interesting), the list of data types can be extended to include the user-added datasets and overlays. You could control them in almost exactly the same manner you currently control things in 'data shown'. By doing this:
Guide uses its own system right now to display "more info" about objects, glossary and help data, tables generated using the various options in the Tables Menu, and Quick Info. Some people have requested a switch to a Windows-style "help" system. This has two shortcomings. First, Windows doesn't allow you to dynamically alter help from within a program... and Guide has to create a new 'help' item every time you ask for More Info or generate a table. Secondly, Guide often has "help" links that tell it to do things such as "set the date to thus-and-such and center on object thus-and-such." HTML is ignorant of Guide's requirements in this department. So I expect Guide to continue to use its own help system.
At present, if you set a given class of data (for example, asteroids) to display down to a given magnitude, that limiting magnitude varies as you zoom in or out. The purpose is to avoid crowding; it's reasonable to display (for example) asteroids down to magnitude 19 in a 1/2 degree field of view, but using the same limit in a 20-degree field can lead to a chaotic mass of asteroids.
Still, some people have asked for a way to do such things. In addition to the current three options of "off", "on", or "auto", they would like to have a "fixed" (mag) column in the Data Shown dialog. My guess is that most people will then try this option and decide that the "auto" system makes a great deal of sense after all.
Eric-Sven Vesting has mentioned that it would be nice to be able to create a table of rise/set times for the Sun, similar to that available for the Moon with the "Lunar Data" option in the Tables menu.
Extending this idea a bit, it would be nice to be able to click on any object, including the sun or moon, and get a table of rise/set times. If the object were the moon, the other lunar data such as librations would also be shown in the table. For the Sun, twilight times might be added. For stars, planets, asteroids, and comets, just the rise/set data would appear.
This function exists now for artificial satellites. For these, some extra data is given, such as maximum altitude and brightness reached, in shadow/out of shadow times, azimuths of rise and set, and so on.
At present, planets, asteroids, and satellites are shown as symbols of various kinds. Several people have mentioned that, since they show up to the eye as starlike points, it would be nice to be able to display them as starlike points of correct magnitude.
This is usually suggested in reference to the Galilean satellites, but there are other cases where it would be a nice option to have.
The ability to set your "viewpoint" to be from the surface of another planet means that a few other functions should to be supported for such views, too. In the past, when all extraterrestrial views were from the center of the planet, the following didn't matter:
Guide currently uses a single-document interface, with one chart available all the time. Some people have suggested that, in some situations, having several charts available might be convenient. (In fact, the original Windows version of Guide started out with multiple documents; this was deliberately rejected partway through, because it seemed to add more trouble than help. But the time may come to revisit this decision.)
At present, the overlay capability in Guide is extremely powerful and flexible. It's also quite clumsy; people report that they take some time before getting the hang of its oddities, and find themselves wishing that they could (for example) click on a piece of overlay text and drag it to a new position, or put rectangles, or edit the text.
At present, Guide shows bitmapped details on the following solar system objects: the Moon, Sun, Earth, Mars, Jupiter, Saturn, Pluto, Io, Europa, Ganymede, Callisto, and Japetus. (Plus a few others; for some smaller objects -- Phobos, Deimos, Amalthea, others -- the shape is also rendered correctly.) The bitmapped details are currently stored in a Guide-specific .qwe format. (Information about this format is given in the file /compress/qwe_fmt.txt of the Guide 8 and 9 disks.)
I have a little program that I use to read in a map in cylindrical equidistant projection, such as those on Steve Albers' planet maps page, and write it out in .qwe form. It has a truly horrendous user interface, though, so I've not posted it yet; when someone asks for a particular planet map, I've just done the conversion and sent the resulting .qwe to them and/or posted it on my Web site. I try to avoid posting my "user abusive" software; it results in too many tech support calls. It's usually easier, quicker, and less embarrassing for me to just get the code to work in a user-friendly fashion once, instead of explaining a dozen times why I wrote a horrible piece of software.
This one has been suggested several times; somehow, though, I failed to post it until now. At present, Guide's handling of double stars is not all that wonderful. You can "go to" a double star, such as Struve 2498; but unless it exists in another catalog, such as the Tycho/Hipparcos or GSC, you won't actually see the star. And even if it does show up from one of these two catalogs, you won't see it labelled as "Struve 2498", nor will you see a little line indicating the position angle of the companion star. The best you can hope for is that, in "More Info", there will be a link to data from the WDS (Washington Double Star) catalog.
Ideally, there would be a "Double Star" entry in the Data Shown menu, so that you could control their display and labelling as with any other object. If you were zoomed out too far, you would see a single star with a line indicating the correct position angle. Closer in, you would see two distinct stars at the component magnitudes. And, while we speak of "ideals", orbiting binaries should be shown at the correct separation and position angle for the current date.
One major obstacle to this is cross-indexing catalogs well enough so that, when the "double star" version of a pair is shown, the individual star(s) from the other catalogs are properly suppressed. This will be a serious hurdle, since there is rarely any information available that is suited to making such a cross-index. A second, smaller hurdle has to do with how such objects are filtered. The visibility of most objects depends essentially on magnitude; that for a double depends on two magnitudes and their separation.
This idea has been suggested by Doug Askew and Michel Collart. Right now, Guide has the "Aperture Circle" to show a circle of a desired angular size. This is commonly used to show the actual field of view of an eyepiece. But computing that field of view requires you to do some math.
For example, suppose you have a 30-cm (10 inch) f/6 telescope, and will be using a 25 mm eyepiece with a 50 degree apparent field of view. You have to do the following math:
focal length = 30cm * 6 = 180 cm = 1800 mm
magnification = (1800 mm / 25 mm) = 72
actual field of view = apparent field of view / magnification
= (50 degrees / 72)
= .69444 degrees = 41.67 arcminutes
This gives the diameter of the actual field of view. You then have to divide by two to get a radius, go to Guide's Measurement Markings dialog box, and tell Guide to show an aperture circle of radius 20.83 arcminutes.
This is a fair bit of math, and one could logically ask Guide to maintain a list of your eyepieces and telescopes, like this:
[ ]--- Aperture -------------------------------[_][X] | _ _ | | 25-mm Plossl |*| 20-cm f/8 SCT | | | | 10-mm TeleVue | | 3.5" Meade ETX | | | | 7-mm Brand X | | 200" f/5 Newt |*| | | 3-mm Tasco |_| 50mm f/4 finder|_| | | | | [ Add eyepiece...] [ Add scope...] | | [ Edit eyepiece...] [ Edit scope...] | | [ Delete eyepiece] [ Delete scope] | | | | [ Color ] [ OK ] [ Cancel ] | | | -----------------------------------------------------
You would select an eyepiece and a scope, and Guide would do the math. If you wanted to add an eyepiece, you would have to give its name, focal length, and apparent field of view. For a scope, you would have to give it a name, aperture, and f/ratio.
At present, the legend is always drawn in one corner of the chart. Some programs produce charts with the legend in a separate part of the page; for example, in portrait mode, the chart may consume an 8-inch square at the top, with the legend totally separated in a strip at the bottom of the page. I would not wish to eliminate the current system used by Guide. But some people would at least like to have the option of having the legend and chart separated.
A possible extension to this: I'm considering a system in which there would be a set of "page layout files" for printing. For example, the "Millennium Atlas clone" layout file would say: "Print in portrait mode, with the chart indented thus-many inches from top, bottom, and sides. Put RA/dec labels around the outside of the chart (see next section for details on this). Suppress Guide's usual legend, which changes from chart to chart; instead, _always_ put the following text and symbols at the bottom of the chart."
Bob Leitner has occasionally mentioned that he would like to have, in addition to the standard "add line", "add text", and "add circle" features in the overlays menu, an "add star" option. This does seem like a reasonable request... the overlay format already supports star display (see the AAVSO charts for an example), but the necessary user interface code isn't in Guide (yet).
Grant Christie has suggested that one should be able to get info on an object by just typing in a name, or running through a "Go To"-like menu. At present, to get "more info" on (say) XY Psc, you click "Go To... Star... Variable..." (or "Go To... Object Name"), type "XY Psc", wait for a chart to be redrawn showing that star, click on it, get a brief summary, and then ask for "more info".
It would be more convenient to instead click on a new "Get Info" option, type "XY Psc", and wait for the "more info" to be shown.
Right now, Guide can show the current Uranometria, Millennium, or Sky Atlas 2000 page in the legend area. It can also show the layout of several additional atlases (Falkenberg, AAVSO, etc.) as "user-added datasets".
It would be nice if one could tell Guide to show the current page for an arbitrary atlas. One would provide a list in a text file ("page 1 is centered on this RA/dec and is so many degrees on a side; page 2 is...") Atlases could then be "user-added", just as datasets are. Furthermore, digital surveys such as DSS and RealSky are nothing more than a collection of rectangular areas, so they fall into the same scheme. As the cursor moved around the screen, you could get the current Palomar plate, possibly with some information about it ("plate taken on this date, with this exposure, in this filter, and the data is found on RealSky CD n1 and DSS CD n2.")
As time goes by, this becomes less and less useful for paper atlases (which see little use), and more and more useful for lists of CCD or photographic plate coverages. Quite a few coverage lists are already available.
This feature now works, but it is not quite perfect yet. Here are some of the things that will need to be added.
This option would work as follows. Suppose you had just gathered an image of asteroid 1997 RA. You would select "Go To... Asteroid..." and enter 1997 RA, and it would appear centered on the screen, as per usual. But you would then click on a "Match Image" menu option in Guide. A file dialog would appear, and you would select the image file of 1997 RA.
At this point, Charon would take over and would match the image to GSC stars, putting a cross-hair on 1997 RA, much as it does now (but minus the need to handle command-line options and so forth). You could confirm that it found the target and create an MPC or IOTA observation report. You could also tell Guide that you want this image to be shown in the background of Guide charts, much as the RealSky images are.
If you did so, and then exited Charon, control would return to Guide and it would redraw the chart with your image on it.
This option is not far away at all. In fact, the ability to use the data found by Charon to display an image in Guide already exists. Click here for details.
While Guide shows artificial satellites, there are still some features that would be very useful. In no particular order:
There are three problems with this. First, you can't take an orbit fitted to the SGP4/SDP4 models and use it in a more accurate orbit propagator; you really need to take the original observations and derive a new orbit using the same theory you're using for "accurate" propagation. Fortunately, Find_Orb can basically do this, so you could feed it observed data, get good data, and feed it to the new propagator. But observed data is rare; almost all Web sites provide TLEs instead, generated from SGP4/SDP4. A wonderful propagator is useless without raw data.
Secondly, it would be considerably slower. To get a satellite position, Guide would really have to numerically integrate the object; SGP4/SDP4 was designed for use on 1980s-vintage computers, and requires much less math.
Third, I would probably find my tax returns audited forever. And it is hard to fault the US Government for not wanting such code released.
Guide currently can switch readily between English, French, German, Spanish, Italian, Japanese, Dutch, and Russian. Each translation was done by native speakers of the language who are also astronomers; both are real necessities for this sort of demanding task.
I have left in provisions for plenty of additional languages. (Look at STRINGS.DAT, lines 1314-1323 and 1482-1487.) If such versions are created, I will automatically update users in those countries by sending them a floppy with the necessary files.
If you've an interest in further languages, there are some details on how to add new languages and some information about languages already supported by Guide on this site. Note that you can add a language to Guide "as is", without needing to modify the software! Only a text editor is required.
The current contrast/brightness adjustment in Guide is a little tough to puzzle out. Something a little less user-abusive (and possibly adding some greater control, such as a choice of linear, logarithmic, and histogram-equalization contrast) would be nice.
Also, it would be nice (in some cases) to have overview images. Right now, when you zoom out, Guide shows pixels selected almost randomly from the image. If it instead created an overview image, containing (say) 1/4 the pixels, with those selected as the median pixels in each 2x2 block, you would get a smoother appearance. Done properly, this would even speed up the display a little.
Finally, there should be some decent control over the palette, so that pseudocolor can be used.
Other features that might be good: a way to change the Gamma value (and set different values for screen and printouts); a photometry tool; the ability to have several "sets" of images, so you can say, "toggle on my set of Messier images".
Some simple image processing routines (low and high pass filters and median filters, for example) might be handy to have. Suitable use of filters could let you create an image retaining nebulae, but dropping out the stars, or vice versa.
There are several ways in which Guide could access and display color images. For example: Guide can now access DSS-2 images, which come in red and blue flavors. You can now see red and blue DSS images combined to make a color image.
Some people do three-color imaging with a CCD and filter wheel; in such cases, it ought to be possible to run all three through Charon, specifying "this is red; this is green; this is blue", so that Guide will combine them properly.
Also, you can frequently download color .JPEG and .GIF images of astronomical targets, or create them with digital cameras. These don't usually work with Charon very well, so automated alignment is unlikely. I envision, instead, rigging up the CCD Frame dialog box so that it can be used to specify the image dimensions. You could then tell Guide: "Stretch this image, M57.JPG, across the CCD frame." You would then have to rotate, shift, and scale the image by hand and eye, aligning it to the stars using mouse and keyboard controls, until you got it into place. You could then tell Guide, "OK, that's the right place", and move on to the next image.
(Update: Having tried this, I'm extremely disappointed with it; trying to get an image to line up by pushing it and turning it is extremely frustrating. This may not have been such a great idea. I've not rejected it completely; there are a lot of nice color images out there, and I'd really like to have some way to incorporate them into Guide.)
At some point, it would be nice if Guide could be transferred to such gadgets. At one point, the main issue in this was size. Guide 8 consumed 1.3 GBytes; Guide 9 consumes about four GBytes. However, that's increasingly an annoyance rather than a real obstacle.
Nowadays, the main problem is that Guide is very desktop oriented, assuming a big screen, mouse, and keyboard. A lot of re-design will be required before it can make the leap to a small screen and touch-based interface. (Plus a bit of learning on my end; I've never had occasion to work on development for such devices before.)
I essentially consider this to be a solved problem now, with Guide running nicely under Wine (Windows Is Not Emulated). I've become a big Linux fan, and currently prefer running Guide on that OS.
The biggest issue people raise with Wine is that not every Windows program works with it, and this is certainly true. In fact, I had to make certain changes to Guide before it would run properly in Wine. However, now that I've made those changes, Guide runs well in Linux and OS/X.