Future extensions to Guide, possible and unlikely
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.
(17 Nov 2003) An "undo" capability:
This one is straightforward enough: there ought to be a way to undo most, if not all, actions in Guide, backing up many levels. The closest thing to this right now is the use of File... Load a Mark to restore one's "initial settings" (the way Guide was set up when you started the current session) or "factory defaults" (the way it was right after you installed it.) But more flexibility would be nice ("I just want to undo the latest Bad Thing that I did, or something I did three steps ago.")
(17 Nov 2003) A way to do more complicated animations:
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.)
: (22 Oct 2002) Viewpoints from other stars/interstellar space/relativistic speeds:
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.)
One probable means of doing this would be the same as in other movie-making programs: the user would have to specify "key frames". For example: you might set up Guide to show Jupiter in a wide field of view, and save it as your first key frame. Then make a second at a narrow field of view (one in which satellites are shown), but otherwise unchanged. Then make a third showing Jupiter a few weeks later, same field of view; and a fourth, another few weeks later, recentered on (say) Io and zoomed in to show that satellite to advantage.
You would then have to tell Guide how many frames to insert between each pair of key frames. The resulting movie would start showing Jupiter in context with the naked-eye sky, then slowly zoom in so you could see Jupiter as a disk with satellites. Then the satellites would start zipping around Jupiter. (If the date/time were shown in the legend, the dates flipping by would give the user a feel for the passage of time.) Finally, you'd get a slow zoom-in, with the field of view gradually drifting from Jupiter and recentering on Io.
(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..."
(8 Oct 2002) User-settable symbols/symbols in overlays:
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.
(4 Oct 2002) Hierarchical arrangement of user-added datasets, mark files, and event tables:
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 three practical benefits. 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.)
Third, doing this would pave the way for adding new types of
telescopes. In particular, I'd like to add support for
ASCOM telescope drivers .
(19 Sep 2002) Use ASCOM telescope drivers: I have a strong interest in junking Guide's current telescope control
system in favor of using ASCOM drivers. At present, each new flavor of
telescope requires me to write (and, worse, test and debug) code to
control that sort of telescope. With ASCOM drivers, I'd be shielded from this: Guide would send
a command such as, "Slew here", and the driver would handle the problem
of converting that to scope-specific commands. This is highly analogous
to the way printer and video drivers work: you're shielded from the
details of how the thousands of various pieces of hardware work. The major problem I've encountered (and the reason I didn't rip
out my current scope control code and replace it with ASCOM-based code
a year or two ago) is that handling COM from C/C++ is astonishingly
opaque. I saw assorted "how to use ASCOM" examples, written in
scripting languages such as Visual Basic, and thought this would be
easy to do. I've found examples in C/C++, but they are incredibly
weird; I'm reluctant to rely on such solutions for a crucial part
of my software. Incidentally, if I did this, I still wouldn't hurry to remove
the existing telescope control code. Thus, one could control the
telescope "directly", using Guide's built-in code; or one could
choose an ASCOM driver. ASCOM does seem to be a bit tech-support
intensive, and I'd like to be able to tell people running into trouble
with it that the old control system is still available.
(14 Dec 2001) Show some asteroids, natural and artificial satellites,
and horizon objects as true 3-D shapes: In theory, it wouldn't be too difficult to get Guide to show
objects as 3-D polyhedra (or collections of polyhedra). I'd
normally consider this "fluff" not especially useful to a program such
as Guide, but if I did it at all, it could rapidly be extended to
provide several capabilities. First, I have "shape" data for some asteroids and natural satellites.
With a "show polyhedron" capability, I could show (for example) Eros
or Phobos or similar objects in their true, irregular shapes, at their
correct orientations. For objects where no shape is known (most of them,
I admit), I could at least show a plausibly shaped object (rounder for
larger objects, lumpier for smaller ones.) Second, artificial satellites and interplanetary probes could be
shown as "objects". Zoom in enough on ISS, and you'd see the solar
panels; set your viewpoint to be just behind Galileo or Cassini, and
you would see those objects. (And Guide 8 allows you to do that.) Third, "horizon objects" are currently defined to be somewhat
cartoonish 2-D shapes. It would be straightforward to generalize this
to 3-D, which would allow for considerably greater flexibility in
that feature. Fourth (and perhaps most importantly), planets could easily be
drawn with this technique (with the "planets" considered to be faceted
spheres/geodesic domes.) This would probably be faster than the
current technique, would simplify the code a bit, and would
allow Guide to show objects with proper perspective when you're
close to them. At present, Guide always shows planets as if you
were infinitely far away; this lack of perspective looks very
bad when you're on a satellite close to its primary. If I added
rendering of this sort, you could get a "correct" view of what the
folks in the International Space Station are seeing out the window
right now, and so forth.
(14 Dec 2001) Show rise/set/transit times and alt/az values from
viewpoints other than the earth: 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. (8 Jan 2000) Adding background images without using
Charon Right now, you can add images to Guide by using
a function that
is part of the Charon astrometry software. Some people are not very
enthusiastic about doing this, especially if they have only a very few
images and don't need the high precision required for asteroid astrometry.
The usual case is somebody who has imaged a few deep-sky objects and
wants to add them to the background of Guide charts. 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.
(8 Jan 2000, updated 23 April 2003) Getting tables of objects
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.
(28 Nov 1999) Numerically integrated objects
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.
Incidentally, it's possible that this would provide a means of handling the swarms of recently-discovered irregular satellites of outer planets. These are currently handled with precomputed, numerically integrated ephemerides; Guide interpolates within these ephemerides. Originally, I was pleased to add J-6 to J-12, and S-9 (Phoebe), and N-2 (Nereid) to Guide, using ephemerides kindly provided by Russ Shuart.
(14 Jan 1999) Reorganize 'data shown' and some similar menu options
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:
(4 Jan 1999) Add a 'time format' selection
The RA/dec format dialog started out with controls to specify only that format: you could select units used, the compass signs, and so on. Now, it also includes controls over the format for lat/lon and for English vs. metric units.
There is no similar control over the format used for expressing dates/times. Controls such as the following, either as part of the RA/dec format dialog or in a dialog of their own, would be nice:
( ) DD MM YYYY [ ] Months as numbers
( ) MM DD YYYY [ ] Two-digit years
(X) YYYY MM DD [x] Leading zeroes
( ) YYYY DD MM Date separator: /
Time separator: :
Calendar:
Show to a precision of [ 2] digits (X) Gregorian
Of: (X) Seconds ( ) Julian
( ) Minutes ( ) Hebrew
( ) Hours ( ) Islamic
( ) Days ( ) French Republican
( ) Years ( ) Chinese
( ) JD
( ) MJD
Example: 1999/Jan/05 10:24:57.91
Persons checking out MPC observations might well want to show dates/times in decimal days, to six-place (a millionth of a day, or about a twelfth of a second) precision. A few sources provide dates in decimal years, and decimal hours are seen on occasion. Artificial satellite folk are accustomed to MJD ("Modified Julian Day", or JD - 2400000.5, to reduce the field size and to put ".0" at midnight instead of noon).
Showing months with numbers (i.e., the above example would be 1999/01/05 10:24:57.91) has the advantage of allowing easy sorting, at least if the YY/MM/DD format is selected. A few people might want to select the "two-digit years" checkbox, so that (for example) "1948" would be shown as "48".
Displaying dates in odd calendars is a less justifiable decision, and I'm not entirely serious about that part of the dialog.
Persons who are gung-ho about changing the date format, and don't wish to wait for me to get around to adding a dialog box to do it, can do so by editing the STARTUP.MAR file. To learn about this, read this file, particularly the comments here.
(14 Dec 1998) HTML-based 'help', 'more info', 'glossary'
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, the Windows-style help is useless for the DOS software.
However, an HTML-based 'help' system would have several advantages. Windows Guide could create the actual HTML text, then leave display, printing, etc. to your Web browser. It would be easier to add images and different fonts and colors to HTML, and a wide variety of tools exists for editing HTML. The major downside is that support in DOS would be limited to nonexistent. This may not be a show-stopper, though; DOS could at least understand a subset of HTML without too much trouble.
(14 Dec 1998) Fixed magnitude limits
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.
(14 Dec 1998) Star display: include parallax, better colors, choice of B or V mags...
In Guide 6.0, the Tycho/Hipparcos star catalogs were used with display data consisting of only the position, proper motion, visual magnitude, designations, and a few other details. Other data was stored separately, and only accessed when you clicked on a star for "more info".
But when Guide 7.0 draws a star on the screen, it also knows its parallax and VT and BT ("visual Tycho" and "blue Tycho") magnitudes. So it could do several interesting things in displaying stars that were not possible in Guide 6.0. It could correct star display for the effects of parallax; this could let you do things such as view the stars as seen from Tau Ceti, say... or tell Guide, "Set a velocity of 10000 times the speed of light" and an animation step size of 1 day, and watch stars drift by in a realistic manner (excluding the fact that such a speed is physically meaningless, of course!)
For more meaningful animation, one could set a speed close to that of the speed of light, and see relativistic effects such as star colors shifting to blue in the forward direction and red in the rear direction, as well as the distortion effects (stars crowding in the "forward" direction). (The physics behind all this is fairly straightforward.)
The ready access to BT and VT data means that Guide could use this data (instead of spectral type data) for coloring stars. This would be more accurate than the use of spectral types; it would also allow about 1 million stars to be colored (all those with BT and VT data) instead of only about 400,000 (all those with spectral type data). Also, it makes it possible to add a switch between the use of visual or blue magnitudes for star sizes; and it may prove possible to compute other magnitudes, such as red and/or CCD, with passable accuracy.
(14 Dec 1998) Tables of rise/set times
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 artificial satellites, some data would be given after "rises/sets" such as maximum altitude and brightness reached, in shadow/out of shadow times, azimuths of rise and set, and so on. For stars, planets, asteroids, and comets, just the rise/set data would appear.
(14 Dec 1998) Display of planets, asteroids, satellites as starlike objects
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.
(5 Apr 1998) Improvements needed for views from other planets
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:
(26 Jan 1998) Multiple Document Interface
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.)
(26 Jan 1998) More Windows-like overlays, with more capabilities
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.
(26 Jan 1998) A way to import your own planetary surface feature maps into Guide
At present, Guide shows bitmapped details on the following solar system objects: the Moon, Earth, Mars, Jupiter, Saturn, Pluto, Io, Europa, Ganymede, Callisto, and Japetus. These are currently stored in a Guide-specific .QWE format.
Guide does have rotation data for all the planets and their satellites; one could put, for example, sunspots on the Sun, or have "cloudy" and "clear" versions of the Earth when viewed from other planets. (A few "alternative" maps are already on the Guide 6.0 and 7.0 CDs, awaiting a suitable interface for switching to them.) In the general case, though, some sort of .QWE converter will be needed that can read an image (a cylindrical projection of an object surface) and crunch it down to the necessary format. (I currently have one that reads in .GIF files, but it's a real pain to use. 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.)
(26 Jan 1998) Better handling of double stars
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.
(23 Jan 1998) "Eyepiece" method of specifying a field of view
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.
(15 Oct 1997) Automatic updating of assorted things via Internet
In theory, Windows Guide could have an option that would make use of your Internet connection to visit certain sites and: update your satellite orbital elements; grab the latest MPC asteroid/comet data; update the longitude shown for the Great Red Spot; correct your PC clock to within a fraction of a second; and check to see if there is updated Guide software on this Web site ("you're running the 10 Oct version; did you know that a 15 Oct version exists?")
This becomes especially important with artificial satellites. Even a few seconds of error can be annoying in tracking these objects. The orbital elements can degrade quite rapidly (sometimes in mere days). Being able to correct your clock and get new orbits in one step would be very useful indeed.
It so happens that, under 32-bit Windows, there are some nifty capabilities available that would let Guide grab such files with minimal code. I'm looking into this. The only bad part is that it would be usable in 32-bit Windows Guide only.
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."
Ability to add stars to an overlay
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).
Get "more info" without clicking on anything
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...", 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 "Get Info... Star... Variable...", type "XY Psc", and wait for the "more info" to be shown.
(Updated 5 October 2002) Plate/RealSky and/or atlas page data in the legend
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.")
This idea actually dates back to my first receipt of Glen Deen's Micro-Sky product, sometime around 1995. This consisted of a few dozen sheets of microfilm containing the complete Palomar Sky Survey.
It seemed to me that to make proper use of it, I needed a way to have the current Palomar plate number appear in the legend, along with the ID of the sheet containing that plate. It also ought to show where I was on the plate, with a little box (one character high) following the plate info with a pixel set inside it to indicate my current position on the plate. (This might be generalized to other atlases, so you could tell at a glance that you were near (say) the bottom left of a given page.)
Display of eclipse/transit/occultation tracks
This feature now works, but it is not quite perfect yet. Here are some of the things that will need to be added.
Better ability to specify location
Right now, the Locations dialog allows you to set your lat/lon and home planet, and possibly a geocentric (or planetocentric, if your home planet isn't earth) viewpoint. But people would also like to be able to specify a "city", or an "MPC (Minor Planet Center) station code", or something similar. Also, people have commented that Guide does show maps of the earth (in eclipse mode); why can't they specify their location by clicking on that map?
I have found some data to help in all this. I have an immensely detailed dataset of US cities and towns (every postal code is listed, so you even have some ability to specify position within a city). Of course, I have the MPC list of observer's stations. And I recently found a good list of over 4000 world cities. (Unfortunately, it's in French. But usually, this is less of a problem than you would think. The database also lists about 4000 cities in France.)
The above datasets are on the Guide 6 and 7 CDs, so that later software can use them. (If you know of other databases with locations and their lat/lons, please let me know! Even with the 4000 world-city database, a lot of smaller places are overlooked.)
It would also be pleasant if Guide could figure out your time zone, given your location. But I doubt that will work very well.
And finally, a good way to specify locations that are not on planets ("give me a view from 50 AU away from the sun, from ecliptic north"; views from asteroids, comets, earth-orbiting satellites, interplanetary satellites...)
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.
(Updated 5 October 2002) Earth-orbiting satellite features
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.
This one is also straightforward. Right now, Guide does a pretty good job of rearranging text to ensure that new text does not collide with old text, and that it doesn't run under the legend or off the screen or page. But there are some ways in which this can be improved. Guide currently simply checks each new piece to make sure it doesn't collide with old text; it would be even better if it kept a big list of text, then sorted it out to get the best layout, and only at the end would it actually draw the text. (The user would see no text on the screen until the very end.) This would give Guide more flexibility in arranging text.
RealSky/DSS (and other image) management
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.)
Guide on a handheld (Palm Pilot, etc.)
Several people would like to see Guide work on handhelds. It would be useful for scope control, especially once I get that section of Guide improved a bit (better interface and mechanical error handling.)
The main obstacle here is sweating Guide down to the size where such a thing would work. I've mostly thought in terms of adding more data and features, to the point where one CD wasn't enough, even with most of the data in compressed form; I had to add a second CD, which is also full.
It's vaguely possible that a greatly-reduced Guide (stars to, say, mag 7, with only limited data on each star; planets with lower precision than they now have, both to save space and to improve computation time on a slower device; no comets or asteroids by default, though the user could add at least a few) might fit on a high-end handheld. I'd be reluctant to make the change the software itself too much (keeping one version going consumes plenty of time as it is), which would mean that most of the other features (display of user-added datasets, artificial satellites, scope control, etc.) would still be operational. The user could copy over datasets, artificial satellite elements, and so on as desired, accepting the inevitable performance loss for the things that are "really needed".
Guide is already pretty smart about allowing for the possibility that some files will be missing (for example, if you've done a "minimal install" and removed the CD, Guide will keep going... it just won't show you very much.) The same principle would apply for handheld operation.
Note that all this would still only get us up and running on Windows-based handhelds. Certain other solutions might pave the way to use on other devices; in particular, the TrollTech toolkit offers a way to produce a Linux solution (see below) that will also work on a Mac and on handhelds. In other words, if I got a Linux solution going, the other platforms might follow (I'm not as knowledgeable about this as I perhaps ought to be, but that's the way it appears to work.)
An increasing number of people are asking about the possibility of a port of Guide to Linux. I don't want to raise hopes too far (see much of the above for things apt to occur first!), but it is something I'd like to do. Normally, ports between any systems are absolute nightmares, but that is less true in the case of Guide. The structure of Guide, built to allow easy maintenance on three platforms (16-bit and 32-bit Windows, and DOS with a 32-bit extender) means that many of the porting issues involved have been dealt with already. Also, I have some previous experience with DOS-to-Unix ports. Some were complicated by shifting both from 16 to 32 bits, and from PCs to machines with different byte orders. Neither headache, at least, would arise here.
Even some of the minor aspects have already been dealt with. For example, printing via PostScript is already implemented; that code will port with very little trouble. (I don't want to give the impression that this will be a one-day job, though. Just learning to deal with X-Windows programming will be daunting.)
There are some pretty good reasons for me to do such a port. Astronomers seem to be especially interested in Linux; see page 54 of the February 1998 Sky & Telescope, "Computing Like a Professional", for an article about this. Also, I must admit that I am not entirely thrilled with Microsoft systems, and would be quite happy to support a good competitor.
Balanced against this is the fact that I always have a few dozen projects brewing. It will be a long time before I can turn my hand to really porting Guide to Linux. In the meantime, I'd suggest checking out Elwood Downey's XEphem software.
So far, I've gotten to the point of porting certain chunks of my code to Linux. The source code for basic astronomical calculations, for example, has been ported and used in console apps in Linux. The Find_orb software for orbit determination has been ported, in console-app form, to Linux.
The major obstacle is porting (really, re-writing from scratch!) the user interface code. The best candidate for the UI part is the Qt toolkit supplied by TrollTech. Using this, I could write one user interface for use on Linux, Windows, and Mac systems.
I'd probably use Qt first to port the GUI version of Find_Orb, for two reasons. First, by porting a small app, I'd learn a few things that would doubtless avoid frustration when the time came to port the large app. Second, the licensing for Qt allows use on free software at no cost, while charging a bit for commercial use. I could port Find_Orb (which is freeware) and learn enough to make a better decision as to whether Qt is right for Guide.
Two people have mentioned running the DOS version of Guide under dosemu, and several have used Wine (Windoze "emulator"). This does work. Wine doesn't have a wonderful reputation, but Guide doesn't use most of the more esoteric aspects of the Windows API; the parts it does use appear to be well-supported by Wine. But people naturally want to have a real Linux version, and Wine doesn't qualify.
A Mac port, by the way, is now unlikely in the extreme (unless use of Qt leads in that direction). I get far more requests for a Linux port than for a Mac port, and the Linux port would be easier by several orders of magnitude. There is some discussion of a Mac port in the next section.
There is at least one person running the DOS version of Guide on a Mac, using the DOS emulation. Several run the Windows software using the Connectix "Virtual PC" system and other Windoze-on-a-Mac systems, and all have reported success so far. Still, this is not what most Mac users are looking for; all would prefer a "real Mac" program.
There are no real plans for a Mac version, and not much interest out there. (There used to be some interest in it, but Mac use has been dropping off rather drastically over the years... and Linux use has been rising; if I did a port today, it would be to Linux.)
So about the best I can do is to suggest possible Mac software. Starry Night, by SiennaSoft, seems to be well thought of (I've never seen it). TheSky, by Software Bisque, is supposed to come out in a Mac version soon. URLs are:
http://www.siennasoft.com http://www.bisque.com
I'm pretty sure that there are several others out there. I've heard of MPAstro, but know nothing of it. In truth, I don't follow the Mac market at all; for all I know, the suggestions made above are not those an experienced Mac user would make, and should be taken with a large grain of salt.
Interactive suggestions/requests on this page
Dave Harris has suggested that making this list interactive, so people could add thoughts to it, might be good. I like the idea; for one thing, it would make it less likely that I'd forget to add to this list. For another, there are a lot of people working on interesting projects using Guide; a place where ideas could be shared would be quite productive, I think.
I will have to do some research on how such a feature would be implemented. (My current knowledge of Web sites is really pretty limited. Once I learned how to provide linked text, some in bold and some in italics, and how to provide files, I had all I felt I needed.) Ideally, someone could look at the above comments on a Linux version of Guide and add, for example, "Really good idea; don't forget about other flavors of Unix", or "I really would like to see a Mac/OS2/TRS-80/Acorn version", and so forth.
Ability to use the Lowell ASTORB dataset for asteroids
As of 17 Mar 1999, this is almost not an issue, because Guide can use the Minor Planet Center's MPCORB database in place of its built-in data (click here for details on this feature). Still, there are probably cases where it would be nice to use the Lowell Observatory ASTORB database as the basis for computing asteroid positions. This would really only apply if the object appeared in a current ASTORB, but not on the Guide CD or in MPCORB. This is not going to happen often, but it can occur. MPCORB contains only realistically visible objects; ASTORB contains everything. If an object was found shortly after the Guide CD was made, but is now lost or nearly so, MPCORB won't contain it, but ASTORB will.
Eric-Sven Vesting has mentioned that it would be nice to revise faulty objects. These fall in several classes. First, you've probably noticed that plenty of nebulae and galaxies have a green GSC "non-star" at their core. When you want to click on the nebula or galaxy, you often get the (useless) data on the GSC object instead. It would be nice to be able to click "OK", then hit a key to get rid of the nonexistent star. Then, you would see the error go away and could click on the real object. (This, at least, has been fixed; click here for details.)
A somewhat more ambitious task: It would also be nice to revise the data used to display an object. Even some NGC/IC objects are not properly positioned, or have bad magnitudes. One should be able to enter revised data, then see the object shown correctly. (Ideally, the revisions could be e-mailed back for possible use in Guide 7, 8, 9, ....)