Issue 256

[astrofle]

fix: add support for AzEl observations

Adds check for empty RADESYS column and functionality to handle AltAz (AzEl) coordinate frame

Still needs tests, but it can handle Issue #256.

[etsmit]

Two things:

1. Add more to the warning (either at the GBTFITSLoad step or when changing velocity frames) that the Az/El values are invalid and will result in an incorrect frequency shift. This could be detected as a separate case from drift scans by detecting when e.g. elevation <4.9. (Or when az/el values are unchanging?)
2. Possibly add the scan numbers corresponding to the blank radesys rows to the warning message, since the antenna manager can be taken in/out over the course of a session. For example, "No RADESYS specified for scans X,Y,Z; assuming AltAz"

[astrofle]

@etsmit I think I implemented your comments. Let me know if you think something else is needed.

Note for the future. This "fix" updates the 'RADESYS' column because that is what was being used downstream by the Spectrum objects to define their celestial coordinates. However, the definition of the 'RADESYS' column (Equatorial coordinate system name) makes it clear that this is not the right column to use to define the coordinate system (it only makes sense for equatorial coordinates). It might be better to use 'CTYPE2' and 'CTYPE3' to define the celestial coordinate system (this would avoid changing the definition of SDFITS), and only do this when a Spectrum object is being instantiated (to avoid the additional computations this fix introduces).

I will also note that:
/home/dysh/example_data/hadec/data/AGBT18B_342_01.raw.vegas/AGBT18B_342_01.raw.vegas.A.fits has a jump in elevation during scan 15, going from ~57 deg to 0 deg. No idea how @etsmit did that, but it is worth noting that in these cases we have no checks when doing operations like time averaging.

[astrofle]

The last update also adds support for HaDEC observations.

[astrofle]

@mpound is this fix acceptable?

[mpound]

Looks good to me.