From heafits@legacy.gsfc.nasa.gov Fri Jul 2 18:28:55 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA01027; Fri, 2 Jul 93 18:28:53 EDT Received: by inet-gw-2.pa.dec.com; id AA03601; Fri, 2 Jul 93 15:28:07 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA17319; Fri, 2 Jul 1993 18:26:20 -0400 Message-Id: <930702094346.2260dc39@NSSDCA.GSFC.NASA.GOV> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: "BARRY M. SCHLESINGER" Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "BARRY M. SCHLESINGER" Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: RE: PFSP Proposal for 2 new keywords: Note of a FITSBITS post Date: Fri, 2 Jul 1993 18:26:20 -0400 The reason for the delay on this answer is that I was away at a meeting for over a week after this message came out and have just gotten back to clearing up back mail. > Yet another recommendation of the OFSP meeting on 1993 Jun 16 was that > the OGIP change its use of the EXTNAME keyword, and that two new keywords > be introduced. > The OFSP found that it was common practice within the OGIP to use the value > of the EXTNAME keyword to simultaneously describe both the generic *kind* > of dataset being stored, and additional *details* of the dataset. Thus > values of the EXTNAME keyword were being formed by the concatination of 2 > or more sub-strings. This gives rise to long, and often user-unfriendly, > EXTNAMEs essentially containing a variety of different pieces of > information. Whilst such use of EXTNAME keyword is legal FITS, the OFSP proposes & recommends the adoption/use of the two keywords listed below. Since this is an issue likely to be of interest to the general FITS community, the OFSP would welcome any comments (via FITSBITS) on this proposal. Furthermore due to the pressures imposed by currently flying missions (ASCA, CGRO & ROSAT) there is an extremely urgent need for a convention for these keywords within the OGIP (& High-Energy community in general). The OFSP therefore plans to meet again in a couple of weeks to make its final recommendations. Thus BITFITS subscribers are urged to response with any comments etc on this timescale. THE PROPOSAL ************ The OFSP recommends the use of the EXTNAME keyword be changed (at least within the OGIP), and that two new keywords, EXTCLASS & EXTTYPE be introduced: EXTNAME - Can be any string & is essentially not used by OGIP s/w (NOTE: IRAF can only cope with 6 character strings) EXTCLASS - Is a new string describing the sort of dataset stored (see below) EXTTYPE - Is a new string available to give more specific details on exactly what type of data is stored (see below) A few examples should make the distinctions between the keywords more obvious: 1) For various "Good Time Intervals" EXTNAME = 'ABCBEF' (or whatever you like) EXTCLASS = 'GTI' (some sort of GTI is stored) EXTTYPE = 'STANDARD' (the GTIs from standard processing are stored) or EXTTYPE = 'ALL' (all times when the instrument is on are stored [no filtering has been applied]) or EXTTYPE = 'UNKNOWN' (uncertain what is stored) 2) For various "Events" lists EXTNAME = 'GHIJKL' (or whatever you like) EXTCLASS = 'EVENTS' (some sort of EVENTS list is stored) EXTTYPE = 'GOOD' (accepted events [only] are stored) or EXTTYPE = 'BAD' (rejected events [only] are stored) or EXTTYPE = 'ALL' (all events [no filtering] are stored) or EXTTYPE = 'UNKNOWN' (uncertain what events are stored) The two new keywords follow a logical hierachy, solve all the current problems, and seem general enough to give us (the OGIP, and general FITS community) flexibility in the future. ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Jun 17 From heafits@legacy.gsfc.nasa.gov Wed Jul 7 16:12:31 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3461" "Wed" "7" "July" "1993" "16:09:53" "-0400" "CORCORAN@ndadsb.gsfc.nasa.gov" "CORCORAN@ndadsb.gsfc.nasa.gov" nil "97" "REVISED OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "7"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA10213; Wed, 7 Jul 93 16:12:26 EDT Received: by inet-gw-2.pa.dec.com; id AA29816; Wed, 7 Jul 93 13:11:40 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA03589; Wed, 7 Jul 1993 16:09:53 -0400 Message-Id: <930707161159.22c06cbc@ndadsb.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: CORCORAN@ndadsb.gsfc.nasa.gov Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: REVISED OFSP proposal - SOURCE ID KEYWORDS Date: Wed, 7 Jul 1993 16:09:53 -0400 Source ID keywords: An OGIP FITS Standards panel (OFSP) proposal (REVISED) SUMMARY The following proposal represents a revision of a previous proposal which defined 3 keywords (CATID, CATREF and NCATREF) to be used to identify sources in FITS headers. As a result of comments from the HEAFITS group, the OFSP has decided to amend the proposal. We now propose a single keyword, CATID, which can be used to represent the catalog designation + the name of the source in the catalog. CATID may be indexed (CATIDn) to allow for alternate designations. The full text of the proposal can be found below. PROBLEM It is a common occurence that information in a FITS extension or file refers to a single astronomical object. In such cases it is necessary to be able to provide the source identification in the file or extension header. PROPOSAL * The OFSP proposes that source id be coded using the following header keyword: KEYWORD VALUE TYPE COMMENT CATIDn string name of source where "name of source" is generally composed of 2 parts: a catalog abbreviation + the entry of the source in the catalog. * Users are encouraged to use catalog abbreviations as given in the following articles (and future supplements) The First Dictionary of Nomenclature of Celestial Objects, Fernandez, Lortet, and Spite, 1983, A&AS, 52, No. 4. First Supplement to the Dictionary of Nomenclature..., Lortet and Spite, 1986, A&AS, 64, No. 2. COMMENT cards should translate any abbreviation which are used for catalogs not listed in these articles. Catalog abbreviations should be given with spaces replaced by underscores; one or more spaces should separate the catalog abbreviation from the source entry in the catalog. * It is also proposed that ancilliary information such as the reference to the catalog be embedded in COMMENT cards. This alleviates the need for definition of a new keyword and is sufficient since it is unlikely that software would ever have to access this information. EXAMPLES OF USAGE CATID = 'HD 153919' / identification of source COMMENT Henry Draper Catalog, Cannon, A., 1925 HCO Multiple id's are allowed: CATID1 = 'MPSLX 3' / identification of source COMMENT MPSLX = ROSAT MERGED SOURCE LIST for pointing CATID2 = 'HD 153919' / identification of source COMMENT Henry Draper Catalog, Cannon, A., 1925 HCO CATID3 = '4U 1700-37' / identification of source COMMENT 4th Uhuru catalog CAVEATS The CATID keyword, when indexed, should only be used to give alternative identifications to the SAME source. It is NOT to be used to give identifications to multiple sources in a given observation. COMMENTS Note that the CATID keyword is meant to augment, not replace, the standard OBJECT keyword. An obvious example is a ROSAT PSPC observation at the North Ecliptic Pole in which a serendipitous source is discovered. An extension which contains the spectrum of the serendipitious source would have the following keywords in its header: OBJECT = 'NORTH ECLIPTIC POLE' CATID = 'MPLSX 5' / source identification COMMENT MPSLX = ROSAT MERGED SOURCE LIST for pointing REQUEST FOR INPUT Please send comments on this proposal to the HEAFITS mail exploder before the next meeting of the OFSP scheduled for 21 Jul 1993. Cheers, Mike Corcoran The OFSP: Bill Pence, chair Ian George, Secretary Lorella Angelini Mike Corcoran Rich Fink Tom McGlynn Arnold Rots From heafits@legacy.gsfc.nasa.gov Fri Jul 9 09:42:20 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1106" "Fri" "9" "July" "1993" "09:39:40" "-0400" "Lee E. Brotzman" "leb@Hypatia.gsfc.nasa.gov " nil "33" "Re: REVISED OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "7"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA14908; Fri, 9 Jul 93 09:42:17 EDT Received: by inet-gw-2.pa.dec.com; id AA13373; Fri, 9 Jul 93 06:41:27 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA11495; Fri, 9 Jul 1993 09:39:40 -0400 Message-Id: <9307091339.AA01045@Hypatia.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: leb@Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: REVISED OFSP proposal - SOURCE ID KEYWORDS Date: Fri, 9 Jul 1993 09:39:40 -0400 > PROPOSAL > * The OFSP proposes that source id be coded using the following > header keyword: > > KEYWORD VALUE TYPE COMMENT > CATIDn string name of source > > where "name of source" is generally composed of 2 parts: a catalog > abbreviation + the entry of the source in the catalog. > I was just wondering what the "Default index" of an indexed keyword is, according to the NOST document (I'm at home and don't have my copy). Barry Schlesinger --- I know you're out there -- care to comment about the following usage of an indexed keyword? > EXAMPLES OF USAGE > CATID = 'HD 153919' / identification of source > COMMENT Henry Draper Catalog, Cannon, A., 1925 HCO I think that should be: CATID1 = 'HD 153919' Just to be unambiguous. Other than that I think this proposed convention is fine. (Thanks for including the references to Lortet and Spite.) -- -- Lee E. Brotzman Internet: leb@hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB@GIBBS From heafits@legacy.gsfc.nasa.gov Fri Jul 9 12:34:35 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA15802; Fri, 9 Jul 93 12:34:31 EDT Received: by inet-gw-2.pa.dec.com; id AA24386; Fri, 9 Jul 93 09:33:31 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA18446; Fri, 9 Jul 1993 12:31:44 -0400 Message-Id: <930709121948.2261633d@NSSDCA.GSFC.NASA.GOV> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "BARRY M. SCHLESINGER" Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: REVISED OFSP proposal - SOURCE ID KEYWORDS Date: Fri, 9 Jul 1993 12:31:44 -0400 >From the OFSP >> PROPOSAL >> * The OFSP proposes that source id be coded using the following >> header keyword: >> >> KEYWORD VALUE TYPE COMMENT >> CATIDn string name of source >> >> where "name of source" is generally composed of 2 parts: a catalog >> abbreviation + the entry of the source in the catalog. >> Lee Brotzman muses > I was just wondering what the "Default index" of an indexed keyword is, > according to the NOST document (I'm at home and don't have my copy). > Barry Schlesinger --- I know you're out there -- care to comment about the > following usage of an indexed keyword? You rang? >> EXAMPLES OF USAGE >> CATID = 'HD 153919' / identification of source >> COMMENT Henry Draper Catalog, Cannon, A., 1925 HCO >I think that should be: >CATID1 = 'HD 153919' > Just to be unambiguous. Other than that I think this proposed convention is > fine. (Thanks for including the references to Lortet and Spite.) The definition of "Indexed keyword" is "A keyword that is of the form of a fixed root with an appended integer count." That language would apply that the number should be there. We have a model to go by. NAXIS is a distinct keyword from the NAXISn. If we have one axis, we call it NAXIS1. Thus, if there is only one usage of the CATIDn keyword, it should be CATID1. Barry Schlesinger NOST FITS Support Office From server@athena.gsfc.nasa.gov Wed Sep 8 19:04:53 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1318" "Wed" "8" "September" "93" "18:56" "EDT" "William Pence" "pence@tetra.gsfc.nasa.gov " nil "34" "FITS celestial coordinate keywords." "^From:" nil nil "9"]) Return-Path: Received: from arupa.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA25441; Wed, 8 Sep 93 19:04:52 EDT Received: from athena.gsfc.nasa.gov by arupa.gsfc.nasa.gov (4.1/1.35) id AA11525; Wed, 8 Sep 93 19:03:49 EDT Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #2) id m0oaYRT-0003IKa; Wed, 8 Sep 93 18:56 EDT Message-Id: <9309082151.AA15503@tetra.gsfc.nasa.gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: pence@tetra.gsfc.nasa.gov (William Pence) Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: FITS celestial coordinate keywords. Date: Wed, 8 Sep 93 18:56 EDT The local OGIP FITS Panel has been attempting to invent some multi-mission FITS keywords to represent the celestial position of astronomical data sets. The following keywords have been proposed; any comments, complaints, or suggestions about this choice of keyword names are welcome. Note that these keywords are provided for general descriptive information and should not be used for precise position determination. These new keywords in no way replace the standard CRVAL, CRPIX, etc FITS keywords. Note also that not all of these keywords will be relevant for all observations (e.g. for observations taken with a scanning instrument) RA_OBJ / position of the object specified by the OBJECT keyword (degrees) DEC_OBJ / RA_NOM / nominal pointed position of the observation (degrees) DEC_NOM RA_PNT / actual pointed position of the optical axis (degrees) DEC_PNT / (or the mean value if the pointing is not stable) RA_PNTE / the 1-signa error on RA_PNT DEC_PNTE / the 1 sigma error on DEC_PNT PA_NOM / the nominal Position Angle (degrees from N to the E) PA_PNT / the actual measured Position Angle of the pointing PA_PNTE / the 1-sigma error on PA_PNT For a 2-D detector these position angles refer to the angle between the +Y axis of the image and North measured towards the East.