The term oblique projection is often used when a projection's native coordinate system does not coincide with the coordinate system of interest. Texts on terrestrial cartography often separately name and derive projection equations for particular oblique projections. Thus the Cassini, Transverse Mercator, and Bartholomew nordic projections are nothing more than the plate carrée, Mercator, and Mollweide projections in disguise.
The view of obliqueness as being a property of a projection arose mainly because of the computational difficulty of producing oblique graticules in the days before electronic computers. The particular aspects chosen were those for which geometrical construction was possible or for which the mathematical formulation had a simple form, and this tended to entrench particular oblique projections as separate entities. In addition, terrestrial longitude and latitude are so closely tied to the visual representation of the Earth's surface that it is shown predominantly in the usual north-south orientation. The only other natural terrestrial coordinate system is that defined by the magnetic pole but the difference between it and the geographic graticule is sufficiently small that it is usually treated as a local correction to the magnetic bearing. The special view of obliqueness was probably also reinforced by traditional methods of map making using sextant and chronometer, which were based on geographic longitude and latitude.
The situation in astronomical cartography is quite different. The celestial sphere has a variety of natural coordinate systems - equatorial, ecliptic, galactic, etc. - and oblique and non-oblique graticules are often plotted together on the same map. It wouldn't make sense to describe such a projection as being simultaneously oblique and non-oblique; clearly it is the particular coordinate graticule which may be oblique, not the projection. Visually, an area of the sky may be seen in different orientations depending on whether it's rising, transiting, or setting, or whether seen from the northern or southern hemisphere. Moreover, oblique graticules arise as a normal feature of observations in optical, infrared, radio, and other branches of astronomy, just as they do now in terrestrial mapping based on aerial and satellite photography. The center of the field of view, wherever it may happen to be, typically corresponds to the native pole of a zenithal projection. Thus the aim of this paper has been to provide a formalism whereby obliquity may be handled in a general way.
Figures 33 and 34 illustrate the same four oblique
celestial graticules for the zenithal equal area, conic equidistant,
Hammer-Aitoff, and COBE quadrilateralized spherical cube projections (at
variable (x,y) scale). For the sake of intercomparison, these graticules
are defined in terms of the celestial coordinates of the native pole,
,
together with
by setting
as described in Sect. 2.5.
The first graticule, A, when compared to the non-oblique native coordinate
graticules presented earlier for each projection, illustrates the effect of
changing
(and hence
). Comparison of graticules A
and B shows that changing
(and hence
)
results in a
simple change in origin of longitude. Graticules A, C, and D show the more
interesting effect of varying
(conveyed by LONPOLE a). For
the zenithal projections the result is indistinguishable from a bulk rotation
of the image plane, but this is not the case for any other class of
projection. This explains why the role of LONPOLE a was covered by
CROTA i in the AIPS convention for the zenithal projections introduced by
Greisen (1983), but why this does not work for any other class of
projection.
![]() |
Figure 33:
Oblique
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
Figure 34:
Oblique (
![]() |
The projected meridians and parallels in Figs. 33 and 34 also serve to illustrate the distortions introduced by the various projections. In particular, the quad-cube projection, while doing a good job within each face, is very distorted over the sphere as a whole, especially where the faces join, so much so that it is difficult even to trace the path of some of the meridians and parallels. However, as indicated previously, this projection is designed for efficient numerical computation rather than visual representation of the sphere.
This leads us to the question of the choice of projection for a particular
application. In some cases the projection is the natural result of the
geometry of the observation and there is no choice. For example, maps
produced by rotational synthesis radio telescopes are orthographic
(SIN) projections with native pole at the phase center of the
observation. Photographic plates produced by Schmidt telescopes are best
described by the zenithal equidistant (ARC) projection, while the field
of view of other optical telescopes is closer to a gnomonic (TAN)
projection. On the other hand, the great circle scanning technique of the
Sloan Digital Sky Survey produces a cylindrical projection. Similarly a map
of the surface of the Moon as it appears from Earth requires a zenithal
perspective (AZP) projection with
.
The same is true
for spacecraft generated images of distant moons and planets. All-sky cameras
should be well served by a ZPN projection with empirically determined
parameters.
Sometimes observational data will be regridded onto a projection chosen for a
particular purpose. Equal area projections are often used since they preserve
surface density and allow integration, whether numerical or visual, to be
performed with reasonable accuracy by summing pixel values. The Hammer-Aitoff
(AIT) projection is probably the most widely used for all-sky maps.
However, the Sanson-Flamsteed (SFL) may be preferred as being easier to
take measurements from. The humble plate carrée (CAR) excels in
this regard and may be considered adequate, say, for mapping a few degrees on
either side of the galactic plane. In general terms, zenithal projections are
good for mapping the region in the vicinity of a point, often a pole;
cylindrical projections are good for the neighborhood of a great circle,
usually an equator; and the conics are suitable for small circles such as
parallels of latitude. A conic projection might be a good choice for mapping
a hemisphere; distortion at most points is reduced compared to a zenithal
projection although at the expense of the break between native longitudes
.
However, in some cases this break might be considered an
extreme distortion which outweighs other reductions in distortion and,
depending on the application, may mandate the use of a zenithal projection.
Cartographers typically favor conics and polyconics for "Australia-sized''
regions of the sphere and at this they excel. Oblique forms of the zenithal
equal-area projection are also commonly used. Celestial applications might
include large scale maps of the Magellanic clouds. Tables 3.1 and 4.1 of
Snyder (1993) summarize actual usage in a variety of 19th and 20th
century atlases.
As mentioned in Sect. 5, some projections are not scaled
true at the reference point. In most cases this is deliberate, usually
because the projection is designed to minimize distortion over a wide area;
the scale will be true at some other place on the projection, typically along
a parallel of latitude. If the projection is required to have
then a number of projections
will serve provided also that
takes its default value. The
following are always scaled true at the reference point: SZP,
TAN, SIN, STG, ARC, ZEA, CAR,
MER, BON, PCO, SFL, and AIT. The
following are scaled true at the reference point for the particular conditions
indicated: AZP (
), ZPN (
P0=0, P1=1), AIR
(
), CYP (
), CEA (
),
COP (
), COD (
), COE (
), and
COO (
). The following are never scaled true at the reference
point: PAR (but is scaled true in x), MOL, TSC,
CSC, and QSC; the latter three are equiscaled at the reference
point.
Of course CDELT ia may be used to control scaling of (x,y) with respect to (p1,p2). Thus, for example, the plate carrée projection (CAR) also serves as the more general equirectangular projection.
We now consider three examples chosen to illustrate how a FITS reader would interpret a celestial coordinate header.
Example 1 is a simple header whose interpretation is quite straightforward.
Example 2 is more complicated; it also serves to illustrate the WCS header cards for 1) image arrays in binary tables, and 2) pixel lists.
Example 3 highlights a subtle problem introduced into a header by the FITS writer and considers how this should be corrected. As such, it introduces the generally more difficult task of composing WCS headers, considered in greater detail in Sect. 7.4.
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 |
NAXIS = 4 / 4-dimensional cube |
NAXIS1 = 512 / x axis (fastest) |
NAXIS2 = 512 / y axis (2nd fastest) |
NAXIS3 = 196 / z axis (planes) |
NAXIS4 = 1 / Dummy to give a coordinate |
CRPIX1 = 256 / Pixel coordinate of reference point |
CDELT1 = -0.003 / 10.8 arcsec per pixel |
CTYPE1 = 'RA---TAN' / Gnomonic projection |
CRVAL1 = 45.83 / RA at reference point |
CUNIT1 = 'deg ' / Angles are degrees always |
CRPIX2 = 257 / Pixel coordinate of reference point |
CDELT2 = 0.003 / 10.8 arcsec per pixel |
CTYPE2 = 'DEC--TAN' / Gnomonic projection |
CRVAL2 = 63.57 / Dec at reference point |
CUNIT2 = 'deg ' / Angles are degrees always |
CRPIX3 = 1 / Pixel coordinate of reference point |
CDELT3 = 7128.3 / Velocity increment |
CTYPE3 = 'VELOCITY' / Each plane at a velocity |
CRVAL3 = 500000.0 / Velocity in m/s |
CUNIT3 = 'm/s ' / metres per second |
CRPIX4 = 1 / Pixel coordinate of reference point |
CDELT4 = 1 / Required here. |
CTYPE4 = 'STOKES ' / Polarization |
CRVAL4 = 1 / Unpolarized |
CUNIT4 = ' ' / Conventional unitless = I pol |
LONPOLE = 180 / Native longitude of celestial pole |
RADESYS = 'FK5 ' / Mean IAU 1984 equatorial coordinates |
EQUINOX = 2000.0 / Equator and equinox of J2000.0 |
The celestial coordinate system is equatorial since the CTYPE ia begin with
RA and DEC and the RADESYS a and EQUINOX a cards denote that
these are in the IAU 1984 system. Zenithal projections have
for which the CRVAL i give equatorial
coordinates
in right ascension and
in declination. The equatorial north pole has a
longitude of
in the native coordinate system from the LONPOLE a
keyword. LATPOLE a is never required for zenithal projections and was not
given. Thus, Eqs. (6) for the right ascension and declination
become
If we define the projection non-linearity as the departure of
from
,
then in this
image it amounts
to
at the corners. However, in a
image
it quickly escalates to
,
sixty times larger. Comparison of
for the southeast and northeast corners indicates the significant
effect of grid convergence even in this moderate sized image. The two differ
by
,
most of which is attributable to the
term in
converting longitude offsets to true angular distances. The effect of grid
convergence is small for
near the equator and large near
the poles.
Figure 35 investigates the effect of projective non-linearities
for moderate field sizes for the commonly used zenithal projections. It shows
the difference in
between the various projections and the SIN
projection as a function of native latitude
.
The SIN
projection is used as reference since it always has
less than the other
zenithal projections. The difference for all projections exceeds 1 arcsec for
values of
less than
and the difference for the TAN
projection exceeds one milliarcsec only 440 arcsec from the native pole. Such
nonlinearities would be significant in optical, VLBI, and other high
resolution observations.
While the previous header was a realistic example it overlooked many of the
concepts introduced in this paper. Consider now the header given in
Table 7. Although contrived to illustrate as much as possible
in one example, this header could conceivably arise as a "tile'' from a conic
equal area projection of a region of the southern galactic hemisphere centered
at galactic coordinates
.
The tile size of
pixels is approximately
,
and this
particular tile is situated immediately to the north of the central tile.
parameter | units | SE corner | NE corner | NW corner |
(p1,p2) | pixel | (1, 2) | (1, 512) | (511, 512) |
(p3,p4) | pixel | (1, 1) | (1, 1) | (196, 1) |
x | deg |
![]() |
![]() |
![]() |
y | deg |
![]() |
![]() |
![]() |
![]() |
deg |
![]() |
![]() |
![]() |
![]() |
deg |
![]() |
![]() |
![]() |
![]() |
deg |
![]() |
![]() |
![]() |
![]() |
deg |
![]() |
![]() |
![]() |
Velocity | ms-1 | 500000.00 | 500000.00 | 1890018.50 |
Stokes |
![]() |
![]() |
![]() |
The header defines ecliptic coordinates as an alternate coordinate system, perhaps to help define the distribution of zodiacal light. This has the same reference point and transformation matrix as the primary description and the reference values are translated according to the prescription given in Sect. 2. The RADESYSA card indicates that the ecliptic coordinates are mean coordinates in the IAU 1984 system, though the author of the header has been sloppy in omitting the EQUINOXA card which therefore defaults to J2000.0. Note that, in accord with Paper I, all keywords for the alternate description are reproduced, even those which do not differ from the primary description.
The problem will be to determine the galactic and ecliptic coordinates
corresponding to a field point with pixel coordinates
(1957.2,775.4). We
begin as before by substituting in Eq. (1)
The next step is to compute the native longitude and latitude. Like all
standard conics, the conic equal area projection has two parameters,
and
,
given by the keywords PV i_1a and PV i_2a attached
to latitude coordinate i. In this example PV2_1 is given but
the author has again been sloppy in omitting PV2_2, which thus
defaults to 0. Explicit inclusion of this keyword in the header would obviate
any suspicion that it had been accidentally omitted. The native coordinates,
are obtained from (x,y) using Eqs. (117) and
(129) via the intermediaries C, Y0, and
given by
Eqs. (125), (127), and (116). These in turn
are expressed in terms of
,
,
and
given by
Eqs. (128), (119), and (120). The
calculations are shown in Table 8.
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 |
NAXIS = 2 / 2-dimensional image |
NAXIS1 = 2048 / x axis (fastest) |
NAXIS2 = 2048 / y axis (2nd fastest) |
MJD-OBS = 44258.7845612 / MJD at start of observation |
CRPIX1 = 1024.5 / Pixel coordinate of reference point |
CRPIX2 = -1023.5 / Pixel coordinate of reference point |
PC1_1 = 1 / Transformation matrix element |
PC1_2 = -0.004 / Transformation matrix element |
PC2_1 = -0.002 / Transformation matrix element |
PC2_2 = 1 / Transformation matrix element |
CDELT1 = -0.005 / x-scale |
CDELT2 = 0.005 / y-scale |
CTYPE1 = 'GLON-COE' / Conic equal area projection |
CTYPE2 = 'GLAT-COE' / Conic equal area projection |
PV2_1 = -25.0 / Conic mid-latitude |
CRVAL1 = 90.0 / Galactic longitude at reference point |
CRVAL2 = -25.0 / Galactic latitude at reference point |
CRPIX1A = 1024.5 / Pixel coordinate of reference point |
CRPIX2A = -1023.5 / Pixel coordinate of reference point |
PC1_1A = 1 / Transformation matrix element |
PC1_2A = -0.004 / Transformation matrix element |
PC2_1A = -0.002 / Transformation matrix element |
PC2_2A = 1 / Transformation matrix element |
CDELT1A = -0.005 / x-scale |
CDELT2A = 0.005 / y-scale |
CTYPE1A = 'ELON-COE' / Conic equal area projection |
CTYPE2A = 'ELAT-COE' / Conic equal area projection |
PV2_1A = -25.0 / Conic mid-latitude |
CRVAL1A = -7.0300934 / Ecliptic longitude at reference point |
CRVAL2A = 34.8474143 / Ecliptic latitude at reference point |
LONPOLEA= 6.3839706 / Native longitude of ecliptic pole |
LATPOLEA= 29.8114400 / Ecliptic latitude of native pole |
RADESYSA= 'FK5 ' / Mean IAU 1984 ecliptic coordinates |
At this stage we have deprojected the field point. In this example the
alternate coordinate description defines the same projection as the primary
description. Indeed, it may seem odd that the formalism even admits the
possibility that they may differ. However, this is a realistic possibility,
for example in defining multiple optical plate solutions based on the
TAN projection. It now remains to transform the native spherical
coordinates into galactic coordinates, ,
and ecliptic coordinates,
.
To do this we need to apply Eqs. (2) and in
order to do that we need
and
.
Looking first at galactic coordinates, we have
and
.
This conic projection has
,
and because
and
,
the native and galactic coordinate systems must
coincide to within an offset in longitude. However, it is not obvious what
should be to produce this offset. Equation (8)
has one valid solution, namely
.
The special case in point
2 in the usage notes for Eqs. (9) and (10) must
therefore be used to obtain
.
The galactic coordinates of the field point listed in Table 8
are then readily obtained by application of Eqs. (2).
The header says that the ecliptic coordinates of the reference point are
and the native longitude
of the ecliptic pole is
.
It also specifies
LATPOLEA as
.
In this case Eq. (8) has
two valid solutions,
,
and
the one closest in value to LATPOLEA (in fact equal to it) is chosen.
If LATPOLEA had been omitted from the header its default value of
would have selected the northerly solution anyway, but of course it
is good practice to make the choice clear. The value of
may
be obtained by a straightforward application of Eqs. (9) and
(10), and the ecliptic coordinates of the field point computed
via Eqs. (2) are listed in Table 8 as the final
step of the calculation. The reader may verify the calculation by
transforming the computed galactic coordinates of the field point to mean
ecliptic coordinates.
Table 9 shows the FITS header for a set of images stored in binary table image array column format. The images are similar to that described in header interpretation example 2, Sect. 7.3.2, with primary image header illustrated in Table 7.
In this example the images are stored as 2-D arrays in Col. 5 of the table and
each row of the table contains a
pixel image of a different
region on the sky. This might represent a set of smaller images extracted
from a single larger image. In this case all coordinate system parameters
except for the reference pixel coordinate are the same for each image and are
given as header keywords. The reference pixel coordinate for the primary and
secondary description are given in Cols. 1 to 4 of the binary table.
Table 10 shows the header for the same image given in pixel list
format. There are 10 000 rows in this table, each one listing the pixel
coordinates (XPOS, YPOS) of every detected "event'' or photon
in the image. For illustration purposes, this table also contains an optional
DATA_QUALITY column that could be used to flag the reliability or
statistical significance of each event. A real image may be constructed from
this virtual image as the 2-dimensional histogram of the number of events that
occur within each pixel. The additional TLMIN n and TLMAX n
keywords shown here are used to specify the minimum and maximum legal values
in XPOS and YPOS columns and are useful for determining the
range of each axis when constructing the image histogram.
This example has been adapted from a real-life FITS data file. The simplicity of the header shown in Table 11 is deceptive; it is actually presented as an example of how not to write a FITS header, although the latent problem with its interpretation is quite subtle.
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 |
XTENSION= 'BINTABLE' / Binary table extension |
BITPIX = 8 / 8-bit bytes |
NAXIS = 2 / 2-dimensional binary table |
NAXIS1 = 16777232 / Width of table in bytes |
NAXIS2 = 4 / Number of rows in table |
PCOUNT = 0 / Size of special data area |
GCOUNT = 1 / One data group (required keyword) |
TFIELDS = 5 / number of fields in each row |
TTYPE1 = '1CRP5 ' / Axis 1: reference pixel coordinate |
TFORM1 = '1J ' / Data format of column 1: I*4 integer |
TTYPE2 = '2CRP5 ' / Axis 2: reference pixel coordinate |
TFORM2 = '1J ' / Data format of column 2: I*4 integer |
TTYPE3 = '1CRP5A ' / Axis 1A: reference pixel coordinate |
TFORM3 = '1J ' / Data format of column 3: I*4 integer |
TTYPE4 = '2CRP5A ' / Axis 2A: reference pixel coordinate |
TFORM4 = '1J ' / Data format of column 4: I*4 integer |
TTYPE5 = 'Image ' / 2-D image array |
TFORM5 = '4194304J' / Data format of column 5: I*4 vector |
TDIM5 = '(2048,2048)' / Dimension of column 5 array |
MJDOB5 = 44258.7845612 / MJD at start of observation |
COMMENT The following keywords define the primary coordinate description |
COMMENT of the images contained in Column 5 of the table. |
11PC5 = 1 / Transformation matrix element |
12PC5 = -0.004 / Transformation matrix element |
21PC5 = -0.002 / Transformation matrix element |
22PC5 = 1 / Transformation matrix element |
1CDE5 = -0.005 / Axis 1: scale |
2CDE5 = 0.005 / Axis 2: scale |
1CTY5 = 'GLON-COE' / Axis 1: conic equal area projection |
2CTY5 = 'GLAT-COE' / Axis 2: conic equal area projection |
2PV5_1 = -25.0 / Conic mid-latitude |
1CRV5 = 90.0 / Axis 1: galactic longitude at reference point |
2CRV5 = -25.0 / Axis 2: galactic latitude at reference point |
COMMENT The following keywords define the secondary coordinate description |
COMMENT of the images contained in Column 5 of the table. |
11PC5A = 1 / Transformation matrix element |
12PC5A = -0.004 / Transformation matrix element |
21PC5A = -0.002 / Transformation matrix element |
22PC5A = 1 / Transformation matrix element |
1CDE5A = -0.005 / Axis 1A: scale |
2CDE5A = 0.005 / Axis 2A: scale |
1CTY5A = 'ELON-COE' / Axis 1A: conic equal area projection |
2CTY5A = 'ELAT-COE' / Axis 2A: conic equal area projection |
2PV5_1A = -25.0 / Conic mid-latitude |
1CRV5A = -7.0300934 / Axis 1A: ecliptic longitude at reference point |
2CRV5A = 34.8474143 / Axis 2A: ecliptic latitude at reference point |
LONP5A = 6.3839706 / Native longitude of ecliptic pole |
LATP5A = 29.8114400 / Ecliptic latitude of native pole |
RADE5A = 'FK5 ' / Mean IAU 1984 ecliptic coordinates |
EQUI5A = 2000.0 / Coordinate epoch |
END |
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 |
XTENSION= 'BINTABLE' / Binary table extension |
BITPIX = 8 / 8-bit bytes |
NAXIS = 2 / 2-dimensional binary table |
NAXIS1 = 5 / Width of table in bytes |
NAXIS2 = 10000 / Number of rows in table |
PCOUNT = 0 / Size of special data area |
GCOUNT = 1 / One data group (required keyword) |
TFIELDS = 3 / Number of fields in each row |
TTYPE1 = 'DATA_QUALITY' / Quality flag value of the photon |
TFORM1 = '1B ' / Data format of the field: 1-byte integer |
TTYPE2 = 'XPOS ' / Axis 1: pixel coordinate of the photon |
TFORM2 = '1I ' / Data format of column 2: I*2 integer |
TLMIN2 = 1 / Lower limit of axis in column 2 |
TLMAX2 = 2048 / Upper limit of axis in column 2 |
TTYPE3 = 'YPOS ' / Axis 2: pixel coordinate of the photon |
TFORM3 = '1I ' / Data format of column 3: I*2 integer |
TLMIN3 = 1 / Lower limit of axis in column 3 |
TLMAX3 = 2048 / Upper limit of axis in column 3 |
MJDOB3 = 44258.7845612 / MJD at start of observation |
COMMENT The following keywords define the primary coordinate description. |
TCRP2 = 1024.5 / Axis 1: reference pixel coordinate |
TCRP3 = -1023.5 / Axis 2: reference point pixel coordinate |
TPC2_2 = 1 / Transformation matrix element |
TPC2_3 = -0.004 / Transformation matrix element |
TPC3_2 = -0.002 / Transformation matrix element |
TPC3_3 = 1 / Transformation matrix element |
TCDE2 = -0.005 / Axis 1: scale |
TCDE3 = 0.005 / Axis 2: scale |
TCTY2 = 'GLON-COE' / Axis 1: conic equal area projection |
TCTY3 = 'GLAT-COE' / Axis 2: conic equal area projection |
TPV3_1 = -25.0 / Conic mid-latitude |
TCRV2 = 90.0 / Axis 1: galactic longitude at reference point |
TCRV3 = -25.0 / Axis 2: galactic latitude at reference point |
COMMENT The following keywords define the secondary coordinate description. |
TCRP2A = 1024.5 / Axis 1A: reference pixel coordinate |
TCRP3A = -1023.5 / Axis 2A: reference point pixel coordinate |
TP2_2A = 1 / Transformation matrix element |
TP2_3A = -0.004 / Transformation matrix element |
TP3_2A = -0.002 / Transformation matrix element |
TP3_3A = 1 / Transformation matrix element |
TCDE2A = -0.005 / Axis 1A: scale |
TCDE3A = 0.005 / Axis 2A: scale |
TCTY2A = 'ELON-COE' / Axis 1A: conic equal area projection |
TCTY3A = 'ELAT-COE' / Axis 2A: conic equal area projection |
TV3_1A = -25.0 / Conic mid-latitude |
TCRV2A = -7.0300934 / Axis 1A: ecliptic longitude at reference point |
TCRV3A = 34.8474143 / Axis 2A: ecliptic latitude at reference point |
LONP3A = 6.3839706 / Native longitude of ecliptic pole |
LATP3A = 29.8114400 / Ecliptic latitude of native pole |
RADE3A = 'FK5 ' / Mean IAU 1984 ecliptic coordinates |
EQUI3A = 2000.0 / Coordinate epoch |
END |
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 |
NAXIS = 2 / 2-dimensional image |
NAXIS1 = 181 / x axis (fastest) |
NAXIS2 = 91 / y axis (2nd fastest) |
CRPIX1 = 226.0 / Pixel coordinate of reference point |
CRPIX2 = 46.0 / Pixel coordinate of reference point |
CDELT1 = -1.0 / x-scale |
CDELT2 = 1.0 / y-scale |
CTYPE1 = 'GLON-CAR' / Plate carree projection |
CTYPE2 = 'GLAT-CAR' / Plate carree projection |
CRVAL1 = 30.0 / Galactic longitude at reference point |
CRVAL2 = 35.0 / Galactic latitude at reference point |
Observe that the image spans
in native longitude and
in
native latitude and that the reference pixel lies outside the image. In fact,
the reference pixel is located so that the native longitude runs from
to
and hence the image lies partly inside and partly
outside the normal range of native longitude, [
,
].
In fact, as might be expected, this makes no difference to the computation of
celestial coordinates. For example, in computing the celestial coordinates of
pixel (1,1) we readily find from Eqs. (83) and (84)
that the native coordinates are
.
The
fact that
exceeds
becomes irrelevant once
Eqs. (2) are applied since the trigonometric functions do not
distinguish between
and
.
The latter
value is the appropriate one to use if the cylinder of projection is
considered to be "rolled out'' over multiple cycles. Consequently the
correct galactic coordinates are obtained.
The problem only surfaces when we come to draw a coordinate grid on the image.
A meridian of longitude, for example, is traced by computing the pixel
coordinates for each of a succession of latitudes along the segment of the
meridian that crosses the image. As usual, in computing pixel coordinates,
the celestial coordinates are first converted to native coordinates by
applying Eqs. (5), and the native longitude will be returned in
the normal range [
]. Consequently, in those parts of
the image where
the pixel coordinates computed will
correspond to the point at
,
i.e. in the part of the
principle cycle of the cylindrical projection outside the image.
In principle it is possible to account for this, at least in specific cases,
particularly for the cylindrical projections which are somewhat unusual in
this regard. In practice, however, it is difficult to devise a general
solution, especially when similar problems may arise for projection types
where it is not desirable to track
outside its normal range. For
example, consider the case where a Hammer-Aitoff projection is used to
represent the whole sky; since its boundary is curved there will be
out-of-bounds areas in the corner of the image. Normally a grid drawing
routine can detect these by checking whether the inverse projection equations
return a value for
outside its normal range. It may thus determine the
proper boundary of the projection and deal with the discontinuity that arises
when a grid line passes through it.
How then should the header have been written? Note that the problem exists at
the lowest level of the coordinate description, in the conversion between
(x,y) and
,
and the solution must be found at this level.
The problem arose from a particular property of cylindrical projections in
that they have
.
We must use this same property, which we
might call "
-translation similarity'', to recast the coordinate
description into a more manageable form.
-translation similarity simply
means that changing the origin of
corresponds to shifting the image in
the x-direction. In other words, we can transfer the reference point of the
projection from its current location to another location along the native
equator without having to regrid the image. The fact that the PC i_ja
matrix is unity in this example makes this task a little simpler than
otherwise.
Note first that because the image straddles
we can't simply
reset CRPIX1 so as to shift the reference point to
;
the image would then straddle
,
which is no improvement. In
this example it is convenient and sufficient to shift the reference point to
,
which corresponds to pixel coordinate
(p1,p2) = (46.0,46.0). Hence we need to reset CRPIX1 to 46.0 and
adjust the keywords which define the celestial coordinate system. The reader
may readily verify that the galactic coordinates of the new reference point
are
and whereas the old, implied value of
LONPOLE was
when
,
now that
its
new implied value is
,
and this is correct. However, we will set it
explicitly anyway. The keywords to be changed are therefore
What if the PC i_ja matrix was not unity? The problem of determining the
pixel coordinates where
would have
presented little extra difficulty, although in general CRPIX2 would
also need to be changed. On reflection it may come as a surprise that
changing CRPIX j like this does not fundamentally alter the linear
transformation. However it may readily be verified that the only effect of
changing CRPIX j is to change the origin of the (x,y) coordinates.
This section considers the more difficult problem faced by FITS writers; that of constructing world coordinate system headers.
Example 1 is contrived to illustrate the general methods used in constructing a spherical coordinate representation. Paying homage to Claudius Ptolemy, it actually constructs a terrestrial coordinate grid for the Mediterranean region as seen from space.
Example 2 constructs headers for the infra-red dust maps produced by Schlegel et al. (1998) who regridded data from the COBE/DIRBE and IRAS/ISSA surveys onto two zenithal equal area projections.
Example 3 considers the case of long-slit optical spectroscopy. It is concerned in particular with solving the problem of producing three world coordinate elements for a data array of only two dimensions.
Example 4 constructs a dual coordinate description for an image of the moon and considers the problem of producing consistent scales for each. It also suggests an extension to deal with the rings of the planet Saturn.
Our first example of FITS header construction concerns satellite photography of the Earth. Figure 36 shows a part of the world which probably would have been recognizable to Claudius Ptolemy.
A satellite 2230 km immediately above Cairo aims its digital camera directly
towards Athens and adjusts the orientation and focal length to include Cairo
in the field near the bottom edge of the frame. The
pixel
CCD detector array employed by the camera is centered on its optical axis so
Athens is at pixel coordinate
(1024.5,1024.5). Cairo - at the satellite's
nadir - is later found to be at
(681.67,60.12). The task is to overlay a
terrestrial coordinate grid on this image.
For the sake of simplicity we will assume pin-hole camera optics. Figure 37 identifies the geometry as that of a tilted, near-sided zenithal perspective projection with the nadir at the reference point. The point of projection P corresponds to the pin-hole of the camera and the tilted plane of projection is parallel to the camera's focal plane F. The image in the focal plane is simply scaled (and inverted) with respect to that on the plane of projection. Clearly a tilted AZP projection is a better match to the geometry than SZP in this instance.
The satellite altitude of 2230 km is 0.350 Earth radii and since the
projection is near-sided we may immediately write
.
Determination of
requires knowledge of the coordinates of Cairo
and Athens
.
From spherical trigonometry
we may deduce that the angular separation between the two cities is
and also that Athens is on a bearing
west of north
from Cairo.
Now since Cairo is at the native pole of the projection the angular separation
between the two cities is just their difference in native latitude,
.
Using the sine rule in triangle PAO in
Fig. 37 we obtain
![]() |
(194) |
![]() |
Figure 37:
The geometry of Fig. 36. Cairo at C
is at the reference point of the projection with Athens at A.
The camera with aperture at P and focal plane F is
not drawn to scale, though the rest of the diagram is. Note that
![]() ![]() |
The obliqueness of this view of the Earth, occasioned by the fact that the
image is not oriented along a meridian, is handled partly via LONPOLE a and
partly as a bulk image rotation via PC i_ja. Note that these are not
complementary; they produce distinct effects since the tilted AZP
projection does not have point symmetry. Figure 37 shows the
situation - the generating sphere with Cairo at the native pole must be
oriented so that Athens is at native longitude
.
The native
longitude of the terrestrial pole (substituting for the celestial pole in this
example) is offset from this by the bearing of Athens from Cairo,
i.e.
.
Since Athens is at native longitude
its x-coordinate, like
Cairo's, must be zero. The inequality of the corresponding pixel coordinates
must have arisen by the satellite rotating the camera about its optical axis
thereby rotating the CCD detector in the focal plane. The angle of this bulk
rotation is readily deduced from the pixel coordinates of Athens and Cairo,
.
This rotation is to
be applied via PC i_ja. The direction of rotation is completely determined
by the requirement that Athens' x-coordinate be zero, regardless of the sign
of CDELT ia, and the resulting PC i_ja rotation matrix is shown below.
The reference pixel coordinates, CRPIX ja, were measured from the image and
the reference coordinates for Cairo, CRVAL ia, were obtained from an atlas,
so the last remaining unknowns are the scales, CDELT ia. From previous
calculations we know that Athens is at
and we may apply Eqs. (20) and (21) to
obtain
.
The distance in pixel coordinates between the
two cities is readily found to be 1023.5 so the y-scale must be
per pixel.
The x-scale cannot be determined like this since both cities have the same
x-coordinate. However, the x-, and y-scales must be equal because the
focal plane is parallel to the plane of projection and ray-tracing through the
pin-hole therefore results in an isotropic change of scale. Do not confuse
this with the statement made in Sect. 5.1.1 that with
the projection is not scaled true at the reference point; this refers to the
differential scale between (x,y) and
.
Though the image in the focal plane is inverted through the pin-hole, thus
indicating a negative scale, we can assume that the camera compensated by
reading out the CCD array in reverse order. Thus for the image of
Fig. 36 we make both of the CDELT ia positive in order to
have east to the right as befits a sphere seen from the outside. Putting this
all together we have
The following example comes from the
pixel infrared dust
maps produced by Schlegel et al. (SFD, 1998). The authors chose to
regrid data from the COBE/DIRBE and IRAS/ISSA maps onto two zenithal equal
area (ZEA) projections centered on the galactic poles. The projection
formula given in their Appendix C expressed in terms of standard 1-relative
FITS pixel coordinates (p1,p2) is
Consider now the coordinate description for the two-dimensional image formed
by a long slit spectrograph. We assume that the wavelength axis of length
1024 and dispersion
nm/pixel corresponds to the p1 pixel
coordinate, and the 2048 pixel spatial axis corresponds to p2. The slit is
centered on equatorial coordinates
and oriented at
position angle
measured such that when
the first spectrum is
northwards. We will assume that the telescope and spectrograph optics are
such that the distance along the slit is in proportion to true angular
distance on the sky with a separation between pixels of
arcsec.
We do not consider curvature of the slit here, that is a distortion of the
sort to be handled by the methods of Paper IV.
Equiscaling along the length of the slit together with the one-dimensional nature of the spatial geometry indicate that any projection could be used that is equiscaled along a great circle projected as a straight line. Many projections satisfy this criterion. However, in practice the zenithal equidistant (ARC) projection is the most convenient choice.
The one-dimensional spatial geometry may at first seem problematical, with
each point along the slit having a different
.
However, this
is easily handled by introducing a third, degenerate axis and introducing a
rotation. The rotation in position angle may be handled via the linear
transformation matrix. Moreover, since we've opted for a zenithal projection,
bearing in mind the discussion of Sect. 7.1, the rotation can
also be handled via
(i.e. LONPOLE). We will demonstrate
both methods.
Use of
is perhaps more straightforward, and the header may be
written without further ado:
To verify this representation we will test it with
,
,
and
for pixel coordinate
(1,1,1). The corresponding (s,x,y) coordinates are
.
The wavelength is therefore
.
From
Eqs. (15), (14), and (67) the native
longitude and latitude are
,
is always
,
and the value of
corresponds to an offset of
2047'' from the center of the slit as it should. From
Eqs. (2) the right ascension and declination are
,
which are in the correct
quadrant.
Most optical telescopes are better described by the TAN projection. In
this case the only difference in the header would be
As an alternative, the original header could also have been written with the
CTYPE i interchanged, so that the slit, still coincident with the
p2-axis, maps directly to the y-axis. The header would be as above but
with the following changes:
There are several practical ways to rewrite the header using the PC i_j or
CD i_j matrices. Looking first at the CD i_j form we have
As before, the main problem is to determine the correct angle of rotation.
For zenithal projections
by default, and referring to
the left side of Fig. 3 we see that this corresponds to the
y-axis. Thus when
we require a rotation of
to
transform the p2-axis onto the y-axis. For
we need to rotate
further so the angle of rotation is
.
Therefore, CDELT i and LONPOLE in the original header must be
replaced with
The PC i_j matrix formulation is similar but allows more flexibility in the way the scale is handled:
Arguably this is more amenable to human interpretation, especially if thoughtful comments are added.
The above six methods should all be regarded as equally legitimate. In fact, there are infinitely many ways to encode this header, though most would disguise the essential simplicity of the geometry.
Thompson (1999) has applied the methods of this paper to the definition of solar coordinates for a variety of coordinate systems. As the final header construction example we will consider a specific coordinate description for another solar system body, the Moon.
A short exposure plate taken at Sydney Observatory at 1:00 am on 15 February
1957 AEST (GMT +1000) of the full Moon near lunar perigee has been digitized
and converted to a
pixel image in FITS format. The scale
is
per pixel with the moon centered in the image, and it is desired
to construct a dual coordinate description. The first system is geocentric
apparent equatorial coordinates in a gnomonic projection. The second is
selenographic coordinates in a zenithal perspective projection attached to the
surface of the Moon.
The ephemeris gives the geocentric apparent right ascension of the Moon at the
time as
and declination as
.
Diurnal parallax would have caused the Moon to
appear slightly offset from this position as seen from Sydney Observatory, but
to a good approximation the coordinate systems may be defined with the center
of the Moon at the stated geocentric coordinates. The image was digitized in
the normal orientation with north up and east to the left so the header for
the primary description is straightforward:
Keyword | Type | Sect. | Use | Status | Comments |
LONPOLE a | floating | 2.2 | coordinate rotation | new | Longitude in the native coordinate system of the |
celestial system's north pole. | |||||
Default:
![]() ![]() ![]() |
|||||
LATPOLE a | floating | 2.4 | coordinate rotation | new | Latitude in the native coordinate system of the |
celestial system's north pole, or equivalently, the | |||||
latitude in the celestial coordinate system of the | |||||
native system's north pole. | |||||
Default:
![]() ![]() |
|||||
in which case it has no default. | |||||
RADESYS a | character | 3.1 | frame of reference | new | Reference frame of equatorial and ecliptic |
coordinates; recognized values are given in Table 2. | |||||
Default: FK4 if EQUINOX a < 1984.0, FK5 if | |||||
![]() |
|||||
EQUINOX a | floating | 3.1 | coordinate epoch | new | Epoch of the mean equator and equinox in years; |
Besselian if RADESYS a is FK4 or FK4-NO-E, | |||||
Julian if FK5; not applicable to ICRS or GAPPT. | |||||
Default: EPOCH if given, else 1950.0 if RADESYS a is FK4 | |||||
or FK4-NO-E, or 2000.0 if FK5. | |||||
EPOCH | floating | 3.1 | coordinate epoch | deprecated | Replaced by EQUINOX a. |
MJD-OBS | floating | 3.1 | time of observation | new | Modified Julian Date (JD - 2 400 000.5) of observation. |
Default: DATE-OBS if given, else no default. |
The first step in constructing the secondary description is to determine the
distance of the observer from the Moon. The ephemeris gives the equatorial
horizontal parallax as
,
corresponding to a distance
between the centers of the Earth and Moon of 55.91 Earth radii. However, the
observer may be closer or further away by up to one Earth radius depending on
location and time of day and this 2% effect is deemed worthy of correction.
At Sydney Observatory (longitude
,
latitude
)
the Greenwich apparent sidereal time was
.
Thus the apparent right ascension and
declination of the zenith was
,
.
The vector dot product then gives the distance
correction as 0.69 Earth radii. Using the ratio of the Earth and Moon radii
of 3.670 the corrected distance of 55.22 Earth radii indicates that the
distance parameter for the zenithal perspective projection is
Moon radii.
We now need to determine the correct relative scale. Figure 38
shows the geometry of the two projections where we note, by analogy with
Fig. 4, that .
From the diagram we have
![]() |
(196) |
The ephemeris records that the selenographic coordinates of the Earth at the
time were
and the position angle of the
Moon's axis was
.
However, since the Earth subtends an angle of
over
in the lunar sky, topocentric optical libration - the
correction for the observatory's location - is significant. Application of
the correction formulæ derived by Atkinson (1951) gives the
selenographic coordinates of Sydney Observatory as
and
.
Since the image was taken in the
normal orientation and we have a zenithal projection it is convenient to
account for the position angle by setting
.
Adopting keyword values of SELN and SELT for selenographic
coordinates we may write
As an extension of this example, a FITS header with three coordinate systems might be constructed for an image of Saturn; a celestial grid for the background, a saturnographic system for the surface of the planet, and a third system for its rings. The rings might be described by a zenithal equidistant (ARC) projection with associated linear transformation matrix set to match the oblique viewing angle.
FITS | Special | Projection parameters associated with
latitude![]() |
|||||||
Code | ![]() |
![]() |
properties | Projection name | PV i_0a | PV i_1a | PV i_2a | PV i_3a | PV i_ma |
AZP |
![]() |
![]() |
Sect. 5.1.1 | Zenithal perspective | ![]() |
![]() |
|||
SZP |
![]() |
![]() |
Sect. 5.1.2 | Slant zenithal perspective | ![]() |
![]() |
![]() |
||
TAN |
![]() |
![]() |
Sect. 5.1.3 | Gnomonic | |||||
STG |
![]() |
![]() |
Sect. 5.1.4, Conformal | Stereographic | |||||
SIN |
![]() |
![]() |
Sect. 5.1.5 | Slant orthographic | ![]() |
![]() |
|||
ARC |
![]() |
![]() |
Equidistant | Zenithal equidistant | |||||
ZPN |
![]() |
![]() |
Zenithal polynomial | P0 | P1 | P2 | P3 |
![]() |
|
ZEA |
![]() |
![]() |
Equiareal | Zenithal equal-area | |||||
AIR |
![]() |
![]() |
Sect. 5.1.9 | Airy |
![]() |
||||
|
![]() |
![]() |
Cylindrical perspective | ![]() |
![]() |
||||
CEA |
![]() |
![]() |
Equiareal | Cylindrical equal area | ![]() |
||||
CAR |
![]() |
![]() |
Equidistant | Plate carrée | |||||
MER |
![]() |
![]() |
Conformal | Mercator | |||||
|
![]() |
![]() |
Equiareal | Sanson-Flamsteed | |||||
PAR |
![]() |
![]() |
Equiareal | Parabolic | |||||
MOL |
![]() |
![]() |
Equiareal | Mollweide | |||||
AIT |
![]() |
![]() |
Equiareal | Hammer-Aitoff | |||||
|
![]() |
![]() |
Conic perspective |
![]() |
![]() |
||||
COE |
![]() |
![]() |
Equiareal | Conic equal-area |
![]() |
![]() |
|||
COD |
![]() |
![]() |
Equidistant | Conic equidistant |
![]() |
![]() |
|||
COO |
![]() |
![]() |
Conformal | Conic orthomorphic |
![]() |
![]() |
|||
|
![]() |
![]() |
Equiareal | Bonne's equal area | ![]() |
||||
PCO |
![]() |
![]() |
Polyconic | ||||||
|
![]() |
![]() |
Sect. 5.6.1 | Tangential Spherical Cube | |||||
CSC |
![]() |
![]() |
Sect. 5.6 | COBE Quadrilateralized Spherical Cube | |||||
QSC |
![]() |
![]() |
Sect. 5.6 | Quadrilateralized Spherical Cube |
Calabretta (1995) has written, and made available under a GNU license, a package of routines, WCSLIB, which implements all projections and coordinate conversions defined here. It contains independent C and Fortran libraries.
The Fortran library includes a routine, PGSBOX, which is based on PGPLOT and uses WCSLIB to draw general curvilinear coordinate axes. It was used to generate Fig. 36.
Copyright ESO 2002