MPCORB database: its properties and use in Guide and Charon
MPCORB is a database of asteroid orbits maintained by the Minor Planet Center. It gives orbits for all numbered and observable unnumbered asteroids, and can be downloaded from the ftp directory ftp://cfa-ftp.harvard.edu/pub/MPCORB. Mirror sites have recently been created:
http://www.astro.cz/mpcorb http://mpcorb.astro.cz/ ftp.astro.cz with username mpcorb and password Ceres. ftp://byte-o-matic.net/pub/mpcorb
On all these sites, the MPC provides the main database in two forms: as MPCORBCR.DAT and MPCORB.DAT. Both contain exactly the same data, but the former is in PC format (with a carriage return/line feed at the end of every line of data), the latter in Unix format (a line feed but no CR at the end of each line). Guide and Charon will recognize either file. MPC also makes both files available in .ZIP format, reducing the download size considerably. The files are updated daily.
Some people have run into troubles in accessing this data from the MPC site. If you're one of them, click here. (It's hoped that the mirror sites will reduce this trouble.)
To use the datasets in Guide, move either .DAT file into the Guide directory. The Extras menu in Guide has an option, "Use MPCORB", shut off by default. (If it is grayed out, it means that Guide can't find either .DAT file.) When you use the toggle, Guide will swap to use of MPCORB data.
This has several pros and cons. Foremost among the advantages of MPCORB is that it is completely up to date, reflecting the latest orbits computed by the Minor Planet Center. The first Guide 7.0 CDs were made in November 1998, and plenty of asteroids have been found since then or had their existing orbits improved. For example, MPCORB contains numbered asteroids past 14000; the first Guide 7.0 CDs only go up to 9826.
Click here for information about use of MPCORB with Charon.
There are a few disadvantages to use of MPCORB. The data exists at only one epoch, always within 100 days of the present. If you try to compute positions far away from that epoch, the quality of the results will gradually deteriorate. The Guide CD provides orbital elements at 50-day intervals over a span of several decades, so the epoch of the data is never off by more than 25 days. Thus, for objects that were well-determined in the original Guide data, MPCORB positions will be less accurate. It's best to avoid MPCORB, for example, in computing asteroid occultations, which always involve well-determined objects. (In defense of MPC, I should point out that if Guide had a built-in orbital integrator, this problem would go away and MPC would be more accurate in all cases.)
Also, use of MPCORB can be slow. Each time you switch to a new (UT) day, Guide has to compute some basic data as to where the asteroid will be over the duration of that day. This speeds up subsequent drawing, since it enables Guide to discard about 99% of the asteroids as "off-screen" for a given chunk of sky. But, at least when you change Guide's date/time to a new day, there will be a delay while the recomputing is done. (On my 200 MHz Pentium, the delay is about six seconds.)
In any case, if MPCORB.DAT or MPCORBCR.DAT are available to Guide, then when you click for "more info" on an asteroid, some comments from MPCORB will be given.
Some people are apt to wonder why this database is used instead of the Lowell Observatory ASTORB dataset. MPCORB has several advantages over ASTORB. MPCORB contains currently visible objects; ASTORB contains a lot of objects that were observed briefly, long ago, and which are essentially "lost" now. MPCORB tends to be slightly more up to date (understandable, since ASTORB is based on waiting for MPC data to arrive). At some point, I may revise Guide to work with either dataset. But it does appear that MPCORB is best suited to the use of observers; this was my primary goal.
Problems in accessing the MPCORB data (and the Minor Planet Center site in general): Some people who attempt to access the MPCORB data will get an error such as "FTP Error - Could not login to FTP server". That's a result of some efforts made at MPC to deter hackers, spammers, and other vermin.
The simplest way around these issues is to use a mirror site instead of the MPC one. If you're really gung-ho about use of the MPC site, then here are the two things to check:
(1) As is now described partway down the MPC's main page, anonymous ftp passwords are now checked:
You must also ensure that you have set your anonymous ftp password in your browser. This password must contain the "@" character. The default values for this setting in browsers such as Netscape and Mozilla will NOT work. (New requirement 2003 Aug. 27)
In Internet Exploder, one should use Tools... Internet Options, click on Content tab, and then on the My Profile button. You can then select the "Name" tab, then the "Edit" button, after which one can finally edit it to provide some different e-mail address.
In Mozilla, and probably in Netscape, one should click on the Edit... Preferences dialog, then on Advanced. This will give a "Send this e-mail address as anonymous FTP password".
In both cases, one can provide a garbage e-mail address; it doesn't appear that MPC requires that the address be legitimate.
(2) The following post on the Minor Planet Mailing List gives the gory details on some of the other security precautions taken by MPC. Those concerning anonymous ftp are relevant here:
From: "Gareth V. Williams"
To: mpml@bitnik.com
Subject: {MPML} Accessing MPCORB
Following a number of enquiries on this mailing list and via e-mail, I
shall summarise the security checks used to determine whether access to
computers here at the CfA is permitted.
(1) E-mail
Two checks are made with incoming e-mail:
(a) Does the e-mail originate from a site on the spammer blacklist?
If so, bounce the message.
(b) Do a reverse DNS check on the site from which the e-mail originates.
Is it properly DNS registered? If not, bounce message.
(2) http
No checks are made since Web access is only browsing.
(3) anon-ftp
Do a reverse DNS on the requesting site. If not properly
registered, refuse connection.
The problems a number of you have been reporting are almost
certainly due to the fact that your ISP is not properly registering
its machines. Note that is not sufficient that the outgoing request
contain either the machine's IP address or host name (or both): the
machines here must be able to quiz a DNS host to convert the address
to the name (or vice versa). It is up to the ISP to properly ensure
that all their hosts are properly registered.
These checks are security measures to try and ensure that all
communications can be tracked back to their (valid) source. This
is especially important with the recent increase in attacks on
high-profile sites. You'd be surprised how often hacking attempts
are made on the machines on the Harvard network (including one very
successful attempt on some CfA U**x machines a year or two back).
But, then again, maybe you wouldn't (:-)
-----------------------------------------------------------------------
-
Gareth V. Williams, MS 18, 60 Garden Street, Cambridge, MA 02138, U.S.A.
Associate Director, IAU Minor Planet Center
E-mail address suppressed
http://cfa-www.harvard.edu/iau/mpc.html
OpenVMS & RISC OS: refined choices in operating systems