Notes about the current WAPP SDfits file 20Jan04 mph CDELT1: Should be positive or negative depending on FLIP, i.e the "partial derivative of the coordinate specified by the CTYPEn keywords with respect to the pixel index, evaluated at the reference point CRPIXn, in units of the coordinate specified by the CTYPEn keyword." CRVALn: In general, these keywords should also have a CTYPEn keyword that describes them. CTYPE1: Axis type and doppler correction a) Appears non-standard (VDEF and VREF should be separate) b) Relationship to CRVAL1 unclear if CRVAL1 is center frequency of band CRVAL2,3: a) units state these are degrees but they are HHMMSS.S DDMMSS 1. Good idea to maintain a sign in the decl "+" or "-" 2. More standard is hh:mm:ss.s, Sdd:mm:ss, or degrees (sexagesimal or decimal) b) Meaning of "requested" unclear? 1) current values are of map center; this actually may be useful also, and so both are needed (need to track separate pixels within a map pattern) 2) but also need "commanded" pixel coordinate (i.e. where telescope is supposed to be, to distinguish it from coordinates derived from AZ,ZA) c) need EQUINOX keyword to indicate specification d) is any other coordinate system allowed? (galactic might be desired, possibly something else) CRVAL5: ("Hours since midnight from OBSDATE") a) Not enough precision? (purpose unclear to me in current units) b) Why not AST or UT? c) Reference point (start? middle? end?) OBSDATE: a) Purpose? Is this different from DATE-OBS? I think that DATE-OBS should refer to pixel, not time of file start; It would be more conventional if the "Date and Time of File Start" was referred to as keyword DATE (when file written) and DATE-OBS referred to time associated with the individual pixel. b) Should conform to Y2K compliant FITS standard 'yyy-mmm-dd' or 'yyy-mm-ddTHH:MM:DD[.sss]' RESTFREQ: "Rest frequency at band center" a) rest frequency should refer to selected spectral line VELOCITY: "Requested velocity" a) Meaning unclear. Does this mean: "corresponding to this band"? What frame? b) INCLUDE also VHELIO or VLSR if selected c) It would be nice to have the doppler correction information stored (V_SUN, V_LSR) for each pixel, even if it is not applied, so that you don't have to compute them later when you convert to velocities. LST: a) Non-standard timing format 'HH:MM:SS.SS' b) precision inadequate? c) Ref. helpful: Is this at start, middle, end? d) Also need UT OFF_RA,DEC,CS not implemented? a) does this refer to offset in a map? b) will this refer to central beam or individual beam? RAJ,DECJ: a) Should be RA, DEC and EQUINOX. b) Units wrong: They are radians; should be sexagesimal or decimal c) Coordinates appear to jump (according to some time stamp); should be smoother d) Need to know if this is start, middle or end. PATTERN_NAME, OBS_NAME, PATTERN_SCAN, OBS_NUM, OBST_TOT etc Need to keep track of various options; not sure it all works (confusing to me). a) Need designation of pattern parameters (center coordinates, strip number, offsets, etc) as well as CAL cycle, etc.) within a single map. Should be tracked if map constructed over several observing setups/sessions. Other things: a) Need an indication of names of other WAPPs/files belonging to the same observation (Helpful for bookkeeping & spectrum/map construction) b) Rotation angle of ALFA c) A position should be recorded separately for each beam which corresponds to that pixel in eventual map. d) Would be nice to have AZIMUTH and ZENANG of source at each pixel. Note added 10Feb03: See also the latest version of the draft "Representations of spectral coordinates in FITS" document currently under development by Greisen et al. It can be found at the bottom of Eric Greisen's home page. The 28Jan04 version is at http://www.aoc.nrao.edu/~egreisen/scs_012804.pdf.