This section describes the sky coordinates in use by science tools. It is referenced from the description of data formats to explain the exact meaning of the coordinates stored.

We don’t have a separate section for world coordinate systems (WCS), pixel coordinates, projections, that is covered here as well (see FITS WCS and WCSLIB for references).

We only discuss 2-dimensional sky and image coordinates here, other coordinates like e.g. time or an energy axis aren’t covered here.

Some conventions are adopted from astropy.coordinates, which is a Python wrapper of the IAU SOFA C time and coordinate library, which is the authoritative implementation of the IAU Standards of Fundamental Astronomy. In some cases code examples are given using astropy.coordinates to obtain a reference value that can be used to check a given software package (in case it’s not based on astropy.coordinates).


The most common way to give sky coordinates is as right ascension (RA) and declination (DEC) in the equatorial coordinate system.

Actually there are several equatorial coordinate systems in use, the most common ones being FK4, FK5 and ICRS. If you’re interested to learn more about these and other astronomical coordinate systems, look into the Explanatory Supplement to the Astronomical Almanac.

But in practice it’s pretty simple: when someone gives or talks about RA / DEC coordinates, they mean either ICRS or FK5 J2000 coordinates. The difference between those two is at the sub-arcsecond level for the whole sky, i.e. irrelevant for gamma-ray astronomy.

We recommend you by default assume RA / DEC is in the ICRS frame, which is the default in astropy.coordinates.SkyCoord and also the current standard celestial reference system adopted by the IAU (see Wikipedia - ICRS).


The Galactic coordinate system is often used by Galactic astronomers.

Unfortunately there are slightly different variants in use (usually with differences at the arcsecond level), and there are no standard names for these slightly different Galactic coordinate frames. See here for an open discussion which Galactic coordinates to support and what to call them in Astropy.

We recommend you use ICRS RA / DEC for precision coordinate computations. If you do use Galactic coordinates, we recommend you compute them like Astropy does (which I think is the most frame in use in the literature and in existing astronomy software).

Both ICRS and Galactic coordinates don’t need the specification of an epoch or equinox.

To check your software, you can use the (l, b) = (0, 0) position:

>>> from astropy.coordinates import SkyCoord
>>> SkyCoord(0, 0, unit='deg', frame='galactic')
<SkyCoord (Galactic): (l, b) in deg (0.0, 0.0)>
>>> SkyCoord(0, 0, unit='deg', frame='galactic').icrs
<SkyCoord (ICRS): (ra, dec) in deg (266.40498829, -28.93617776)>

Alt / Az

The horizontal coordinate system is the one connected to an observer at a given location on earth and point in time.

  • Azimuth is oriented east of north (i.e. north is at 0 deg, east at 90 deg, south at 180 deg and west at 270 deg). This is the convention used by astropy.coordinates.AltAz and quoted as the most common convention in astronomy on Wikipedia (see horizontal coordinate system).
  • The zenith angle is defined as the angular separation from the zenith, which is the direction defined by the line connecting the Earth’s center and the observer. Altitude and elevation are the same thing, and are defined as 90 degree minus the zenith angle. The reason to define altitude like this instead of the angle above the horizon is that usually Earth models aren’t perfect spheres, but ellipsoids, so the zenith angle as defined here isn’t perfectly perpendicular with the horizon plane.
  • Unless explicitly specified, Alt / Az should be assumed to not include any refraction corrections, i.e. be valid assuming no refraction. Usually this can be achived in coordinate codes by setting the atmospheric pressure to zero, i.e. turning the atmosphere off.

Here’s some Astropy coordinates code that shows how to convert back and forth between ICRS and AltAz coordinates (the default pressure is set to zero in Astropy, i.e. this is without refraction corrections):

import astropy.units as u
from astropy.time import Time
from astropy.coordinates import Angle, SkyCoord, EarthLocation, AltAz

# Take any ICRS sky coordinate
icrs = SkyCoord.from_name('crab')
print('RA = {pos.ra.deg:10.5f}, DEC = {pos.dec.deg:10.5f}'.format(pos=icrs))
# RA =   83.63308, DEC =   22.01450

# Convert to AltAz for some random observation time and location
# This assumes pressure is zero, i.e. no refraction
time = Time('2010-04-26', scale='tt')
location = EarthLocation(lon=42 * u.deg, lat=42 * u.deg, height=42 * u.meter)
altaz_frame = AltAz(obstime=time, location=location)
altaz = icrs.transform_to(altaz_frame)
print('AZ = {}, ALT = {pos.alt.deg:10.5f}'.format(pos=altaz))
# AZ =  351.88232, ALT =  -25.56281

# Convert back to ICRS to make sure round-tripping is OK
icrs2 = altaz.transform_to('icrs')
print('RA = {pos.ra.deg:10.5f}, DEC = {pos.dec.deg:10.5f}'.format(pos=icrs2))
# RA =   83.63308, DEC =   22.01450

