(XXX) observer codes for astrometric data

The Minor Planet Center has a "standardized" format for reporting measured positions of asteroids, comets, natural and artificial satellites, and planets. To report a position to them, you give the location of your telescope as a three-character code. This used to be a three-digit code; (695), for example, is Kitt Peak; (568) is Mauna Kea; and so on.

When they ran low on three-digit codes, they added codes that were an uppercase letter and two digits, such as (E12) Siding Spring and (G96) Mt. Lemmon Survey.

You can get an "official" three-character MPC code for your observatory. However, it takes a good bit of effort and some time, and the MPC considers codes to be a limited resource (3600 possible codes with their current scheme, with 2575 used as of 2025 January and some reserved for various reasons.) They are understandably reluctant to hand out a code unless you're apt to provide a substantial number of observations.

Alternatively (or while waiting for MPC to assign a code), you can contact me for an 'unofficial' MPC code. I maintain a list of unofficial observatory codes to supplement the MPC one. While I'm quite willing to add new ones, this has the drawback that it only works on my software. That does cover all the various tools on this Web site and the software I've published such as Sat_ID and Find_Orb.

However, MPC has provided another workaround : the temporary code (XXX). For this, you need to supply the same sort of observational header details as with any batch of observations, saying what telescope was used, who did the observing, and so on. But you also have to give your latitude/longitude/altitude in a very specific format, using a line starting with COM Long. An example :

COD XXX
COM Long. 242 18 45 E, Lat. 33 54 11 N, Alt. 100m, Google Earth
(rest of your header,  with ACK,  TEL,  OBS,  etc. lines)
(a bunch of 80-column observations,  all ending in XXX)

MPC is a little picky about the way this is formatted. Most of us would put the above longitude in the Western Hemisphere, and would therefore write it as 117 41 15 W. Don't do that. If you're a Western Hemispherian, substract your longitude from 360 degrees and put yourself in the Eastern Hemisphere.

You also need to supply a "Long.", "Lat.", and "Alt.", in that order. At the end, you have to say how you obtained the coordinates. Google Earth is surprisingly good for doing this; its coordinates are good to about five meters, even on mountaintops. Note that (as best I can tell) you can't get altitudes from Google Maps; it's an odd limitation they're apparently unwilling to fix. But Google Earth will do it.

For full accuracy, be sure that the altitude is above the WGS84 ellipsoid, not above sea level! Click here if you aren't sure what that means.

If you're going to send your temporary observer data to MPC, stop reading now. I'm about to describe Find_Orb's extensions to this scheme. Use of any of them will cause MPC to reject your data.

With Find_Orb, you can use W longitudes. You can also specify latitude and/or longitude in decimal degrees, or in degrees and decimal minutes; the above could have used Long. 242 18.75 E or Long. 117 41.25 W or Long. 117.6875 W, for examples.

Find_Orb will also let you apply this to codes other than (XXX). If you don't expect the data to ever go to MPC, I suggest picking three characters that mean something, such as (jkO) for Joseph Kurtz Observatory, or (1.2) for your 1.2-m reflector. Don't use three numbers or a letter and two numbers; MPC uses that pattern, and even if there's no current collision, they may add such a code.

Because you can select a different code, you can also have as many temporary observers as you wish. Observations can come from (XXX), (jkO), and (1.2), as long as you provide the observational header for each.

You can also simply add "your" code for Find_Orb's use. If you edit the file rovers.txt in any text editor, you'll get full directions on how to do so, and will see a variety of "MPC codes" already present.

Find_Orb will also let you "move" an existing, official site. Let's say you thought the MPC position for (568) Mauna Kea was wrong.

COD 568
OBS R. Observer
TEL 60-mm refractor
COM Long. 204 31 18.3141 E, Lat. 19 49 22.2718 N, Alt. 4211.6m, Because I say so

would "correct" the MPC mistake.

Note that if you provide such data to the on-line Find_Orb utility, the "observing stations" data will have a line such as

(XXX) Temporary MPC code  (N33.903056 W117.687500)  US/California.

(same location, expressed in decimal degrees instead of degrees/minutes/seconds). And clicking on the lat/lon should give a Google map of your site. (Which is a good way to test that you got the location right.)

(Find_Orb only) You can specify the observatory name after the obscode, and then that'll be used instead of "Temporary MPC code". For example,

COD jkO Joseph Kurtz Observatory
OBS U. Observer
COM Long. .....

Ellipsoidal altitude vs. height above sea level

Heights from most sources (maps, Google Earth, most modern navsat units) are 'above sea level' or 'geoid' heights. They are relative to a somewhat complicated shape (the geoid) with irregular variations due to the earth's gravitational field not being mathematically perfect.

A simplified explanation would be that if you could dig a tunnel from the ocean to your location, the point where the water rose to would be sea level, and your height above that would be your 'height above sea level'. It means that with any passably recent navsat unit, you can walk to the seashore and see an altitude of slightly over zero meters. Or you can run a cursor near the seashore on Google Earth and see near-zero altitudes (this is, in fact, how I verified that they really do use ASL altitudes).

Ellipsoidal heights, in contrast, are measured relative to a mathematically exact ellipsoid. The almost universal standard is the World Geodetic System (WGS84) ellipsoid, which approximates the earth as an ellipsoid that has a radius of 6378.137 kilometers at the equator and 6356752.314140 kilometers at the poles, suitably adjusted to be a good fit (on average) to the actual geoid.

The difference between ellipsoidal altitude and ASL/geoid altitude, also known as the "geoid height", can be as much as about plus or minus a hundred meters.

I had a navsat unit a couple of decades ago that lacked the sophistication to take an ellipsoidal altitude (what a navsat unit natively measures) and convert it to an ASL altitude. (The conversion involves summing up a huge series of terms in a spherical harmonics expansion. Pretty easy today, but not then.) When I was near the coast, I didn't get altitudes close to zero.

Altitudes above the ellipsoid are mathematically much more straightforward to deal with and are usually what an astronomer needs. In particular, they are what is needed when specifying an observatory location, either in the COD XXX form or in any other.

You can use this site to determine the geoid height for any point on the earth. As described there, you can add the result to an ASL altitude (the one you probably have) to get an ellipsoidal height (the one you actually need).