Solar coordinates

[William Thompson]

Before I left for Christmas vacation, there was some talk about how to store
solar data in FITS files using the WCS formalism.  Unfortunately, those
messages are gone from the usenet server, and there appears to be something
wrong with the traffic archive on fits.cv.nrao.edu, so I'll have to work from
memory on this.

As I see it, there are three coordinate systems relevant to solar data.  One of
the things that was originally not evident to me was that they all share the
same PC matrix.  This is because, although the coordinate systems are rotated
with respect to each other, the rotation is out of the plane of observation.
Much of my earlier confusion was because I was thinking of these coordinate
systems as requiring different PC matrices for each.  Also, it wasn't obvious
to me that the same PC matrix would be applied to the secondary axis
descriptions as well as the primary ones.  That should perhaps be made clearer
in the documentation.

The three main coordinate systems are:


I.  Heliographic coordinates.

This is a spherical coordinate system, well described by Mark Calabretta's
earlier message.  The one point of ambiguity is that the sun actually has
several spherical "surfaces" of interest.  What is most commonly understood as
the surface of the sun is the photospheric surface, which is well defined at
most visible wavelengths.  However, for some wavelengths, a more appropriate
surface to use in describing the data is the base of the chromosphere, which is
perceptibly above the photospheric limb.  Other heights may be appropriate for
other data.

This ambiguity could be removed by including an additional keyword to define
exactly what surface is meant.  I suggest that the keyword SOLAR_R be defined
as an optional keyword whose meaning would be the apparent solar radius in
kilometers of the surface used in determining the solar latitude and longitude.
If omitted, the default value would be the photospheric value.


II.  Heliocentric coordinates.

This is a three-dimensional X,Y,Z coordinate system which is defined to have
the following characteristics:

	1.  The Z axis points from sun center towards the observer.

	2.  The Y axis is perpendicular to the Z axis, and lies in the plane
	    containing the Z axis and the solar north rotational axis.

	3.  The X axis is perpendicular to both the Y and Z axes, and completes
	    the right-handed coordinate system.  It points towards the west
	    (right) solar limb.

It is not a spherical coordinate system.  The Z coordinate is, of course, not
observed.  In my opinion, this is the primary coordinate system for coaligning
solar data taken at different observatories.

In a strict formal sense, no solar observations are ever made directly in this
coordinate system, but it is generally treated as if it did.  The important
assumption is made that the distance from the observer to the object is large
compared to any of the dimensions of the object.  This is similar to the
assumption that -mu >> 1 in Mark Calabretta's message.

Traditionally, data in this coordinate system is given in one of three
different units:

Arcsec (or arcmin): Actually, what is meant here is not the angle itself, but
	the tangent of the angle.  Expressing the data in arcsec or arcmin is
	really an expression of the fact that one is operating in the regime of
	the small angle approximation.  Since this isn't truly a spherical
	coordinate system, the use of these pseudo-angular dimensions is not
	really in the spirit of the WCS.  Also, the advent of spacecraft
	observing the sun from beyond low earth orbit, such as SOHO, means that
	the apparent angular size of the sun can be different for different
	sets of data.  For example, SOHO sees a 1% larger sun than ground-based
	observatories.

Solar radii: It's common to speak of data as being so many solar radii out from
	disk center.  This is used for both on-disk data (0-1) and for off-limb
	data (>1).  In Mark Calabretta's earlier message, it was suggested that
	the PC matrix be defined in such a way that it converted the data into
	units relative to the solar radius.  However, I don't see where this is
	necessary.  In order to properly express the position of the center of
	the sun, one needs proper CRPIXn and CRVALn values (or CmPIXn and
	CmVALn values).  Those keywords imply that one also has a corresponding
	CDELTn (or CmELTn) keyword, so I don't see any utility in using the PC
	matrix to force CmELTn to be 1.  Also, the coordinate system calls for
	the full complement of axis description keywords, including CTYPEn and
	CUNITn (CmYPEn/CmUNIn).  It shouldn't be a "poor sister" of the
	heliographic coordinate system.

	Another objection to using the PC matrix to convert the data into solar
	radii is that it appears to go against the sense of the PC matrix.
	According to the documentation, the PC matrix is intended to serve as a
	rotation/skew transformation--the conversion to physical units is
	supposed to be done with the CDELTn/CmELTn keywords.

	Note also that expressing the data in solar radii suffers from the same
	potential ambiguity as the heliographic coordinate system as to exactly
	what radius is meaningful for the data.

	My suggestion is that the part about using the PC matrix to normalize
	the coordinates be removed from the PLON/PLAT proposal.

Kilometers: Expressing the data as a physical distance removes all ambiguity
	due to either observing distance or to solar radius definition.


III.  "Helioprojective" coordinates

For some data, the small angle approximation can no longer be maintained, and
the fact that one is seeing the sun projected against the celestial sphere
cannot be ignored.  Such data require a modification to the heliocentric
coordinate system, to convert it into a spherical system.  Such a coordinate
system would have the following properties:

1.  The solar disk center would be on the equator at latitude and longitude
both equal to zero.

2.  The projection of the solar north polar axis would be on the great circle
representing zero longitude, on the positive side.

Since this is a spherical coordinate system, the units would be in degrees.

I'm not sure what to call this system, which is why I put the name above in
quotation marks.


A very important point is that all three of the above coordinate systems use
the same PC matrix.  This makes it possible to have a combination of these
coordinates occur in the same FITS file.  Mark Calabretta's suggestion was to
have the primary coordinate system be heliographic, and then one could have the
secondary coordinate system be heliocentric.  Is it also possible to do it the
other way around?  To my mind the heliocentric system is a more direct
representation of the data, and the heliographic coordinates are a more derived
quantity.  However, I wasn't sure if the keywords LONGPOLE, etc. applied to the
secondary coordinates as well.  The sentence in the WCS documentation that

	The alternate coordinate descriptions are computed in the same fashion
	as the primary coordinates.

would appear to imply that they did, in the same sense as the PC matrix.

William Thompson