A Frame which is specialised for representing coordinate systems on the celestial sphere is obviously of great importance in astronomy. The SkyFrame is such a Frame. In this section we examine the additional properties and behaviour of a SkyFrame that distinguish it from a basic Frame (§7).
A SkyFrame is, of course, a Frame (§7) and also a Mapping (§5), so it inherits all the properties and behaviour of these two ancestral classes. When used as a Mapping, a SkyFrame implements a unit transformation, exactly like a basic Frame (§7.3) or a UnitMap, so this aspect of its behaviour is not of great importance.
When used as a Frame, however, a SkyFrame represents a 2-dimensional spherical coordinate system, in which the shortest distance between two points is a great circle. A SkyFrame therefore always has exactly two axes which represent the longitude and latitude of a coordinate system residing on the celestial sphere. Many such coordinate systems can be represented by a SkyFrame, as we will see shortly.
A SkyFrame can represent any of the commonly used celestial coordinate systems. Optionally, the origin of the longitude/latitude system can be moved to any specified point in the standard celestial system, allowing a SkyFrame to represent offsets from a specified sky position.
When it is first created, a SkyFrame’s axes are always in the order (longitude, latitude) but this can be changed, if required, by using the astPermAxes function (§7.9). The order of the axes can be determined at any time using the LatAxis and LonAxis attributes. A SkyFrame’s coordinate values are always stored as angles in (double precision) radians, regardless of the setting of the Unit attribute 16.
The SkyFrame constructor function is particularly simple and a SkyFrame with default attributes is created as follows:
Such a SkyFrame would represent the default celestial coordinate system which, at present, is the ICRS system (the default was "FK5(J2000)" in versions of AST prior to 3.0).
For many purposes, the ICRS coordinate system is perfectly adequate. In order to support conversion between a variety of celestial coordinate systems, however, you can create SkyFrames that represent any of these.
Selection of a particular coordinate system is performed simply by setting a value for the SkyFrame’s (character string) System attribute. This setting is most conveniently done when the SkyFrame is created. For example, a SkyFrame representing the old FK4 (B1950.0) coordinate system would be created by:
Note that specifying “SystemFK4” also changes the associated equinox (from J2000.0 to B1950.0). This is because the default value of the SkyFrame’s Equinox attribute (§8.4) depends on the System attribute setting.
You may change the System value at any time, although this is not usually needed. The values supported are set out in the attribute’s description in Appendix C and include a variety of equatorial coordinate systems, together with ecliptic and galactic coordinates.
General spherical coordinates are supported by specifying “Systemunknown”. You should note, though, that no Mapping can be created to convert between “unknown” coordinates and any of the other celestial coordinate systems (see §12 ).
Many celestial coordinate systems have some additional free parameters which serve to identify a particular coordinate system from amongst a broader class of related coordinate systems. For example, the FK5 (J2010.0) system is distinguished from the FK5 (J2000.0) system by a different equinox—and the coordinates of a fixed astronomical source would have different values when expressed in these two systems.
In AST, these free parameters are represented by additional SkyFrame attributes, each of which has a default appropriate to (i.e. defined by) the setting of the main System attribute. Each of these qualifying attributes may, however, be assigned an explicit value so as to select a particular coordinate system. Note, it is usually best to assign explicit values whenever possible rather than relying on defaults. Attribute should only be left at their default value if you “don’t care” what value is used. In certain circumstances (particularly, when aligning two Frames), a default value for an attribute may be replaced by the value from another similar Frame. Such value replacement can be prevented by assigning an explicit value to the attribute, rather than simply relying on the default.
The main SkyFrame attributes which qualify the System attribute are:
Coordinates expressed in any of these systems vary with time due to movement (by definition) of the coordinate system itself, and must therefore be qualified by a moment in time (the epoch of the mean equinox, or “equinox” for short) which specifies the position of the model coordinate system on the sky. This is the role of the Equinox attribute.
Note that it is quite valid and common to relate the position of a source to an equinox other than the date of observation. Usually a standard equinox such as J2000.0 is used, meaning that the coordinates are referred to axes defined by where the model mean equator and ecliptic would lie on the sky at the Julian epoch J2000.0.
For further details of these attributes you should consult their descriptions in Appendix C and for details of the System settings for which they are relevant, see the description of the System attribute (also in Appendix C). For the interested reader, an excellent overview of celestial coordinate systems can also be found in the documentation for the SLALIB library (SUN/67).
The value of these qualifying attributes is most conveniently set at the same time as the System value, e.g. when a SkyFrame is created. For instance:
would create a SkyFrame representing an ecliptic coordinate system referred to the mean equinox and ecliptic of Julian epoch J2005.5.
Note that it does no harm to assign values to qualifying attributes which are not relevant to the main System value. Any such values are stored, but are not used unless the System value is later set so that they become relevant.
The default values supplied for many SkyFrame attributes will depend on the value of the SkyFrame’s System attribute. In practice, this means that there is usually little need to specify many of these attributes explicitly unless you have some special requirement. This can be illustrated by using astShow to examine a SkyFrame, as follows:
The output from this might look like the following:
Note that the defaults (indicated by the “#” comment character at the start of the line) for attributes such as the Title, axis Labels and Format specifiers are all set to values appropriate for the particular equatorial coordinate system that the SkyFrame represents.
This means, for example, that if we were to use this SkyFrame to format a right ascension value stored in radians using astFormat (§7.6), it would automatically result in a string in sexagesimal notation (such as “12:14:35.7”) suitable for display. If we changed the value of the SkyFrame’s Digits attribute (which is inherited from the Frame class), the number of digits appearing would also change accordingly.
These choices would be appropriate for a System value of “FK4-NO-E”, but if a different System value were set, the defaults would be correspondingly different. For example, ecliptic longitude is traditionally expressed in degrees, so setting “System=ecliptic” would result in coordinate values being formatted as degrees by default.
Of course, if you do not like any of these defaults, you may always over-ride them by setting explicit attribute values yourself.
SkyFrames use astFormat for formatting coordinate values in the same way as other Frames (§7.6). However, they offer a different set of formatting options more appropriate to celestial coordinates.
The Digits attribute of a SkyFrame behaves in essentially the same way as for a basic Frame (§7.6), so the precision with which celestial coordinates are displayed can also be adjusted in this way. However, the range of format specifiers that can be given for the Format(axis) attribute, and the default format resulting from any particular Digits value, is different.
The syntax of SkyFrame format specifiers is detailed under the description of the Format(axis) attribute in Appendix C. Briefly, however, it allows celestial coordinates to be expressed either as angles or times and to include one or more of the fields:
with a specified number of decimal places for the final field. A range of field separators is also available, as the following examples show:
|Format Specifier||Example Formatted Value|
|bdms.2||219 05 42.81|
Note the following key points:
.” followed by an integer. An asterisk can be used in place of an integer, in which case the number of decimal places is chosen so that the total number of digits in the formatted value is equal to the value of the Digits attribute.
The formatting performed by a SkyFrame is also influenced by the AsTime(axis) attribute, which has a boolean (integer) value for each SkyFrame axis. It determines whether the default format specifier for an axis will present values as angles (e.g. in degrees) if it is zero, or as times (e.g. in hours) if it is non-zero.
The default AsTime value depends on the celestial coordinate system which the SkyFrame represents which, in turn, depends on its System attribute value. For example, equatorial longitude values (right ascension) are normally expressed in hours, whereas ecliptic longitudes are normally expressed in degrees, so their default AsTime values will reflect this difference.
The value of the AsTime attribute may be set explicitly to over-ride these defaults if required, with the formatting precision being determined by the Digits/Digits(axis) value. Alternatively, the Format(axis) attribute may be set explicitly to specify both the format and precision required. Setting an explicit Format value always over-rides the effects of both the Digits and AsTime attributes (unless the Format value does not specify the required number of decimal places, in which case Digits is used to determine the default number of decimal places)
The process of converting formatted celestial coordinates, such as might be produced by the astFormat function (§8.6), into numerical (double) coordinate values is performed by using astUnformat (§7.8) and passing it a pointer to a SkyFrame. The use of a SkyFrame means that the range of input formats accepted is appropriate to positions on the sky expressed as angles and/or times, while the returned value is in radians.
The following describes the forms of celestial coordinate which are supported:
|m||–||minutes (of arc or time)|
|s||–||seconds (of arc or time)|
Either lower or upper case may be used. Fields must be given in order of decreasing significance
(e.g. “11D 3
Incompatible angle/time identification characters may not be mixed (e.g. “10h14
"” is not
valid). The remaining field identification characters and separators do not specify a preference
for an angle or a time and may be used with either.
|10d12||–||degrees and arc-minutes|
| 11:14||–||arc-minutes and arc-seconds|
|9h13s||–||hours and seconds of time|
|:45:33||–||minutes and seconds (of arc or time)|
|:55:||–||minutes (of arc or time)|
|::13||–||seconds (of arc or time)|
|6::2.5||–||degrees/hours and seconds (of arc or time)|
|07m14||–||minutes and seconds (of arc or time)|
| 8:14||–||degrees and arc-minutes|
|h3:14||–||minutes and seconds of time|
|h:2.1||–||seconds of time|
This final convention is intended to ensure that values formatted by astFormat which contain less than three fields will be correctly interpreted if read back using astUnformat, even if they do not contain field identification characters. However, it also affects other forms of input. For example, if the Format(axis) string were set to “mst.1” (producing two fields representing minutes and seconds of time), then formatted input would be interpreted by astUnformat as follows:
|12 13||–||minutes and seconds|
|1 2 3||–||hours, minutes and seconds|
| 4 ||–||arc-minutes|
(in the last four cases, explicit field identification has been given which overrides the implicit identification).
Alternatively, if the Format(axis) string were set to “s.3” (producing only an arc-seconds field), then formatted input would be interpreted by astUnformat as follows:
|12 13||–||arc-minutes and arc-seconds|
|1 2 3||–||degrees, arc-minutes and arc-seconds|
In general, if you are preparing formatted input data containing celestial coordinates and wish to omit certain fields, then you are advised to identify clearly those that you do provide by using the appropriate field identification characters and/or extra colon separators. This prevents you depending on the implicit field identification described above which, in turn, depends on an appropriate Format(axis) string having been set.
When writing software, it is also a good idea to set the Format(axis) string so that data input will be as simple as possible for the user. Unless some special effect is desired, this normally means that it should contain “d” or “h” to ensure that the first field entered by the user will be interpreted as degrees or hours, unless otherwise identified. This is the normal behaviour unless an explicit Format(axis) value has been set to override the default.
A SkyFrame can be modified so that its longitude and latitude axes are referred to an origin at any specified sky position. Such a coordinate system is referred to as an “offset” coordinate system. First, the System attribute should be set to represent the celestial coordinate system in which the origin is to be specified. Then the SkyRef attribute should be set to hold the coordinates of the origin within the selected celestial coordinate system.
By default, “north” in the new offset coordinate system is parallel to north in the original celestial coordinate system. However, the direction of north in the offset system can be controlled by assigning a value to the SkyRefP attribute. This attribute should be assigned the celestial coordinates of a point which is on the zero longitude meridian and which has non-zero latitude.
By default, the position given by the SkyRef attribute is used as the origin of the new longitude/latitude system, but an option exists to use it as the north pole of the system instead. This option is controlled by the SkyRefIs attribute. The choice of value for SkyRefIs depends on what sort of offset coordinate system you want. Setting SkyRefIs to “Origin” (the default) produces an offset coordinate system which is approximately Cartesian close to the specified position. Setting SkyRefIs to “Pole” produces an offset coordinate system which is approximately Polar close to the specified position.
16The units used for the internal floating-point representation of an axis value can be determined by examining the
InternalUnit attribute of the Frame. For most Frames, the Unit and InternalUnit attributes will be equal, but InternalUnit is
always set to “
rad” for SkyFrames.