In this section, we start to look at techniques for converting between different coordinate systems. At this stage, the tools we have available are Frames (§7), SkyFrames (§8), SpecFrames (§9), TimeFrames (§10) and various Mappings (§5). These are sufficient to allow us to begin examining the problem, but more sophisticated approaches will also emerge later (§14.2).
We begin by examining how to convert between two celestial coordinate systems represented by SkyFrames, as this is both an illuminating and practical example. Consider the problem of converting celestial coordinates between:
This example is arbitrary but not completely unrealistic. Unless you already have expertise with such conversions, you are unlikely to find it straightforward.
Using AST, we begin by creating two SkyFrames to represent these coordinate systems, as follows:
Note how specifying the coordinate systems consists simply of initialising the attributes of each SkyFrame appropriately. The next step is to find a way of converting between these SkyFrames. This is done using AST_CONVERT, as follows:
The third argument of AST_CONVERT is not used here and should be a blank string.
AST_CONVERT will return a null result, AST__NULL (as defined in the AST_PAR include file), if conversion is not possible. In this example, conversion is possible, so it will return a pointer to a new Object that describes the conversion.
The Object returned is called a FrameSet. We have not discussed FrameSets yet (§13), but for the present purposes we can consider them simply as Objects that can behave both as Mappings and as Frames. It is the FrameSet’s behaviour as a Mapping in which we are mainly interested here, because the Mapping it implements is the one we require—i.e. it converts between the two celestial coordinate systems (§14.1).
For example, if ALPHA1 and DELTA1 are two arrays containing the longitude and latitude, in radians, of N points on the sky in the original coordinate system (corresponding to SKYFRAME1), then they could be converted into the new coordinate system (represented by SKYFRAME2) as follows:
The new coordinates are returned via the ALPHA2 and DELTA2 arrays. To transform coordinates in the opposite direction, we simply invert the 5th (logical) argument to AST_TRAN2, as follows:
The FrameSet returned by AST_CONVERT also contains information about the SkyFrames used in the conversion (§14.1). As we mentioned above, a FrameSet may be used as a Frame and in this case it behaves like the “destination” Frame used in the conversion (i.e. like SKYFRAME2). We could therefore use the CVT FrameSet to calculate the distance between two points (with coordinates in radians) in the destination coordinate system, using AST_DISTANCE:
and the result would be the same as if the SKYFRAME2 SkyFrame had been used.
Another way to see how the FrameSet produced by astConvert retains information about the coordinate systems involved is to set its Report attribute (inherited from the Mapping class) so that it displays the coordinates before and after conversion (§4.8):
The output from this might look like the following:
Here, we see that the input FK4 equatorial coordinate values (given in radians) have been formatted automatically in sexagesimal notation using the conventional hours for right ascension and degrees for declination. Conversely, the output ecliptic coordinates are shown in decimal degrees, as is conventional for ecliptic coordinates. Both are displayed using the default precision of 7 digits.22
In fact, the CVT FrameSet has access to all the information in the original SkyFrames which were passed to AST_CONVERT. If you had set a new Digits attribute value for either of these, the formatting above would reflect the different precision you requested by displaying a greater or smaller number of digits.
The principles described in the previous section for converting between celestial coordinate systems also apply to the task of converting between spectral coordinate systems. As an example, let’s look at how we might convert between frequency measured in as measured in the rest frame of the telescope, and radio velocity measured in measured with respect the kinematic Local Standard of Rest.
First we create a default SpecFrame, and then set its attributes to describe the required radio velocity system (this is slightly more convenient, given the relatively large number of attributes, than specifying the attribute values in a single string such as would be passed to the SpecFrame constructor). We then take a copy of this SpecFrame, and change the attribute values so that the copy describes the original frequency system (modifying a copy, rather than creating a new SpecFrame from scratch, avoids the need to specify the epoch, reference position, etc a second time since they are all inherited by the copy):
Note, the fact that a SpecFrame has only a single axis means that we were able to refer to the Unit attribute without an axis index. The other attributes are: the time of of observation (Epoch), the geographical position of the telescope (ObsLat & ObsLon), the position of the source on the sky (RefRA & RefDec), the rest frequency (RestFreq) and the standard of rest (StdOfRest).
The next step is to find a way of converting between these SpecFrames. We use exactly the same code that we did in the previous section where we were converting between celestial coordinate systems:
A before, this will give us a FrameSet (assuming conversion is possible, which should always be the case for our example), and we can use the FrameSet to convert between the two spectral coordinate systems. We use AST_TRAN1 in place of AST_TRAN2 since a SpecFrame has only one axis (unlike a SkyFrame which has two).
For example, if FRQ is an array containing the observed frequency, in GHz, of N spectral channels (describe by SPECFRAME1), then they could be converted into the new coordinate system (represented by SPECFRAME2) as follows:
The radio velocity values are returned in the VEL array.
All the principles outlined in the previous section about aligning spectral cocordinate systems (SpecFrames) can be applied directly to the problem of aligning time coordinate systems (TimeFrames).
We can illustrate an important point if we swap the axis order of either SkyFrame in the example above (§12.1) before identifying the conversion. Let’s assume we use AST_PERMAXES (§7.9) to do this to the second SkyFrame, before applying AST_CONVERT, as follows:
Now, the destination SkyFrame system no longer represents the coordinate system:
(ecliptic longitude, ecliptic latitude)
but instead represents the transposed system:
(ecliptic latitude, ecliptic longitude)
As a consequence, when we use the FrameSet returned by AST_CONVERT to apply a coordinate transformation, we obtain something like the following:
When compared to the original (§12.1), the output coordinate order has been swapped to compensate for the different destination SkyFrame axis order.
In all, there are four possible axis combinations, corresponding to two possible axis orders for each of the source and destination SkyFrames, and AST_CONVERT will convert correctly between any of these. The point to note is that a SkyFrame contains knowledge about how to convert to and from other SkyFrames. Since its two axes (longitude and latitude) are distinguishable, the conversion is able to take account of the axis order.
If you need to identify the axes of a SkyFrame explicitly, taking into account any axis permutations, the LatAxis and LonAxis attributes can be used. These are read-only attributes which give the indices of the latitude and longitude axes respectively.
Having seen how clever SkyFrames are (§12.1 and §12.4), we will next examine how dumb a basic Frame can be in comparison. For example, if we create two 2-dimensional Frames and use AST_CONVERT to derive a conversion between them, as follows:
then the coordinate transformation which the “cvt” FrameSet performs will be as follows:
This is an identity transformation, exactly the same as a UnitMap (§5.10). Even if we permute the axis order of our Frames, as we did above (§12.4), we will fare no better. The conversion between our two basic Frames will always be an identity transformation.
The reason for this is that, unlike a SkyFrame, all basic Frames start life the same and have axes that are indistinguishable. Therefore, permuting their axes doesn’t make them look any different—they still represent the same coordinate system.
In practice, when AST is asked to find a conversion between two Frames describing two different coordinate systems on a given physical domain, it uses an intermediate “alignment” system. Thus, when finding a conversion from system A to system B, AST first finds the Mapping from system A to some alignment system, system C, and then finds the Mapping from this system C to the required system B. It finally concatenates these two Mappings to get the Mapping from system A to system B.
One advantage of this is that it cuts down the number of conversion algorithms required. If there are different Systems which may be used to describe positions within the Domain, then this approach requires about conversion algorithms to be written. The alternative approach of going directly from system A to system B would require about conversion algorithms.
In addition, the use of an intermediate alignment system highlights the nature of the conversion process. What do we mean by saying that a Mapping “converts a position in one coordinate system into the corresponding position in another”? In practice, it means that the input and output coordinates correspond to the same coordinates in some third coordinate system. The choice of this third coordinate system, the “alignment” system, can completely alter the nature of the Mapping. The Frame class has an attribute called AlignSystem which can be used to specify the alignment system.
As an example, consider the case of aligning two spectra calibrated in radio velocity, but each with a different rest frequency (each spectrum will be described by a SpecFrame). Since the rest frequencies differ, a given velocity will correspond to different frequencies in the two spectra. So when we come to “align” these two spectra (that is, find a Mapping which converts positions in one SpecFrame to the corresponding positions in the other), we have the choice of aligning the frequencies or aligning the velocities. Different Mappings will be required to describe these two forms of alignment. If we set AlignSystem to “Freq” then the returned Mapping will align the frequencies described by the two SpecFrames. On the other hand, if we set AlignSystem to “Vradio” then the returned Mapping will align the velocities.
Some choices of alignment system are redundant. For instance, in the above example, changing the alignment system from frequency to wavelength has no effect on the returned Mapping: if two spectra are aligned in frequency they will also be aligned in wavelength (assuming the speed of light doesn’t change).
The default value for AlignSystem depends on the class of Frame. For a SpecFrame, the default is wavelength (or equivalently, frequency) since this is the system in which observations are usually made. The SpecFrame class also has an attribute called AlignStdOfRest which allows the standard of rest of the alignment system to be specified. Similarly, the TimeFrame class has an attribute called AlignTimeScale which allows the time scale of the alignment system to be specified. Currently, the SkyFrame uses ICRS as the default for AlignSystem, since this is a close approximation to an inertial frame of rest.
22The leading digit is zero and is therefore not seen in this particular example.