Before we can write processed WCS information held in a FrameSet back
into a FitsChan in preparation for output, we must select the FITS
encoding to use. Unfortunately, we cannot simply depend on the
default value of the Encoding attribute, as we did when reading the
input information (), because the
destructive action of reading the WCS data
(
) will have altered the FitsChan's
contents. This, in turn, will have changed the choice of default
encoding, probably causing it to revert to NATIVE.
We will return to the question of the optimum choice of encoding
below. For now, let's assume we want to use the same encoding for
output as we used for input. Since we enquired what that was before we
read the input WCS data from the FitsChan
(), we can now set that value
explicitly. We can also set the FitsChan's Card attribute back to 1 at
the same time (because the write will fail if the FitsChan is not
rewound). AST_WRITE can then be used to write the output WCS
information into the FitsChan:
INTEGER NOBJ ... CALL AST_SET( FITSCHAN, 'Card=1, Encoding=' // ENCODE, STATUS ) NOBJ = AST_WRITE( FITSCHAN, WCSINFO, STATUS )
The value returned by AST_WRITE (assigned to NOBJ) indicates how many Objects were written. This will either be 1 or zero. A value of zero is used to indicate that the information could not be encoded in the form you requested. If this happens, nothing will have been written.
If your choice of encoding proves inadequate, the probable reason is that the changes you have made to the FrameSet have caused it to depart from the data model which the encoding assumes. AST knows about the data model used by each encoding and will attempt to simplify the FrameSet you provide so as to fit into that model, thus relieving you of the need to understand the details and limitations of each encoding yourself.28 When this attempt fails, however, you must consider what alternative encoding to use.
Ideally, you would probably want to try a sequence of alternative encodings, using an approach such as the following:
* 1. CALL AST_SET( FITSCHAN, 'Card=1, Encoding=FITS-WCS', STATUS ) IF ( AST_WRITE( FITSCHAN, WCSINFO, STATUS ) .EQ. 0 ) THEN * 2. CALL AST_SETC( FITSCHAN, 'Encoding', ENCODE, STATUS ) IF ( AST_WRITE( FITSCHAN, WCSINFO, STATUS ) .EQ. 0 ) THEN * 3. CALL AST_SET( FITSCHAN, 'Encoding=NATIVE', STATUS ) NOBJ = AST_WRITE( FITSCHAN, WCSINFO, STATUS ) END IF END IF
That is:
An alternative approach might be to encode the WCS information in several ways, since this gives the maximum chance that other software will be able to read it. This approach is only possible if there is no significant conflict between the FITS keywords used by the different encodings29. Adopting this approach would simply require multiple calls to AST_WRITE, rewinding the FitsChan and changing its Encoding value before each one.
Unfortunately, however, there is a drawback to duplicating WCS information in the FITS header in this way, because any program which modifies one version of this information and simply copies the remainder of the header will risk producing two inconsistent sets of information. This could obviously be confusing to subsequent software. Whether you consider this a worthwhile risk probably depends on the use to which you expect your data to be put.
AST A Library for Handling World Coordinate Systems in Astronomy