Coordinate Systems in KStars



Horizontal Coordinates

Horizontal coordinates are defined strictly relative to the observer. We usually use two angles, the altitude, which measures the angle from the point to the horizon, so that 90° is straight up, 0° is on the horizon, and -90° is straight down, and the azimuth, which measures the angle eastward from the north direction to the direction of the point.

Equatorial Coordinates

There are two important lines on the celestial sphere that we’ll use to define our coordinate systems. The first is the celestial equator, which is just the Earth’s equator, extended outwards and projected onto the celestial sphere. The second is the ecliptic, which is the intersection of the Earth’s orbital plane with the celestial sphere. Since the Earth’s axis is tilted, these two lines are distinct, and they intersect at two points, as seen in this drawing:

Equator and Ecliptic

From the point of view of the Earth, the Sun travels along the ecliptic. When the ecliptic intersects the equator, it means that the Sun is directly above the equator, so night and day have the same length everywhere on earth. Thus, these points are the spring (vernal) and fall (autumnal) equinoxes.

The equatorial coordinate system describes a point p in terms of its relation to the vernal equinox, usually by means of two angles, called right ascension and declination. The right ascension, RA or α, is the angle running eastward from the vernal equinox along the equator, while the declination is the angle from the object to the equator.

Wikipedia provides a nice summary in GIF format:

Equatorial Coordinates

J2000 and standard epochs

One thing to note about this system is that the Earth does not orbit the Sun perfectly. The Earth has precession and nutation, which are respectively a slow drift in the earth’s rotational axis and a slight, gradual wobbling motion. These motions cause the positions of the equinoxes to shift slightly, which means that the equatorial coordinates of even “fixed” objects vary over time, since they’re defined in reference to a moving point!

To solve this problem, astronomers agree on particular times (“epochs”) to reference their coordinates. The most common is the J2000 epoch, which is defined to be the equatorial coordinates of a point in reference to the vernal equinox at noon on January 1, 2000.

These coordinates have the time already specified, so we’re not missing any information, and we can use them in catalogs and databases.

As an example, the Andromeda galaxy currently has equatorial coordinates of RA = 00h 43m 29s, Dec = 41° 20’ 22“, but the catalog coordinates are RA = 00h 42m 44s, Dec = 41° 16’ 08”.

Ecliptic coordinates

Ecliptic coordinates are pretty similar to equatorial coordinates, but they’re defined in terms of the ecliptic plane, instead of the equatorial plane. We describe a point in terms of its ecliptic longitude, which is measured eastward from the vernal equinox, and its ecliptic latitude, which is the angle from the point to the ecliptic plane.

The same points about time dependence hold for ecliptic coordinates as well as equatorial coordinates, but in KStars we don’t store any data in ecliptic coordinates, so it’s not as important to define reference epochs for ecliptic coordinates.

Galactic coordinates

Finally, there’s the galactic coordinate system. This system places the Sun at the centre and uses the disk of the Milky Way to define the galactic equator. It describes a point in terms of its galactic longitude, measured eastward from the centre of the galaxy, and its galactic latitude, which is the angle to the galactic plane.

KStars doesn’t actually make use of these, but we have the ability to calculate them, and this is exposed to the user as part of KStars’ tools collection.

Converting between coordinate systems

A lot of the work that KStars does goes into converting between these coordinate systems. We have a lot of different types of objects, which are grouped into SkyComponents. Currently, KStars deals with the problem of different objects needing different calculations by making each sky object have its own class, with its own object-oriented code for computation. This is really, really, bad for performance in a lot of ways, because it has fragmented memory access patterns, a virtual function call for each point, and a lot of duplicated work.

Simplfying this requires carefully laying out what kinds of computation we do for each kind of sky object, which I’ll do in a future post. For now, I’ll just give a brief description of what goes into the conversion from one coordinate system to another.

To convert from horizontal coordinates to equatorial coordinates, we need to know the time and location of the observer. Going back to the description we had of the equatorial coordinate system, we have a (relatively) fixed sphere, with the earth rotating around inside. All we need to do is compute the rotation of the earth, and apply that rotation to all of the points we want to convert. (Interestingly enough, at the moment KStars computes this rotation for each point we want to compute, because we never compute multiple conversions at the same time). If we want to be very precise, however, we need to compute the effects of atmospheric refraction, which makes our points appear higher in the sky then they actually are.

As we noted, equatorial coordinates change over time due to the effects of precession and nutation. Converting equatorial coordinates in one epoch to another epoch requires computing the effects of precession and nutation. But there’s an extra complication there, too: we also need to compute the effects of aberration, which is caused by relativistic effects: the earth is moving around the sun, and this movement causes the apparent position of the stars to shift depending on the relative velocity of the earth to the star.

Converting from equatorial to ecliptic coordinates is a simple rotation, and we just need to know the angle between the Earth’s equator and the ecliptic plane. This varies over time, so we need to compute precession and nutation as before.

However, this isn’t the full story: some objects have extra calculations that need to be done, and we also want to be able to do these computations in a way that avoids trigonometry as much as possible. To be continued…

Posted June 17, 2013 under planetkde, kstars, math.