Field of view

FOV coordinates are currently used in two places in this spec:

  1. Some background models are in the FOV coordinate system and FOV coordinates can also be used for other IRFs.
  2. FOV coordinates appear is as optional columns in the events table. While it is possible to compute FOV coordinates from the RA, DEC, TIME columns and the observatory Earth location, some IACTs choose to add FOV coordinate columns to their event lists for convenience.

In Gamma-ray astronomy, sometimes field of view (FOV) coordinates are used. The basic idea is to have a coordinate system that is centered on the array pointing position. We define FOV coordinates here to be spherical coordinates, there is no projection or WCS, only a spherical rotation.

Two ways to give the spherical coordinate are defined:

  1. (LON, LAT) with the pointing position on the equator at (LON, LAT) = (0, 0)
    • LON: Longitude (range -180 deg to + 180 deg)
    • LAT: Latitude (range -90 deg to + 90 deg)
  2. (THETA, PHI) with the pointing position at the pole THETA=0
    • THETA: Offset angle (range 0 deg to +180 deg)
    • PHI: Position angle (range 0 deg to 360 deg)

Two orientations of the FOV coordinate system are defined:

  1. Aligned with the ALTAZ system
  2. Aligned with the RADEC system

This yields the following possible coordinates:

Field Description
FOV_ALTAZ_LON Longitude in ALTAZ FOV system
FOV_ALTAZ_LAT Latitude in ALTAZ FOV system
FOV_ALTAZ_THETA Offset angle in ALTAZ FOV system
FOV_ALTAZ_PHI Position angle in ALTAZ FOV system
FOV_RADEC_LON Longitude in RADEC FOV system
FOV_RADEC_LAT Latitude in RADEC FOV system
FOV_RADEC_THETA Offset angle in RADEC FOV system
FOV_RADEC_PHI Position angle in RADEC FOV system
  • The FOV offset angle (separation to pointing position) THETA doesn’t depend on the orientation. So in this spec, often simply THETA is used, and that is equal to FOV_ALTAZ_THETA and FOV_RADEC_THETA.
  • The other FOV coordinates depend on the alignment and orientation of a second coordinate systems (OTHER, either ALTAZ or RADEC).
    • FOV PHI is counterclockwise from OTHER north, i.e. PHI=0 deg pointing to OTHER LAT, and PHI=270 deg pointing to OTHER LON
    • FOV LON should increase with decreasing OTHER LON
    • FOV LAT should increase with increasing OTHER LAT

In the events table, the column names DETX and DETY are sometimes used. This originates from the OGIP event list standard, which uses these names for “detector coordinates”. Given that IACTs don’t have a detector chip (or at least the FOV coordinates used in high-level analysis are different from the IACT camera coordinate detectors), the definition is not unambiguous, both (DETX, DETY) = (FOV_ALTAZ_LON, FOV_ALTAZ_LAT) and (DETX, DETY) = (FOV_RADEC_LON, FOV_RADEC_LAT) have been used.

To resolve this ambiguity, we propose a header key FOVALIGN={ALTAZ,RADEC}, specifying which definition of field-of-view coordinates is used. If the key is not present, FOVALIGN=ALTAZ should be assumed as default.

Given the situation that there is no concensus yet, one suggestion is to avoid putting FOV coordinates in EVENTS, or if they are added, to clearly state how they are defined.

Earth location

When working with Alt-Az coordinates or very high-precision times, an observatory Earth location is needed. However, note that high-level analysis for most use cases does not need this information.

The FITS standard specifies two possibilities for defining observatory location:

  • ITRS Cartesian coordinates (defined in section 8.4.1, strongly prefered according to section 9.3.2)
  • Geodetic latitude / longitude / elevation

For ITRS Cartesian coordinates, use

  • OBSGEO-X, OBSGEO-Y, OBSGEO-Z type: float, unit: m

For geodetic coordinates, use

  • OBSGEO-L Geographic longitude of array center, type: float, unit: deg
  • OBSGEO-B Geographic latitude of array center, type: float, unit: deg
  • OBSGEO-H Altitude of array center above WGS84 reference ellipsoid, type: float, unit: m


Up to including version 0.2 of this standard, the keywords GEOLON, GEOLAT and ALTITUDE were used for the observatory location.

While it is possible in principle to change this for each FITS file, in practice the observatory or telescope array center position is something that is chosen once and then used consistently in the event reconstruction and analysis. As an example, H.E.S.S. uses the following location and FITS header keys:

OBSGEO-B = -23.2717777777778 / latitude of observatory (deg)
OBSGEO-L =  16.5002222222222 / longitude of observatory (deg)
OBSGEO-H =             1835. / altitude of observatory (m)