next up previous 264
Next: Converting between Spectral Coordinate Systems
Up: An Introduction to Coordinate System Conversions
Previous: An Introduction to Coordinate System Conversions


Converting between Celestial Coordinate Systems

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:

  1. The old FK4 system, with no E terms, a Besselian epoch of 1958.0 and a Besselian equinox of 1960.0.

  2. An ecliptic coordinate system based on the mean equinox and ecliptic of Julian epoch 2010.5.

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:

      INCLUDE 'AST_PAR'
      INTEGER SKYFRAME1, SKYFRAME2, STATUS

      STATUS = 0

      ...

      SKYFRAME1 = AST_SKYFRAME( 'System=FK4-NO-E, Epoch=B1958, Equinox=B1960', STATUS )
      SKYFRAME2 = AST_SKYFRAME( 'System=Ecliptic, Equinox=J2010.5', STATUS )

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:

      INTEGER CVT

      ...

      CVT = AST_CONVERT( SKYFRAME1, SKYFRAME2, ' ', STATUS )
      IF ( CVT .EQ. AST__NULL ) THEN
         <conversion is not possible>
      ELSE
         <conversion is possible>
      END IF

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 ([*]), 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 ([*]).

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:

      INTEGER N
      DOUBLE PRECISION ALPHA1( N ), DELTA1( N )
      DOUBLE PRECISION ALPHA2( N ), DELTA2( N )

      ...

      CALL AST_TRAN2( CVT, N, ALPHA1, DELTA1, .TRUE., ALPHA2, DELTA2, STATUS )

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:

      CALL AST_TRAN2( CVT, N, ALPHA2, DELTA2, .FALSE., ALPHA1, DELTA1, STATUS )

The FrameSet returned by AST_CONVERT also contains information about the SkyFrames used in the conversion ([*]). 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:

      DOUBLE PRECISION DISTANCE, POINT1( 2 ), POINT2( 2 )

      ...

      DISTANCE = AST_DISTANCE( CVT, POINT1, POINT2, STATUS )

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 ([*]):

      CALL AST_SET( CVT, 'Report=1', STATUS )
      CALL AST_TRAN2( CVT, N, ALPHA1, DELTA1, .TRUE., ALPHA2, DELTA2, STATUS )

The output from this might look like the following:

(2:06:03.0, 34:22:39) --> (42.1087, 20.2717)
(2:08:20.6, 35:31:24) --> (43.0197, 21.1705)
(2:10:38.1, 36:40:09) --> (43.9295, 22.0716)
(2:12:55.6, 37:48:55) --> (44.8382, 22.9753)
(2:15:13.1, 38:57:40) --> (45.7459, 23.8814)
(2:17:30.6, 40:06:25) --> (46.6528, 24.7901)
(2:19:48.1, 41:15:11) --> (47.5589, 25.7013)
(2:22:05.6, 42:23:56) --> (48.4644, 26.6149)
(2:24:23.1, 43:32:41) --> (49.3695, 27.5311)
(2:26:40.6, 44:41:27) --> (50.2742, 28.4499)

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.18

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.



next up previous 264
Next: Converting between Spectral Coordinate Systems
Up: An Introduction to Coordinate System Conversions
Previous: An Introduction to Coordinate System Conversions

AST A Library for Handling World Coordinate Systems in Astronomy
Starlink User Note 210
R.F. Warren-Smith & D.S. Berry
24th May 2011
E-mail:ussc@star.rl.ac.uk

Copyright (C) 2009 Science \& Technology Facilities Council