|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Mon 2007/07/23 15:03:43 -0400, William Pence wrote in a message to: FITSBITS Please post any comments, suggestions, or concerns regarding these proposals (or any other suggestions for improving the Standard document) here on the FITSBITS email list, or on the associated sci.astro.fits Sect. 8 looks like a very competent summary with plenty of evidence of careful work, well done Dick! The following comments are all minor: * In Table 8.1 and elsewhere the 'a' symbol used for the alternate code should be in math font. * p82: where CROTA2 is mentioned it should be stated in this context that, while it may occur with CDi_ja, it must not occur with PCi_ja. * Table 8.2: it would be better if RESTFREQ was presented in the same way as RADECSYS. A footnote describing these forms would be useful. * The note at the bottom of Table 8.2 reverses the meaning of i and j. In that note, k also refers to column number in a pixel list. * p86: There are a number of keywords, ijPCna, ijCDna, iVn_ma, and so on, where 'a' could be pushed right out of the 8-char keyword name for plausible values of i, j, k, n, and m. In such cases 'a' is still said to be "blank" although it is not the blank character. (This isn't really made clear in Paper I.) * p87: probably should indicate that no time system (UTC, TAI, TCB, etc.) is currently defined for MJD-OBS or any of the other time- related keywords. (This is not important for anything in the existing WCS papers.) * p90: "Vaccuum" * p91: the footnote mark doesn't appear anywhere in the table or caption. * p92: the reference to Table 8.6 should be 8.7. * p92: the discussion at the bottom should indicate that the diurnal Doppler correction is only weakly dependent on position and therefore great accuracy is not required. * p93 footnote: how could CUNITia (not CUNITka) substitute for VELOSYSa anyway? Or should the footnote really refer to the units of VELOSYSa specified later? * p93: in the description of ZSOURCEa, the reference to ZSOURCEa should be SSYSSRCa. General note: there are a few anomalies in the set of WCS keywords as published. The main one is that no bintable or pixel list equivalent of DATE-OBS is defined. Also, the pixel list form for WCSNAMEa was mistakenly specified as TWCSna instead of WCSNna. I can do no better than to append an extract of the usage notes for the WCSLIB 4.3 function wcshdo() (as yet unreleased) which writes out a WCS data structure as a FITS header. This might be a good opportunity to legitimise these extended usages - I note that Table 8.2 has already captured WCSHDO_TPC and WCSHDO_PV from the errata. Mark Calabretta ATNF * 8) wcshdo() interprets the "relax" argument as a vector of flag bits to * provide fine-grained control over what non-standard WCS cards to * write. The flag bits are subject to change in future and should be * set by using the preprocessor macros defined below for the purpose. * * WCSHDO_none: Don't use any extensions. * * WCSHDO_all: Write all recognized extensions, equivalent to setting * each flag bit. * * WCSHDO_safe: Write all extensions that are considered to be safe and * recommended. * * WCSHDO_DOBS: Write DOBSn, the column-specific analogue of DATE-OBS * for use in binary tables and pixel lists. WCS Paper III * introduced DATE-AVG and DAVGn but by an oversight DOBSn (the * obvious analogy) was never formally defined by the standard. * The alternative to using DOBSn is to write DATE-OBS which * applies to the whole table. This usage is considered to be * safe and is recommended. * * WCSHDO_TPC: Paper I defined * * TPn_ka and TCn_ka for pixel lists * * but Paper II uses TPCn_ka in one example and subsequently the * errata for the WCS papers legitimized the use of * * TPCn_ka and TCDn_ka for pixel lists * * provided that the keyword does not exceed eight characters. * This usage is considered to be safe and is recommended because * of the non-mnemonic terseness of the shorter forms. * * WCSHDO_PV: Paper I defined * * iVn_ma and iSn_ma for bintables and * TVn_ma and TSn_ma for pixel lists * * but Paper II uses iPVn_ma and TPVn_ma in the examples and * subsequently the errata for the WCS papers legitimized the * use of * * iPVn_ma and iPSn_ma for bintables and * TPVn_ma and TPSn_ma for pixel lists * * provided that the keyword does not exceed eight characters. * This usage is considered to be safe and is recommended because * of the non-mnemonic terseness of the shorter forms. * * WCSHDO_CRPX: For historical reasons Paper I defined * * jCRPXn, iCDLTn, iCRVLn, iCUNIn, and iCTYPn for bintables and * TCRPXn, TCDLTn, TCRVLn, TCUNIn, and TCTYPn for pixel lists * * for use without an alternate version specifier. However, * subject to the eight-character keyword constraint, in order to * accommodate column numbers greater than 99 it also defined * * jCRPna, iCDEna, iCRVna, iCUNna, and iCTYna for bintables and * TCRPna, TCDEna, TCRVna, TCUNna, and TCTYna for pixel lists * * for use with an alternate version specifier (the 'a'). Like * the PC, CD, PV, and PS keywords there is an obvious tendency * to confuse these two forms for column numbers up to 99. It * is very unlikely that a parser would reject keywords in the * first set with a non-blank alternate version specifier so this * usage is considered to be safe and is recommended. * * WCSHDO_CNAM: Papers I and III defined * * iCNAna, iCRDna, and iCSYna for bintables and * TCNAna, TCRDna, and TCSYna for pixel lists * * By analogy with the above the long forms would be * * iCNAMna, iCRDEna, and iCSYEna for bintables and * TCNAMna, TCRDEna, and TCSYEna for pixel lists * * This usage is potentially unsafe and is not recommended at * this time. * * WCSHDO_WCSN: Paper I mistakenly defined the pixel list form of * WCSNAMEa as TWCSna instead of WCSNna; the 'T' is meant to * substitute for the axis number in the binary table form of the * keyword - note that keywords defined in Papers II and III that * are not parameterised by axis number have identical forms for * binary tables and pixel lists. This usage is potentially * unsafe and is not recommended at this time. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] Proposed Changes to the FITS Standard | William Pence | FITS | 0 | July 27th 07 07:38 PM |
[fitsbits] Proposed Changes to the FITS Standard | Rob Seaman | FITS | 0 | July 24th 07 07:21 PM |
[fitsbits] Proposed Changes to the FITS Standard | William Pence | FITS | 2 | July 24th 07 04:57 AM |
[fitsbits] proposed FITS MIME types Internet Draft | Steve Allen | FITS | 0 | October 1st 03 05:49 AM |