Laurent Zimmermann wrote:

"...On the other hand, it could be a good idea if Guide itself had
a built-in option to make the same job. Bill, what's your opinion?"

Guide does have something of this ilk, but Denis' comments are
making me think I may want to do a better job of it.

Right now, when Guide has to draw asteroids from MPCORB for a
particular date, it first computes the location and magnitude of each
asteroid at the start and end of that date. It stores all of this in
a file called 'mpcorb.lim' ("limits" file for mpcorb). Subsequent
draws of asteroids for that date tend to be quite fast, because
Guide can look through 'mpcorb.lim' and say, "this asteroid isn't
bright enough on this day" or "this asteroid doesn't appear in the
current chart area on this day." As a result, Guide will usually
consider just those asteroids that really matter, and it can run
briskly, even on old computers.

The problem arises when you specify a different day. Guide has
to recompute everything, and you get a long wait.

Denis now has me contemplating a few revisions to this idea. First,
the 'mpcorb.lim' file would indicate the area covered by an asteroid,
and its maximum magnitude, over a fifty-day period, not a one-day
period. And Guide would be able to create several of these files,
perhaps up to ten of them, so that over a 500-day range, it would
run briskly.

There would still be a slowdown when (for example) using an updated
'mpcorb.dat', because when you do that, new 'mpcorb.lim' files would
be needed. And they'd be created on an as-needed basis, so when you
decided you wanted to look at where an object will be next year, there
would be a pause as Guide created the necessary .lim file. But such
pauses would be far less frequent than they are now. Something for me
to work on...

-- Bill