From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 1 10:19:59 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA13320 for fitsbits-spinner; Thu, 1 Apr 1999 10:18:37 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA13315 for ; Thu, 1 Apr 1999 10:18:34 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA21729 for fitsbits at majordomo.cv.nrao.edu; Thu, 1 Apr 1999 10:18:33 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA13299 for ; Thu, 1 Apr 1999 10:17:29 -0500 (EST) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id KAA21713 for ; Thu, 1 Apr 1999 10:17:29 -0500 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA10276 for ; Thu, 1 Apr 1999 10:17:27 -0500 Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3) id sma010142; Thu Apr 1 10:17:25 1999 Received: from xebec.harvard.edu (xebec [131.142.52.100]) by head-cfa.harvard.edu (8.9.1a/8.9.0) with ESMTP id KAA03847; Thu, 1 Apr 1999 10:10:11 -0500 (EST) From: Arnold Rots Received: (from arots at localhost) by xebec.harvard.edu (8.9.1/8.9.0) id KAA18249; Thu, 1 Apr 1999 10:10:10 -0500 (EST) Message-Id: <199904011510.KAA18249 at xebec.harvard.edu> Subject: Re: wcs.ps In-Reply-To: <199903312117.QAA25164 at primate.cv.nrao.edu> from Eric Greisen at "Mar 31, 99 04:17:52 pm" To: egreisen at valen.cv.nrao.edu (Eric Greisen) Date: Thu, 1 Apr 1999 10:10:09 -0500 (EST) Cc: fitsbits at fits.cv.nrao.edu X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric, A few more comments on the WCS paper. Units: When we introduced the ADU for Chandra/AXAF files, last year, it was decided to use the string "adu", in lower case. Since that has been written into a lot of software already, it would be helpful - to us, at least - if you could also define that string as lower case. I noticed that your list was missing the unit that is dear to many HEA types' hearts: the "Crab". Even though it's listed in the Chandra FITS guide, I'm not sure I'd really want to argue for its inclusion in your list. ;-) Coordinates in binary tables: I think it would be good to split the BINARY vector column in Table 7 also into new and old, where old is the convention that HEASARC adopted a number of years ago and that got incorporated into the RXTE archive: jCTYPn, jCUNIn, jCRVLn, jCRPXn, jCDLTn. I know, that makes it hard to fit into one text column, but ... My recollection was that the old Pixel List increment was TCDLTn, not TCDELn. I would suggest changing the Vector increment keyword, in view of these older forms, to jCDLns, rather than jCDEns. In general, I would argue for accepting CDELTjs, jCDLns, and TCDLns as plain synonyms for, respectively, CDj_js, jjCDns, and TCn_ns (rather than deprecating some of them), just to have uniform rules for all of them (I hope I'm not opening a can of worms here); with the restriction that one cannot mix increments with a matrix: increments are ignored when any CD matrix element is present. I was trying not to get confused by the indices in Tables 1 and 7; but shouldn't, in the latter, TCRPns be TCRPks? It took me a while, but I can see the rationale for the trio PVj_ms, jPm_ns, and TPm_ns. It is unfortunate that, in an effort to keep the column number at the end, this clashes internally. Maybe one should consider jPn_ms and TPn_ms; I have my doubts whether these will ever become popular. - Arnold -------------------------------------------------------------------------- Arnold H. Rots AXAF Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 81 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 1 10:50:38 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA13462 for fitsbits-spinner; Thu, 1 Apr 1999 10:50:21 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA13457 for ; Thu, 1 Apr 1999 10:50:18 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA21976 for fitsbits at majordomo.cv.nrao.edu; Thu, 1 Apr 1999 10:50:17 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA13446 for ; Thu, 1 Apr 1999 10:49:43 -0500 (EST) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id KAA21958 for ; Thu, 1 Apr 1999 10:49:42 -0500 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA03778 for ; Thu, 1 Apr 1999 10:49:41 -0500 Received: from amon.u-strasbg.fr(130.79.200.3) by palantir.cv.nrao.edu via smap (V1.3) id sma003772; Thu Apr 1 10:49:14 1999 Received: from vizir.u-strasbg.fr (vizir.u-strasbg.fr [130.79.128.13]) by amon.u-strasbg.fr (8.9.1a/8.9.0) with SMTP id RAA19436; Thu, 1 Apr 1999 17:02:00 +0200 (MET DST) Received: by vizir.u-strasbg.fr (5.x/SMI-SVR4) id AA24848; Thu, 1 Apr 1999 17:01:43 +0200 Message-Id: <9904011501.AA24848 at vizir.u-strasbg.fr> To: Eric Greisen Cc: fitsbits at fits.cv.nrao.edu Subject: Re: wcs.ps In-Reply-To: Your message of Wed, 31 Mar 1999 16:17:52 -0500 (EST) . Date: Thu, 01 Apr 1999 17:01:42 +0200 From: Francois Ochsenbein Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Dear Eric, Thank you for your fast reaction and update of the wcs paper. It's really converging, just a few more comments: > > > > 1. Compared to the IAU Style Manual: > > In table3: > > - the radian (symbol rad) is missing > > Angular units are a problem. The original FITS papers specified >that degrees would be used and they have been widely used for angles >projected onto images. Coordinate descriptions purporting to obey the >proposed conventions of Paper II (ccs.ps) will be required to use >degrees throughout. Nonetheless, wcs.ps should include 'rad' and >other standard angular measures for other uses, such as in tables. >Angles without specified units will be assumed to be in degrees. ----------------------- ==> Agreed, that's the important point: any unit can be used for angle, the _default_ being degrees (important for angles in the HDU, not really for tabular data) > > - the Ohm should be written with a capitalized O, > > to be consistent with its origin (physicist's name) > > and uppercase Greek symbol. > > Agreed - but neither your www site nor OGIP used the upper case >so I think we should stay lower. IAU does not capitalize any of the >named units (e.g.newton) when spelling out the unit in case that >matters to anyone. ==> Well, it looks like I'm also inconsistent... I'll change "ohm" to "Ohm" in our definitions (no column with such unit was found up to now in astronomical tables anyway). About case, the spelled units use only lowercase --- but the symbol units derived from some physicist's name are always capitalized ('N' for newton, 'A' for ampere, 'J' for Joule, 'Wb' for weber, 'Jy' for Jansky, etc...) > > In table 4: > > - the symbol of the year is the single-letter a (not yr) > > Yes. However, your www site also allows 'yr', so I have added >the IAU-standard 'a' ==> Thank you -- the "a preferred" sentence is probably not required, mentionning its presence in the IAU style manual should be enough (yr is much more frequently used in the literature...) > > - the sun-based units (solar mass at least) is missing > > Special mass units in general were missing and I also added all >the solar ones on your www page. > > > - the letter 'b' alone is the symbol of the barn (cross-section) > > The IAU does not include this unit and your www page also uses >'barn' so I think we leave this one. ==> The IAU style manual includes the 'b' in its Table 7 (Non-SI units and symbols whose continued use is deprecated). But I agree that "barn" is better, to distinguish from "beam" > > - for the Angstroem: should be capitalized for the same reasons > > as Ohm above -- and should or not an 'e' appended after the > > 'o' to reflect the original accentuation of the o ? > > The IAU does not include the unit. I suggest angstrom because >that is what OGIP has used and your www page does not allow for it. ==> Like the barn, the symbol is listed in Table 7 of IAU style manual. I could add also add it in our list. > > 2. The usage of the ** for exponentiation is not really a good > > idea -- it only makes sense for fortran programmers. > > Why not a single-letter symbol like the caret (^) most > > likely familiar to many more persons ? > > Actually the up arrow is also tied to mark-up languages such as >TeX which, like Fortran, will become unfamiliar to people in time. >There is no reason not to allow both and I agree that the up arrow >looks more like "raising to a power". It will be harder to typeset >with TeX (e.g. \char'136 or inside a \verb) than simple text. ==> I agree, the best solution is to allow both... In latex, just write \^{ } -- a bit ugly, I agree, but this works... > > 3. The usage of the blank is not a good idea either, even though > > it looks more like the printed text, it complicates its > > acquisition from simple-minded software (e.g. Perl) without > > better readability -- "count /s" doesn't look better than > > "count/s" > > You know - I rejected this when I first read it and have since >come around to think that you are right. I have rewritten the text to >allow but strongly discourage blanks. ==> There is just a 'switch?' at the end of this paragraph which is mot likely to be removed. > > 4. Some usual abbreviations like "ct" for count, or "ph" for > > photon, could be accepted . > > And some "miscellaneous" units could be useful as well like > > "beam" or "bit" > > I added 'ct', 'bit', and 'beam'. Your list does not include 'ph' >so I left 'photon' as the only one of those. ==> I will add 'ph' (frequently found in the literature anyway) > > 5. Finally, the usage of the trigonometric functions applied to > > units raises the question of the units of their argument and > > therefore the inconsistency with the inverse function, the degree > > being adopted instead of the radian. My personal suggestion > > would be to drop completely the trigonometric functions applied > > to non-dimensionless units -- I never found such expression in > > the literature, and this would be bad physics anyway ! > >Again I am going from rejecting your idea to accepting it. There are >numerous physical quantities that vary e.g wrt log(wavelength) or >cos(elevation). In the first case, the values do depend on whether it >is log(nm) or log(m). But the second case, cos requires an argument >in whatever units that function requires and produces a unitless >result that is independent of whatever units we thought of the >elevation in. Therefore I have dropped all trigonometric functions >but have left log, ln, etc. ==> Thank you ! > > Are these conventions about units in FITS definitive ? > > The documentation of astronomical catalogues available from > > the data centres (ADC, CDS, ...) describe over 60,000 columns; > > roughly 50% of these columns are unitless, and therefore about > > 30,000 columns have attached units carefully standardized > > to allow automatic conversions. (description at > > http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) > > I would hesitate to change these anyway... but would appreciate > > any comment / argumentation ! > > I have adopted all of the suggestions at this site, but one. >Write m2 does not instinctively mean m^2 or m**2 when I read it and so >I prefer the nomenclature of OGIP for exponents even though it does >require more characters. At some point human readability must enter >this discussion. ==> In our system, we'll also adopt the ^ as a possible way (presently we don't require any symbol for an integer power) > Many thanks for your close reading of this document and your >suggestions. I look forward to hearing from you again... There are a few additions/suppressions of the dagger indicating the possible addition of multiple prefixes in Table 4: - deg: suppress the dagger ? - add the dagger for a yr solMass barn Thank you again, Francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)3 88 150 755 Email: francois at simbad.u-strasbg.fr (France) Fax: +33-(0)3 88 150 740 ================================================================================ From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 1 13:13:39 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA13775 for fitsbits-spinner; Thu, 1 Apr 1999 13:13:10 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA13770 for ; Thu, 1 Apr 1999 13:13:07 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA23963 for fitsbits at majordomo.cv.nrao.edu; Thu, 1 Apr 1999 13:13:06 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA13625 for ; Thu, 1 Apr 1999 12:12:27 -0500 (EST) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id MAA23855 for ; Thu, 1 Apr 1999 12:12:26 -0500 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA26281; Thu, 1 Apr 1999 12:12:21 -0500 (EST) Date: Thu, 1 Apr 1999 12:12:21 -0500 (EST) Message-Id: <199904011712.MAA26281 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Arnold Rots Cc: egreisen at valen.cv.nrao.edu (Eric Greisen), fitsbits at fits.cv.nrao.edu Subject: Re: wcs.ps In-Reply-To: <199904011510.KAA18249 at xebec.harvard.edu> References: <199903312117.QAA25164 at primate.cv.nrao.edu> <199904011510.KAA18249 at xebec.harvard.edu> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Arnold Rots writes: > Units: > When we introduced the ADU for Chandra/AXAF files, last year, it was > decided to use the string "adu", in lower case. Since that has been > written into a lot of software already, it would be helpful - to us, > at least - if you could also define that string as lower case. okay > > I noticed that your list was missing the unit that is dear to many HEA > types' hearts: the "Crab". Even though it's listed in the Chandra > FITS guide, I'm not sure I'd really want to argue for its inclusion in > your list. ;-) if the Crab is as well defined as the Solar units, we could add it. What is the definition? > > > Coordinates in binary tables: > I think it would be good to split the BINARY vector column in Table 7 > also into new and old, where old is the convention that HEASARC > adopted a number of years ago and that got incorporated into the RXTE > archive: jCTYPn, jCUNIn, jCRVLn, jCRPXn, jCDLTn. I know, that makes > it hard to fit into one text column, but ... sigh... > My recollection was that the old Pixel List increment was TCDLTn, not > TCDELn. the old column has been added and the spellings fixed > I would suggest changing the Vector increment keyword, in view of > these older forms, to jCDLns, rather than jCDEns. CDELT is not an allowed "new" word. I moved jCDLns to the new old column and put in the old spelling > In general, I would argue for accepting CDELTjs, jCDLns, and TCDLns as > plain synonyms for, respectively, CDj_js, jjCDns, and TCn_ns (rather > than deprecating some of them), just to have uniform rules for all of > them (I hope I'm not opening a can of worms here); with the > restriction that one cannot mix increments with a matrix: increments > are ignored when any CD matrix element is present. There has been a fight about this. Earlier drafts of the full combined paper recommended writing both forms of the words for new as well as old readers. But there was a large outburst from a variety of people. The new Paper II will recommend writing either the new form ONLY or the old form ONLY. Combined versions will be forbidden. I am sympathetic to this view in hindsight since the subject is already complicated without mixing "Latin" with a modern tongue. > > > I was trying not to get confused by the indices in Tables 1 and 7; but > shouldn't, in the latter, TCRPns be TCRPks? A subtle (and correct) point. How many people will read this paper that closely? It took me a while, but I > can see the rationale for the trio PVj_ms, jPm_ns, and TPm_ns. It is > unfortunate that, in an effort to keep the column number at the end, > this clashes internally. Maybe one should consider jPn_ms and TPn_ms; I agree and have switched them. > I have my doubts whether these will ever become popular. They may not be "popular" but coordinate projections will require them and people will have little choice... I have not yet copied a new wcs.ps to the www address because I now need to consider Francois' latest ideas. A new one will be announced when ready. Thanks for your comments and close reading, Eric From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 1 13:40:07 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA13895 for fitsbits-spinner; Thu, 1 Apr 1999 13:39:55 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA13890 for ; Thu, 1 Apr 1999 13:39:52 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA24658 for fitsbits at majordomo.cv.nrao.edu; Thu, 1 Apr 1999 13:39:52 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA13849 for ; Thu, 1 Apr 1999 13:34:10 -0500 (EST) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id NAA24576 for ; Thu, 1 Apr 1999 13:34:09 -0500 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA26320; Thu, 1 Apr 1999 13:34:05 -0500 (EST) Date: Thu, 1 Apr 1999 13:34:05 -0500 (EST) Message-Id: <199904011834.NAA26320 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Francois Ochsenbein Cc: Eric Greisen , fitsbits at fits.cv.nrao.edu Subject: Re: wcs.ps In-Reply-To: <9904011501.AA24848 at vizir.u-strasbg.fr> References: <9904011501.AA24848 at vizir.u-strasbg.fr> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk ***** GENERAL REMARKS *****: 1. Does anyone require angstrom as a synonym to Angstrom? 2. Would people read over Table 4 to see if they agree with which units should be allowed prefixes and which not. Also, please look to see if a prefix might turn one unit into another - a gotcha we have to avoid. 3. The latest draft is now in place at ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/wcs.ps Thanks to all Eric Francois Ochsenbein writes: > > It's really converging, just a few more comments: Yes - remarkable really. Thanks for your help here. > > > > > > > 1. Compared to the IAU Style Manual: > > > In table3: > > > - the radian (symbol rad) is missing > > > > Angular units are a problem. The original FITS papers specified > >that degrees would be used and they have been widely used for angles > >projected onto images. Coordinate descriptions purporting to obey the > >proposed conventions of Paper II (ccs.ps) will be required to use > >degrees throughout. Nonetheless, wcs.ps should include 'rad' and > >other standard angular measures for other uses, such as in tables. > >Angles without specified units will be assumed to be in degrees. > ----------------------- > ==> Agreed, that's the important point: any unit can be used for angle, > the _default_ being degrees (important for angles in the HDU, > not really for tabular data) Actually tables can have whole images in them or fragments of projected imagery, so the conventions of Paper II will be important in those cases. Of course, what really matters is that coordinates be labeled and labeled correctly. > > > > - the Ohm should be written with a capitalized O, > > > to be consistent with its origin (physicist's name) > > > and uppercase Greek symbol. > > > > Agreed - but neither your www site nor OGIP used the upper case > >so I think we should stay lower. IAU does not capitalize any of the > >named units (e.g.newton) when spelling out the unit in case that > >matters to anyone. > ==> Well, it looks like I'm also inconsistent... I'll change "ohm" to > "Ohm" in our definitions (no column with such unit was found up to now > in astronomical tables anyway). > About case, the spelled units use only lowercase --- but the > symbol units derived from some physicist's name are always > capitalized ('N' for newton, 'A' for ampere, 'J' for Joule, > 'Wb' for weber, 'Jy' for Jansky, etc...) This is not worth much discussion - as you say it is not present in much of our data. 'Ohm' it is. > > > > In table 4: > > > - the symbol of the year is the single-letter a (not yr) > > > > Yes. However, your www site also allows 'yr', so I have added > >the IAU-standard 'a' > ==> Thank you -- the "a preferred" sentence is probably not required, > mentioning its presence in the IAU style manual should be enough > (yr is much more frequently used in the literature...) Changed to "a is IAU-style" > > > > - the sun-based units (solar mass at least) is missing > > > > Special mass units in general were missing and I also added all > >the solar ones on your www page. > > > > > - the letter 'b' alone is the symbol of the barn (cross-section) > > > > The IAU does not include this unit and your www page also uses > >'barn' so I think we leave this one. > ==> The IAU style manual includes the 'b' in its Table 7 (Non-SI units > and symbols whose continued use is deprecated). > But I agree that "barn" is better, to distinguish from "beam" I like barn - b is unfamiliar to we non-X-ray folk and the b of IAU documents is being deprecated by them. > > > > - for the Angstroem: should be capitalized for the same reasons > > > as Ohm above -- and should or not an 'e' appended after the > > > 'o' to reflect the original accentuation of the o ? > > > > The IAU does not include the unit. I suggest angstrom because > >that is what OGIP has used and your www page does not allow for it. > ==> Like the barn, the symbol is listed in Table 7 of IAU style manual. > I could add also add it in our list. Okay - "Angstrom". Does anyone require angstrom as a synonym? I note that my spell checker wants Angstrom also! > > > > 2. The usage of the ** for exponentiation is not really a good > > > idea -- it only makes sense for fortran programmers. > > > Why not a single-letter symbol like the caret (^) most > > > likely familiar to many more persons ? > > > > Actually the up arrow is also tied to mark-up languages such as > >TeX which, like Fortran, will become unfamiliar to people in time. > >There is no reason not to allow both and I agree that the up arrow > >looks more like "raising to a power". It will be harder to typeset > >with TeX (e.g. \char'136 or inside a \verb) than simple text. > ==> I agree, the best solution is to allow both... In latex, just write > \^{ } -- a bit ugly, I agree, but this works... > > > > 3. The usage of the blank is not a good idea either, even though > > > it looks more like the printed text, it complicates its > > > acquisition from simple-minded software (e.g. Perl) without > > > better readability -- "count /s" doesn't look better than > > > "count/s" > > > > You know - I rejected this when I first read it and have since > >come around to think that you are right. I have rewritten the text to > >allow but strongly discourage blanks. > ==> There is just a 'switch?' at the end of this paragraph which > is mot likely to be removed. I don't know where that came from - it is gone now. > > > > 4. Some usual abbreviations like "ct" for count, or "ph" for > > > photon, could be accepted . > > > And some "miscellaneous" units could be useful as well like > > > "beam" or "bit" > > > > I added 'ct', 'bit', and 'beam'. Your list does not include 'ph' > >so I left 'photon' as the only one of those. > ==> I will add 'ph' (frequently found in the literature anyway) I added ph as a synonym. > > > > 5. Finally, the usage of the trigonometric functions applied to > > > units raises the question of the units of their argument and > > > therefore the inconsistency with the inverse function, the degree > > > being adopted instead of the radian. My personal suggestion > > > would be to drop completely the trigonometric functions applied > > > to non-dimensionless units -- I never found such expression in > > > the literature, and this would be bad physics anyway ! > > > >Again I am going from rejecting your idea to accepting it. There are > >numerous physical quantities that vary e.g wrt log(wavelength) or > >cos(elevation). In the first case, the values do depend on whether it > >is log(nm) or log(m). But the second case, cos requires an argument > >in whatever units that function requires and produces a unitless > >result that is independent of whatever units we thought of the > >elevation in. Therefore I have dropped all trigonometric functions > >but have left log, ln, etc. > ==> Thank you ! Mark Calabretta points out that all functions require unitless arguments. Thus log(Hz) really means log(x/1Hz). A sentence to say this has been added. That would make trigonometric functions possible, but I will only put them back is there is an outcry... > > > > Are these conventions about units in FITS definitive ? > > > The documentation of astronomical catalogues available from > > > the data centres (ADC, CDS, ...) describe over 60,000 columns; > > > roughly 50% of these columns are unitless, and therefore about > > > 30,000 columns have attached units carefully standardized > > > to allow automatic conversions. (description at > > > http://vizier.u-strasbg.fr/doc/catstd-3.2.htx ) > > > I would hesitate to change these anyway... but would appreciate > > > any comment / argumentation ! > > > > I have adopted all of the suggestions at this site, but one. > >Write m2 does not instinctively mean m^2 or m**2 when I read it and so > >I prefer the nomenclature of OGIP for exponents even though it does > >require more characters. At some point human readability must enter > >this discussion. > ==> In our system, we'll also adopt the ^ as a possible way (presently > we don't require any symbol for an integer power) Thanks you! > > > Many thanks for your close reading of this document and your > >suggestions. I look forward to hearing from you again... > > There are a few additions/suppressions of the dagger indicating the > possible addition of multiple prefixes in Table 4: > - deg: suppress the dagger ? > - add the dagger for a yr solMass barn Done. The whole issue of which to put daggers on and which not is confusing to me. I hope people read and check this matter closely. Again, many thanks, Eric From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 1 17:13:43 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA14336 for fitsbits-spinner; Thu, 1 Apr 1999 17:13:09 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA14331 for ; Thu, 1 Apr 1999 17:13:06 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id RAA25985 for fitsbits at majordomo.cv.nrao.edu; Thu, 1 Apr 1999 17:13:05 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA14309 for ; Thu, 1 Apr 1999 16:55:25 -0500 (EST) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id QAA25954 for ; Thu, 1 Apr 1999 16:55:24 -0500 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id QAA18897 for ; Thu, 1 Apr 1999 16:55:23 -0500 Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3) id sma018894; Thu Apr 1 16:55:19 1999 Received: from xebec.harvard.edu (xebec [131.142.52.100]) by head-cfa.harvard.edu (8.9.1a/8.9.0) with ESMTP id QAA29619; Thu, 1 Apr 1999 16:48:33 -0500 (EST) From: Arnold Rots Received: (from arots at localhost) by xebec.harvard.edu (8.9.1/8.9.0) id QAA22562; Thu, 1 Apr 1999 16:48:33 -0500 (EST) Message-Id: <199904012148.QAA22562 at xebec.harvard.edu> Subject: Re: wcs.ps In-Reply-To: <199904011712.MAA26281 at primate.cv.nrao.edu> from Eric Greisen at "Apr 1, 99 12:12:21 pm" To: egreisen at valen.cv.nrao.edu (Eric Greisen) Date: Thu, 1 Apr 1999 16:48:32 -0500 (EST) Cc: fitsbits at fits.cv.nrao.edu X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric Greisen wrote: > Arnold Rots writes: > > Units: > > ... > > I noticed that your list was missing the unit that is dear to many HEA > > types' hearts: the "Crab". Even though it's listed in the Chandra > > FITS guide, I'm not sure I'd really want to argue for its inclusion in > > your list. ;-) > > if the Crab is as well defined as the Solar units, we could add > it. What is the definition? It's more like a relative flux density unit, with a particular spectral distribution. Think of it as radio astronomers expressing their flux densities at all frequencies in Cas-A units. I don't think you want to get into this ;-) > > > > > > > Coordinates in binary tables: Table 7 still contains TCDELn instead of TCDLTn. > > > I would suggest changing the Vector increment keyword, in view of > > these older forms, to jCDLns, rather than jCDEns. > > CDELT is not an allowed "new" word. I moved jCDLns to the new > old column and put in the old spelling > > > In general, I would argue for accepting CDELTjs, jCDLns, and TCDLns as > > plain synonyms for, respectively, CDj_js, jjCDns, and TCn_ns (rather > > than deprecating some of them), just to have uniform rules for all of > > them (I hope I'm not opening a can of worms here); with the > > restriction that one cannot mix increments with a matrix: increments > > are ignored when any CD matrix element is present. > > There has been a fight about this. Earlier drafts of the full > combined paper recommended writing both forms of the words for new as > well as old readers. But there was a large outburst from a variety of > people. The new Paper II will recommend writing either the new form > ONLY or the old form ONLY. Combined versions will be forbidden. I am > sympathetic to this view in hindsight since the subject is already > complicated without mixing "Latin" with a modern tongue. > Sigh... I notice, though, that, de facto, you don't adhere to this creed, either, using words like e.g., prefix, suffix, etc. ... Which seems to indicate that it can quite convenient to have the ability to throw an occasional Latin word in ;-) > > > > Thanks for all the great work, - Arnold -------------------------------------------------------------------------- Arnold H. Rots AXAF Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 81 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 2 09:04:50 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA24735 for fitsbits-spinner; Fri, 2 Apr 1999 09:04:12 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA24730 for ; Fri, 2 Apr 1999 09:04:09 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id JAA27673 for fitsbits at majordomo.cv.nrao.edu; Fri, 2 Apr 1999 09:04:08 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id UAA14633 for ; Thu, 1 Apr 1999 20:27:45 -0500 (EST) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id UAA26300 for ; Thu, 1 Apr 1999 20:27:45 -0500 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id UAA21952 for ; Thu, 1 Apr 1999 20:27:43 -0500 Received: from phobos.caltech.edu(131.215.240.1) by palantir.cv.nrao.edu via smap (V1.3) id sma021946; Thu Apr 1 20:27:24 1999 Received: from bottom.caltech.edu (bottom [131.215.240.17]) by phobos.caltech.edu (8.9.3/8.9.3) with ESMTP id RAA26554; Thu, 1 Apr 1999 17:21:03 -0800 (PST) Received: from localhost by bottom.caltech.edu (8.9.0/8.9.0) with ESMTP id RAA17935; Thu, 1 Apr 1999 17:20:59 -0800 (PST) X-Authentication-Warning: bottom.caltech.edu: tjp owned process doing -bs Date: Thu, 1 Apr 1999 17:20:59 -0800 (PST) From: Tim Pearson X-Sender: tjp at bottom.caltech.edu To: Francois Ochsenbein cc: fitsbits at fits.cv.nrao.edu Subject: Re: units In-Reply-To: <37024139.19EA at simbad.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by kochab.cv.nrao.edu id UAA14634 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk On Wed, 31 Mar 1999, Francois Ochsenbein wrote: > - the Ohm sould be written with a capitalized O, > to be consistent with its origin (physicist's name) I disagree with this (trivial) point. I think that it is the normal practice of publishers in the english-speaking world *not* to capitalize the names of units, even those derived from proper names, such as "newton", "ohm", "joule", "jansky", "ampère", "ångström", etc. This may be a recommendation of the various international unions - I am not sure - but it is certainly advocated by, for example, the Royal Society (London). This follows normal english practice, in which proper names are capitalized, but not words derived from proper names, such as "sandwich", "boycott", etc. However, tastes differ; and there are some circumstances in which it is appropriate to capitalize the name of a unit, such as at the beginning of a sentence. So software should be tolerant of variant capitalization (i.e., it should be case-insensitive). Tim Pearson Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA Internet: tjp at astro.caltech.edu From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 2 09:04:53 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA24742 for fitsbits-spinner; Fri, 2 Apr 1999 09:04:44 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA24737 for ; Fri, 2 Apr 1999 09:04:41 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id JAA27678 for fitsbits at majordomo.cv.nrao.edu; Fri, 2 Apr 1999 09:04:40 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id CAA16250 for ; Fri, 2 Apr 1999 02:50:43 -0500 (EST) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id CAA27008 for ; Fri, 2 Apr 1999 02:50:42 -0500 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id CAA29694 for ; Fri, 2 Apr 1999 02:50:41 -0500 Received: from poseidon.ifctr.mi.cnr.it(155.253.16.87) by palantir.cv.nrao.edu via smap (V1.3) id sma029688; Fri Apr 2 02:50:31 1999 Received: from localhost (lucio at localhost) by poseidon.ifctr.mi.cnr.it (8.9.1/8.9.1) with ESMTP id JAA19721 for ; Fri, 2 Apr 1999 09:50:32 +0200 (MET DST) Date: Fri, 2 Apr 1999 09:50:32 +0200 (MET DST) From: Lucio Chiappetti To: fitsbits at fits.cv.nrao.edu Subject: Crab et al., a warning Re: wcs.ps In-Reply-To: <199904011712.MAA26281 at primate.cv.nrao.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk On Thu, 1 Apr 1999, Eric Greisen wrote: > Arnold Rots writes: > > I noticed that your list was missing the unit that is dear to many HEA > > types' hearts: the "Crab". > if the Crab is as well defined as the Solar units, we could add > it. What is the definition? About the definition of "1 Crab" I guess it could be good to agree a standard definition. I believe everybody has one's own variant ... In principle it should be a "flux" unit (ANY flux, from erg/cm2/s to ph/cm2/s or even cts/s for a particular mission instrument) which results from the comparison of the integrated flux (in a "given" energy band, see below) of a Crab-like spectrum, i.e. the spectrum of the synchrotron component in the Crab nebula dN/dE = 9.8 * E**(-2.1) * absorption(NH=3.10E21). At least that's what I use. Little variations in norm, spectral index and NH are possible according to your favourite reference. However what is not well defined is the band in which the integral is taken. In principle you can integrate the above spectrum in ANY band, and compare the flux of your source in the same band to the Crab-like spectrum. In practice the definition was born in 2-10 (or 2-6) keV X-ray astronomy, and it would be of less use and ease in other bands ... of course a, say, 1 mCrab source in 2-10 keV would'nt be a 1 mCrab in 100-300 keV if the spectrum is steeper or flatter than 2.1 ! BUT .. BUT ... BUT ... One moment. Are we talking here of standardization of unit indication in generic FITS files (tables) or just of WCS ? And does not WCS apply "primarily" (or "originally") to IMAGES and "secondarily" (or "more recently") to SPECTRA ? I would expect it would be very difficult that the "spatial" axes of an image, or the "dispersion" axis of a spectrum, would be measured in Crab units (or in Ohm, if that matters). So aren't we discussing about "the sex of angels" ? AND MORE BUT'S ... Even if we would be discussing standardization of units in generic tables, I reiterate my provocation, is it really worth while to go in extreme detail ? For what are essentially "plot labels" ? I'd expect humans (astronomers) be able to read a column heading and know what it is (and convert to their favourite customary units) anyhow, while software will just copy and use labels as they are, as "semantic-less" strings. Do we really expect to have an all-encompassing universal routine library which will convert any unit to any unit ? I heard a saying "build a system than any fool can use, and only a fool will want to use it". But it could also be reversed "build a standard that is too clever, and nobody will be clever enough to want to use it". I'm thinking of a recent discussion about a largish database private to a smallish consortium (less than 10 institutes), of course to me it was obvious to say FITS had to be used for interchange and not ASCII ... but it was pointed to me that the programming competences of the "mean quadratic astronomer" were quite below that mark ... And if he/she will have difficulty in using age-old consolidated good old plain FITS, is it likely it will adhere, or even check, a "marginal" convention ? Even when major agencies (funded also by my taxes) involved in major missions produce and distribute tools which measure fluxes in eV/mm2/s (!) instead of the more usual erg/cm2/s ? :-) [sorry, I could not resist] ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html ---------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 2 10:29:10 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA24956 for fitsbits-spinner; Fri, 2 Apr 1999 10:29:05 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA24951 for ; Fri, 2 Apr 1999 10:29:02 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA28282 for fitsbits at majordomo.cv.nrao.edu; Fri, 2 Apr 1999 10:29:02 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA24937 for ; Fri, 2 Apr 1999 10:12:35 -0500 (EST) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id KAA28129 for ; Fri, 2 Apr 1999 10:12:34 -0500 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA26763; Fri, 2 Apr 1999 10:12:30 -0500 (EST) Date: Fri, 2 Apr 1999 10:12:30 -0500 (EST) Message-Id: <199904021512.KAA26763 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: Tim Pearson Cc: Francois Ochsenbein , fitsbits at fits.cv.nrao.edu Subject: Re: units In-Reply-To: References: <37024139.19EA at simbad.u-strasbg.fr> X-Mailer: VM 6.35 under Emacs 20.2.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kochab.cv.nrao.edu id KAA24938 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Tim Pearson writes: > On Wed, 31 Mar 1999, Francois Ochsenbein wrote: > > > - the Ohm sould be written with a capitalized O, > > to be consistent with its origin (physicist's name) > > I disagree with this (trivial) point. I think that it is the normal > practice of publishers in the english-speaking world *not* to > capitalize the names of units, even those derived from proper names, > such as "newton", "ohm", "joule", "jansky", "ampère", "ångström", etc. > This may be a recommendation of the various international unions - I > am not sure - but it is certainly advocated by, for example, the Royal > Society (London). > > This follows normal english practice, in which proper names are > capitalized, but not words derived from proper names, such as > "sandwich", "boycott", etc. We are here not talking about spelled out names generally but about abreviations for units. The Ohm and Angstrom ones are special cases since A is amperes and a is ato and O likes too much like 0, so we are spelling them out as "abreviations". I note that the IAU style manual refers to "janskys" as "Jy" which is what all radio astronomers use. I really don't care whether Angstrom or Ohm are capitalized, and perhaps since we are spelling these out we should leave them without capitals as the IAU style manual does with spelled out words and as both units references actually do. > > However, tastes differ; and there are some circumstances in which it > is appropriate to capitalize the name of a unit, such as at the > beginning of a sentence. So software should be tolerant of variant > capitalization (i.e., it should be case-insensitive). If we become case insensitive, then m milli and M mega and A ampere and a ato become hard to tell apart. I am no fan of case sensitivity, but it is unfortunately necessary here. It is of course true that a clever parser could have more lenient rules than the standard - that is normal and perhaps even required of FITS readers in general. Eric Greisen From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 2 10:44:49 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA25274 for fitsbits-spinner; Fri, 2 Apr 1999 10:44:47 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA25269 for ; Fri, 2 Apr 1999 10:44:44 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA28362 for fitsbits at majordomo.cv.nrao.edu; Fri, 2 Apr 1999 10:44:43 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA25253 for ; Fri, 2 Apr 1999 10:41:01 -0500 (EST) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id KAA28334 for ; Fri, 2 Apr 1999 10:41:00 -0500 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA26773; Fri, 2 Apr 1999 10:40:22 -0500 (EST) Date: Fri, 2 Apr 1999 10:40:22 -0500 (EST) Message-Id: <199904021540.KAA26773 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lucio Chiappetti Cc: fitsbits at fits.cv.nrao.edu Subject: Re: Crab et al., a warning Re: wcs.ps In-Reply-To: References: <199904011712.MAA26281 at primate.cv.nrao.edu> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Lucio Chiappetti writes: > On Thu, 1 Apr 1999, Eric Greisen wrote: > > > Arnold Rots writes: > > > I noticed that your list was missing the unit that is dear to many HEA > > > types' hearts: the "Crab". > > > if the Crab is as well defined as the Solar units, we could add > > it. What is the definition? > > About the definition of "1 Crab" I guess it could be good to agree a standard > definition. I believe everybody has one's own variant ... Arnold's earlier reply that "we don't want to go there" about Crabs is well explained by your description of them. I have no intention of putting them in the paper, until the community gets a much better definition. > > BUT .. BUT ... BUT ... > > One moment. Are we talking here of standardization of unit indication in > generic FITS files (tables) or just of WCS ? > And does not WCS apply "primarily" (or "originally") to IMAGES and > "secondarily" (or "more recently") to SPECTRA ? WCS applies to any observation of a physical quantity. The issue is most pressing when we attempt to associate coordinates with the voxels in an image, but images as well as single pixels can and do occur in tables and elsewhere. > > I would expect it would be very difficult that the "spatial" axes of an image, > or the "dispersion" axis of a spectrum, would be measured in Crab units (or > in Ohm, if that matters). > So aren't we discussing about "the sex of angels" ? Derived quantities may also be sampled into images or tables and expressed against whatever physical coordinates seem appropriate to the Physics of the observation. I have removed trigonometric functions from wcs.ps but am concerned about matters that are indeed functions of e.g. cos(latitude). Maybe it is wrong to remove them. I agree that Ohm is unlikely in astronomical data and so we are free to change its spelling, but Crabs and Angstroms are not unlikely. > > AND MORE BUT'S ... > > Even if we would be discussing standardization of units in generic tables, I > reiterate my provocation, is it really worth while to go in extreme detail ? > For what are essentially "plot labels" ? WCS are not plot labels. They have that function, but they have a great deal more as well. If units are expressed properly, then they may be parsed in software and converted to other comparable units, after which vast tables may be searched for matches, sub-set selection, etc etc etc This is now done with tabular data a great deal with for example the NVSS survey here at NRAO and, judging by Francois Ochsenbein's remarks, many of the tables at the Strasbourg data center. WCS for imagery is often used to regrid one image to the coordinates of another so that the physics of the two may be compared visually and numerically. WCS is not a plot tool, it is a Physics tool. > I'd expect humans (astronomers) be able to read a column heading and know what > it is (and convert to their favorite customary units) anyhow, while software > will just copy and use labels as they are, as "semantic-less" strings. > Do we really expect to have an all-encompassing universal routine library > which will convert any unit to any unit ? Yes - I do not have such a thing. But I am told that numerous Object Oriented tool sets (e.g. aips++) do have exactly that. Current data sets, tables, and images are already awfully large to depend on astronomers to read them visually. And as you point out below, the working astronomer may not be the best equipped to understand technical details of what you would force him to read. > > I heard a saying "build a system than any fool can use, and only a fool will > want to use it". But it could also be reversed "build a standard that is too > clever, and nobody will be clever enough to want to use it". FITS as a whole was claimed when we started to be too hard because we allowed and required BINARY data. Where would we be today if we had done only character-form data? Where are ASCII tables today? I agree that we can get too fancy and I think that some hierarchal relational data-base proposals that I have heard are just that. However, we do need also to get things right. To leave things inexact and prone to error and misinterpretation simply because "it is too hard" is wrong. The whole subject of WCS is hard and that is why we have had to leave it until later in the FITS process. It was needed at the beginning (hence CDELTA, CTYPE etc in the first FITS paper) and has been used in detail in some software from the early 1980s (e.g. aips). > > I'm thinking of a recent discussion about a largish database private to a > smallish consortium (less than 10 institutes), of course to me it was obvious > to say FITS had to be used for interchange and not ASCII ... but it was > pointed to me that the programming competences of the "mean quadratic > astronomer" were quite below that mark ... > > And if he/she will have difficulty in using age-old consolidated good old > plain FITS, is it likely it will adhere, or even check, a "marginal" > convention ? The initial software may not be the best that it could be. But with a good standard and the 3-sigma astronomer it can get better with time if there is a standard to which it may aspire. FITS tapes are usually written even today with little or no WCS info. They are useful, but would be very much more useful if they had better WCS, especially WCS that software would recognize. > > Even when major agencies (funded also by my taxes) involved in major missions > produce and distribute tools which measure fluxes in eV/mm2/s (!) instead of > the more usual erg/cm2/s ? :-) [sorry, I could not resist] But there is no problem with either of these units if they are described properly. The point of wcs.ps is to allow even misguided folks to express their misguided opinions in such a fashion that other misguided folks may correctly convert the data to their particular religion. I knew that the units section would get people to talk about the paper. I just hope you are all also reading the rest of it and Paper III (and Paper II when it becomes available). The spectroscopy paper is new and important. FITS itself has guided how astronomers think of their data and how software systems think of data for their users. These WCS papers will, if adopted, affect how you will see data and how you will receive them from your colleagues. Eric Greisen From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 2 14:37:37 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id OAA00078 for fitsbits-spinner; Fri, 2 Apr 1999 14:37:16 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA00073 for ; Fri, 2 Apr 1999 14:37:14 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id OAA28914 for fitsbits at majordomo.cv.nrao.edu; Fri, 2 Apr 1999 14:37:13 -0500 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA26548 for ; Fri, 2 Apr 1999 11:52:47 -0500 (EST) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id LAA28577 for ; Fri, 2 Apr 1999 11:52:47 -0500 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id LAA05651 for ; Fri, 2 Apr 1999 11:52:45 -0500 Received: from poseidon.ifctr.mi.cnr.it(155.253.16.87) by palantir.cv.nrao.edu via smap (V1.3) id sma005644; Fri Apr 2 11:52:19 1999 Received: from localhost (lucio at localhost) by poseidon.ifctr.mi.cnr.it (8.9.1/8.9.1) with ESMTP id SAA06977 for ; Fri, 2 Apr 1999 18:52:21 +0200 (MET DST) Date: Fri, 2 Apr 1999 18:52:21 +0200 (MET DST) From: Lucio Chiappetti To: fitsbits at fits.cv.nrao.edu Subject: Re: Crab et al., a warning Re: wcs.ps In-Reply-To: <199904021540.KAA26773 at primate.cv.nrao.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk On Fri, 2 Apr 1999, Eric Greisen wrote: > Lucio Chiappetti writes: > > On Thu, 1 Apr 1999, Eric Greisen wrote: > > > Arnold Rots writes: > Arnold's earlier reply that "we don't want to go there" about > Crabs is well explained by your description of them. I have no > intention of putting them in the paper, until the community gets a > much better definition. Ok for letting the Crab out > > One moment. Are we talking here of standardization of unit indication in > > generic FITS files (tables) or just of WCS ? > > And does not WCS apply "primarily" (or "originally") to IMAGES and > > "secondarily" (or "more recently") to SPECTRA ? > > WCS applies to any observation of a physical quantity. The issue > is most pressing when we attempt to associate coordinates with the > voxels in an image, but images as well as single pixels can and do > occur in tables and elsewhere. hmm ... tables within tables, or images within tables, look to me what you'd call "fancy" stuff. I do appreciate that an image can be other than a sky image (see one example further below), but most of the WCS image paper is for astrometry, or anyhow sky coordinate handling (and that's not particularly my field). Also a spectrum is in generally something quite defined (flux vs energy) although there can be peculiarities (and the WCS spectral papeer addresses many of them from optical astronomy, again things I'm not particularly familiar with) particularly for "raw" or "nearly raw" data. I could imagine the need of some standard for flux conversions of "reduced" spectra. I mainly think of the conversion of dN/dE vs E from/to Fnu vs nu, Flambda vs lambda, nuFnu (SED) etc. with proper handling of error bars, and clear distinction of the case the single points in a spectrum are monochromatic or broad band fluxes (in which case proper conversion need to know the form of the underlying continuum !) But "any other thing" is just an "histogram" or "plot" of some y quantity vs some x quantity. Is it worthwhile to commit to a very hard enterprise of a fully general handler ? Or is it better to consider only the cases of images and spectra, and at most light curves and other timing analysis data structures (thinking of x-axis which could be in time, frequency, or phase) ... > I agree that Ohm is unlikely in astronomical data and so we are free > to change its spelling, but Crabs and Angstroms are not unlikely. Angstrom are extremely likely on the X (dispersion, or energy) axis of an UV or optical spectrum. Crabs (a flux unit) are totally unlikely (probably meaningless) as units of the axes of an image or a spectrum, and even if they are flux units, quite unlikely also on the "Z axis" (BUNIT), or the Y axis of a spectrum. They are likely to occur only in pure tables (catalog entries). > WCS are not plot labels. They have that function, but they have > a great deal more as well. I've never told that WCS were plot labels, my reference to plot labels was to the physical unit convention (i.e. the part of the Appendices which were not immediately related to WCS). It was even farther from my mind to criticise or diminish the WCS effort ! I do appreciate at least some usages of "original" WCS for astrometry, and of course also the ones in the spectroscopy paper. My doubts were on the insertion of the ENTIRE business of units into the WCS approval process, particularly for what concerned "exotic" units, or anyhow units outside the ra-dec-energy-flux (astrometry/spectroscopy) context. After all the important thing in WCS are "internal transformation" (like sky projections going beyond the original CRPIX CRVAl CDELT, or intrinsic usage of "log(units)" ... I tend myself to keep chi-square grid vs spectral index and column density NH in form of images ... and of course NH has a log range ...). But once there is a clear convention (-> WCS) to know that the value at pixel coordinates i,j correspond a given log(NH),gamma, or instead to log(pears),apples ... NH and gamma, or pears and apples, become plot labels. ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html ---------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Sat Apr 3 08:45:01 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA13174 for fitsbits-spinner; Sat, 3 Apr 1999 08:44:20 -0500 (EST) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA13169 for ; Sat, 3 Apr 1999 08:44:17 -0500 (EST) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id IAA30845 for fitsbits at majordomo.cv.nrao.edu; Sat, 3 Apr 1999 08:44:17 -0500 Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA11488 for ; Sat, 3 Apr 1999 08:31:08 -0500 (EST) Received: from palantir.cv.nrao.edu (root at palantir.cv.nrao.edu [192.33.115.254]) by cv3.cv.nrao.edu (8.8.5/8.8.5/CV-2.7) with ESMTP id IAA00791 for ; Sat, 3 Apr 1999 08:31:06 -0500 (EST) Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id BAA28492 for ; Sat, 3 Apr 1999 01:57:58 -0500 Received: from fits.cv.nrao.edu(192.33.115.8) by palantir.cv.nrao.edu via smap (V1.3) id sma027130; Sat Apr 3 01:56:58 1999 Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id BAA30024 for ; Sat, 3 Apr 1999 01:53:10 -0500 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id BAA07999; Sat, 3 Apr 1999 01:52:54 -0500 To: fitsbits at fits.cv.nrao.edu Date: 3 Apr 1999 07:25:06 +0200 From: pausch at merope.saaf.se (Paul Schlyter) Message-ID: <7e48ni$7of$1 at merope.saaf.se> Organization: Svensk Amat|rAstronomisk F|rening (SAAF) Path: newsfeed.cv.nrao.edu!chaos.aoc.nrao.edu!newshost.nmt.edu!logbridge.uoregon.edu!news.maxwell.syr.edu!newsfeed.nacamar.de!uio.no!news.kth.se!tybalt.admin.kth.se!merope.saaf.se!not-for-mail References: <37024139.19EA at simbad.u-strasbg.fr> <199904021512.KAA26763 at primate.cv.nrao.edu> Subject: Re: units Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk In article <199904021512.KAA26763 at primate.cv.nrao.edu>, Eric Greisen wrote: > Tim Pearson writes: >> On Wed, 31 Mar 1999, Francois Ochsenbein wrote: >> >>> - the Ohm sould be written with a capitalized O, >>> to be consistent with its origin (physicist's name) >> >> I disagree with this (trivial) point. I think that it is the normal >> practice of publishers in the english-speaking world *not* to >> capitalize the names of units, even those derived from proper names, >> such as "newton", "ohm", "joule", "jansky", "ampère", "ångström", etc. >> This may be a recommendation of the various international unions - I >> am not sure - but it is certainly advocated by, for example, the Royal >> Society (London). >> >> This follows normal english practice, in which proper names are >> capitalized, but not words derived from proper names, such as >> "sandwich", "boycott", etc. > > We are here not talking about spelled out names generally but > about abreviations for units. The Ohm and Angstrom ones are special > cases since A is amperes and a is ato and O likes too much like 0, so > we are spelling them out as "abreviations". The Ångström unit is abbreviated "A" only in languages which lack "Å". And the "Ohm" is not abbreviated as "O" but as (capital) Omega. Finally: there are numerous other units which are abbreviated as a capital letter. For instance newton (N), joule (J), ...... -- ---------------------------------------------------------------- Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) Grev Turegatan 40, S-114 38 Stockholm, SWEDEN e-mail: pausch at saaf.se paul.schlyter at ausys.se paul at inorbit.com WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch From owner-fitsbits at kochab.cv.nrao.edu Mon Apr 5 08:31:52 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA07908 for fitsbits-spinner; Mon, 5 Apr 1999 08:30:30 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA07903 for ; Mon, 5 Apr 1999 08:30:27 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id IAA04182 for fitsbits at majordomo.cv.nrao.edu; Mon, 5 Apr 1999 08:30:26 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id XAA19046 for ; Sun, 4 Apr 1999 23:21:45 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id XAA03250 for ; Sun, 4 Apr 1999 23:21:44 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id XAA08190; Sun, 4 Apr 1999 23:21:43 -0400 To: fitsbits at fits.cv.nrao.edu Date: Sun, 4 Apr 1999 23:16:23 -0400 From: "Greg Mazujian" Message-ID: <7e999u$qjl$1 at clarknet.clark.net> Organization: Verio Mid-Atlantic Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!newsfeed.mathworks.com!news-peer.gip.net!news.gsl.net!gip.net!europa.clark.net!206.55.3.15!news.clark.net!not-for-mail Subject: new to group Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Hello, I am new to FITS . I have Microsoft Visual C++ v5.0. I am also new to that. I downloaded the FITS programs from NASA and attempted to compile them, but to no avail. I received so many errors. Any idea what I am doing wrong? Thanks in advance Greg From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 6 13:48:58 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA07006 for fitsbits-spinner; Tue, 6 Apr 1999 13:47:59 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA07001 for ; Tue, 6 Apr 1999 13:47:56 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA07964 for fitsbits at majordomo.cv.nrao.edu; Tue, 6 Apr 1999 13:47:56 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA06989 for ; Tue, 6 Apr 1999 13:45:05 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id NAA07927 for ; Tue, 6 Apr 1999 13:45:00 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA19910; Tue, 6 Apr 1999 13:44:59 -0400 To: fitsbits at fits.cv.nrao.edu Date: Tue, 6 Apr 1999 19:42:37 +0200 From: andekl at saaf.se (Anders Eklof) Message-ID: <1dpuubn.xyzv895vol16N at dialup174-4-16.swipnet.se> Organization: Svensk =?ISO-8859-1?Q?Amat=F6rastronomisk?= =?ISO-8859-1?Q?_F=F6rening?= Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed1.swip.net!swipnet!nntpserver.swip.net!not-for-mail References: <199904021512.KAA26763 at primate.cv.nrao.edu> Reply-To: andeeklo at mbox.ki.se Subject: Re: units Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric Greisen wrote: > Tim Pearson writes: > > On Wed, 31 Mar 1999, Francois Ochsenbein wrote: > > > > > - the Ohm sould be written with a capitalized O, > > > to be consistent with its origin (physicist's name) > > > > I disagree with this (trivial) point. I think that it is the normal > > practice of publishers in the english-speaking world *not* to > > capitalize the names of units, even those derived from proper names, > > such as "newton", "ohm", "joule", "jansky", "ampère", "ångström", etc. > > This may be a recommendation of the various international unions - I > > am not sure - but it is certainly advocated by, for example, the Royal > > Society (London). > > > > This follows normal english practice, in which proper names are > > capitalized, but not words derived from proper names, such as > > "sandwich", "boycott", etc. > > We are here not talking about spelled out names generally but > about abreviations for units. Judging from what I can see above (physicist's name), spelled out names is exactly what we are talking about. -- * Anders Eklöf * Phone: + 46 8581 74712 * "I blame you for * * Glimmerstigen 46 * e-mail: ae at radfys.ks.se * the moonlit sky" * * S-196 33 KUNGSÄNGEN * or andekl at saaf.se * ---- * * SWEDEN * * Tasmin Archer * From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 8 08:53:58 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA06750 for fitsbits-spinner; Thu, 8 Apr 1999 08:53:00 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA06745 for ; Thu, 8 Apr 1999 08:52:57 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id IAA13157 for fitsbits at majordomo.cv.nrao.edu; Thu, 8 Apr 1999 08:52:57 -0400 Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA21094 for ; Wed, 7 Apr 1999 13:54:33 -0400 (EDT) Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA07303; Wed, 7 Apr 1999 13:54:32 -0400 (EDT) Date: Wed, 7 Apr 1999 13:54:32 -0400 (EDT) Message-Id: <199904071754.NAA07303 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fitsbits at primate.cv.nrao.edu Subject: wcs.ps, scs.ps X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Minor mostly typographic changes have been made in both documents. The velocity system parameters have been clarified (I hope) in scs.ps and certain numeric values in wcs.ps have been corrected. These papers will ultimately affect how we think about our data - please read them. They are at ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/wcs.ps ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/Scs.ps Mark is again hard at work on Paper II. We will announce its availability asap. Thanks, Eric Greisen From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 8 09:05:12 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA06780 for fitsbits-spinner; Thu, 8 Apr 1999 09:05:09 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA06775 for ; Thu, 8 Apr 1999 09:05:06 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id JAA13191 for fitsbits at majordomo.cv.nrao.edu; Thu, 8 Apr 1999 09:05:06 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA21676 for ; Wed, 7 Apr 1999 18:12:40 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id SAA11567 for ; Wed, 7 Apr 1999 18:12:39 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id SAA30346 for ; Wed, 7 Apr 1999 18:12:38 -0400 Received: from amon.u-strasbg.fr(130.79.200.3) by palantir.cv.nrao.edu via smap (V1.3) id sma030340; Wed Apr 7 18:12:09 1999 Received: from vizir.u-strasbg.fr (vizir.u-strasbg.fr [130.79.128.13]) by amon.u-strasbg.fr (8.9.1a/8.9.0) with SMTP id AAA24396; Thu, 8 Apr 1999 00:05:20 +0200 (MET DST) Received: by vizir.u-strasbg.fr (5.x/SMI-SVR4) id AA06480; Thu, 8 Apr 1999 00:05:16 +0200 Message-Id: <9904072205.AA06480 at vizir.u-strasbg.fr> To: Eric Greisen Cc: fitsbits at fits.cv.nrao.edu Subject: Re: units In-Reply-To: Your message of Fri, 2 Apr 1999 10:12:30 -0500 (EST) . Date: Thu, 08 Apr 1999 00:05:15 +0200 From: Francois Ochsenbein Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric, I just proofread the last version of table4 and there are just the following typos: => remove the dagger in front of u (unified atomic mass unit), and ph (difficult to envisage milli-photons...), and solMass (an error in my previous message, sorry...) => could add the dagger in front of mag (the millimag is used, but I don't know other multiples in use) => the 26 exponent in the solLum definition is missing {} Let me know whenever the Paper II is ready, I'm eager to read it ! Thank you again, and sorry if my questions on units generated so many messages... but it helped to clarify the topic. I'm sure ! Francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)3 88 150 755 Email: francois at simbad.u-strasbg.fr (France) Fax: +33-(0)3 88 150 740 ================================================================================ From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 8 09:05:53 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA06796 for fitsbits-spinner; Thu, 8 Apr 1999 09:05:51 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA06791 for ; Thu, 8 Apr 1999 09:05:48 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id JAA13196 for fitsbits at majordomo.cv.nrao.edu; Thu, 8 Apr 1999 09:05:48 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA22037 for ; Wed, 7 Apr 1999 21:28:18 -0400 (EDT) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id VAA11882 for ; Wed, 7 Apr 1999 21:28:18 -0400 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA07835; Wed, 7 Apr 1999 21:28:10 -0400 (EDT) Date: Wed, 7 Apr 1999 21:28:10 -0400 (EDT) Message-Id: <199904080128.VAA07835 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Francois Ochsenbein Cc: Eric Greisen , fitsbits at fits.cv.nrao.edu Subject: Re: units In-Reply-To: <9904072205.AA06480 at vizir.u-strasbg.fr> References: <9904072205.AA06480 at vizir.u-strasbg.fr> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Francois Ochsenbein writes: > I just proofread the last version of table4 and there are just the > following typos: > => remove the dagger in front of u (unified atomic mass unit), and ph > (difficult to envisage milli-photons...), and solMass (an error in > my previous message, sorry...) I was visualizing Mega photons - but maybe that's just wishful thinking outside the radio range. Done > => could add the dagger in front of mag (the millimag is used, but I don't > know other multiples in use) Done > => the 26 exponent in the solLum definition is missing {} Typos re exponents (several) were fixed today. > > Let me know whenever the Paper II is ready, I'm eager to read it ! So am I - I have seen bits of it and Mark is doing a wonderful job. > > Thank you again, and sorry if my questions on units generated so > many messages... but it helped to clarify the topic. I'm sure ! They have caused a better standard to be proposed and one that unites two groups I hope. Your comments and repeated followups are very much appreciated. Thanks, Eric From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 8 23:45:41 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id XAA27779 for fitsbits-spinner; Thu, 8 Apr 1999 23:43:41 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id XAA27774 for ; Thu, 8 Apr 1999 23:43:38 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id XAA14947 for fitsbits at majordomo.cv.nrao.edu; Thu, 8 Apr 1999 23:43:38 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA04990 for ; Thu, 8 Apr 1999 17:37:59 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id RAA14267 for ; Thu, 8 Apr 1999 17:37:59 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id RAA25078; Thu, 8 Apr 1999 17:37:58 -0400 To: fitsbits at fits.cv.nrao.edu Date: 8 Apr 1999 17:37:16 -0500 From: Pete Ratzlaff Message-ID: <370d218c.0 at cfanews.harvard.edu> Organization: Harvard University Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!newsfeed.mathworks.com!newsfeed.cwix.com!129.250.35.146!iad-peer.news.verio.net!news.verio.net!news.harvard.edu!cfanews.harvard.edu!not-for-mail Subject: ANNOUNCE: CFITSIO.pm v0.91 Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Hello all, A new version of the Perl interface to William Pence's CFITSIO subroutine library is available. This version synchronizes with CFITSIO v2.031, and requires that version or later for proper installation. For more information on the CFITSIO subroutine library, see http://heasarc.gsfc.nasa.gov/fitsio New features in CFITSIO.pm v0.91 include: * implemented functions: - fits_get_col_display_width - fits_url_type - fits_real_col_bit_usht - fits_real_col_bit_uint * several bug fixes This version can be obtained at: http://hea-www.harvard.edu/~rpete/cfitsio/CFITSIO-0.91.tar.gz And also on your local CPAN mirror under: modules/by-authors/id/P/PR/PRATZLAFF/CFITSIO-0.91.tar.gz As always, you can find the latest version of CFITSIO.pm at http://hea-www.harvard.edu/~rpete/cfitsio Cheers, -Pete Ratzlaff From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 9 13:30:08 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA06794 for fitsbits-spinner; Fri, 9 Apr 1999 13:29:01 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA06789 for ; Fri, 9 Apr 1999 13:28:58 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA16784 for fitsbits at majordomo.cv.nrao.edu; Fri, 9 Apr 1999 13:28:58 -0400 Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA06778 for ; Fri, 9 Apr 1999 13:24:26 -0400 (EDT) Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA17415; Fri, 9 Apr 1999 13:24:25 -0400 (EDT) Date: Fri, 9 Apr 1999 13:24:25 -0400 (EDT) Message-Id: <199904091724.NAA17415 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fitsbits at primate.cv.nrao.edu Subject: wcs.ps and scs.ps X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Both wcs.ps and scs.ps have had modifications made. The latter was primarily the addition of a reference on relativistic velocities suggested by Don Wells. wcs.ps was changed to implement the suggestion copied below. Remarks about the actual (deprecated) status of CDELT were added by me. This status means that CDELT and its offspring may be used in writing, but only if the new forms are not used (i.e. CDji, PVj_m and version codes other than blank). The political machinations have settled on the idea that CDELT is deprecated but will have to be understood by readers for a long time to come. We are recommending that, either one uses solely older forms of coordinates or solely newer forms. Mark and I miss the simplicity of the CDELT formulation, but understand some of the problems perceived by the people who opposed the CDELT * PC formulation we had proposed. The desire for separate spelling for primary and secondary forms (below) is an offshoot of the change from CDELT * PC to CDj_i. Oh well, I think we are converging. Is there anyone who does not think so? See ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/wcs.ps ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/scs.ps Thanks, Eric W. Greisen --------------- Mail received from the OGIP project ------------------- Subject: Re: wcs draft Date: Thu, 08 Apr 1999 17:40:58 -0400 Eric, Here is a revision to the Table 7 in your wcs paper that has been recommended by representatives of several high energy astrophysics groups. The main change is that instead of having 'old' and 'new' versions of these keywords in the table, we continue to use the same keywords as have been used in the past when no version code letter is used, and adopt the new root names for the keywords only when the version code letter is used. The advantage of this is that the large body of software that reads and writes the old keywords will continue to work in the future in most cases (when no version letter is needed). Sincerely, Lorella Angelini, HEASARC/SAX Keith Arnaud, HEASARC Mike Corcoran, HEASARC/ROSAT Tom McGlynn, HEASARC Koji Mukai, HEASARC/ASCA William Pence, HEASARC Steve Snowden, HEASARC/XMM Jonathan McDowell, AXAF Science Center Arnold Rots, AXAF Science Center - --------------------------------------------------------------- Keyword Image BINTABLE vector Pixel List Description Array Primary 2ndary Primary 2ndary -------------------------------------------------------------- Axis Type CTYPEjs jCTYPn jCTYns TCTYPn TCTYns Axis Units CUNITjs jCUNIn jCUNns TCUNIn TCUNns Reference value CRVALjs jCRVLn jCRVns TCRVLn TCRVns Reference point CRPIXis iCRPXn iCRPns TCRPXk TCRPks Transformation matrix CDj_is jiCDn jiCDns TCDn_k TCn_ks Coordinate parameter PVj_ms jPVn_m jPn_ms TPVn_m TPn_ms Coordinate increment CDELTj jCDLTn jCDLns TCDLTn TCDLns ------- end ------- From owner-fitsbits at kochab.cv.nrao.edu Fri Apr 9 17:26:43 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA09789 for fitsbits-spinner; Fri, 9 Apr 1999 17:25:57 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA09784 for ; Fri, 9 Apr 1999 17:25:54 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id RAA18411 for fitsbits at majordomo.cv.nrao.edu; Fri, 9 Apr 1999 17:25:54 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA09772 for ; Fri, 9 Apr 1999 17:11:10 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id RAA18303 for ; Fri, 9 Apr 1999 17:11:09 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id RAA25275; Fri, 9 Apr 1999 17:11:08 -0400 To: fitsbits at fits.cv.nrao.edu Date: Fri, 09 Apr 1999 21:12:56 +0000 From: Godzilla Message-ID: <370E6D57.B39D28A6 at tin.it> Organization: TIN Path: newsfeed.cv.nrao.edu!chaos.aoc.nrao.edu!lynx.unm.edu!newshub.tc.umn.edu!news.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!skynet.be!Pollux.Teleglobe.net!server-b.cs.interbusiness.it!news.tin.it!not-for-mail Subject: raw fits images? Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Hello all, I am looking for raw fits images took with amatorial telescopes. Where may I find them? Thanks in advance Nicola From owner-fitsbits at kochab.cv.nrao.edu Sat Apr 10 20:17:42 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id UAA18786 for fitsbits-spinner; Sat, 10 Apr 1999 20:17:15 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id UAA18781 for ; Sat, 10 Apr 1999 20:17:11 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id UAA21681 for fitsbits at majordomo.cv.nrao.edu; Sat, 10 Apr 1999 20:17:11 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id FAA18152 for ; Sat, 10 Apr 1999 05:34:59 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id FAA20204 for ; Sat, 10 Apr 1999 05:34:58 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id FAA09532; Sat, 10 Apr 1999 05:34:57 -0400 To: fitsbits at fits.cv.nrao.edu Date: Sat, 10 Apr 1999 11:30:48 +0200 From: Jan Lustrup Message-ID: <370F1A48.258D at online.no> Organization: Telenor Online Public Access Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!newsfeed.mathworks.com!news-feed.inet.tele.dk!bofh.vszbr.cz!newsfeed1.online.no!newsfeed.online.no!news1.online.no!not-for-mail References: <370E6D57.B39D28A6 at tin.it> Subject: Re: raw fits images? Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Godzilla wrote: > > Hello all, > > I am looking for raw fits images took with amatorial telescopes. Where > may I find them? > > Thanks in advance > > Nicola Whats ???? -- Jan Lustrup LA3EQ Norway "http://home.sol.no/~lustrup/index.html" From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 13 12:57:36 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA06965 for fitsbits-spinner; Tue, 13 Apr 1999 12:55:35 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA06960 for ; Tue, 13 Apr 1999 12:55:32 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id MAA29593 for fitsbits at majordomo.cv.nrao.edu; Tue, 13 Apr 1999 12:55:31 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA15561 for ; Mon, 12 Apr 1999 14:02:54 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id OAA27176 for ; Mon, 12 Apr 1999 14:02:53 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id OAA03215 for ; Mon, 12 Apr 1999 14:02:50 -0400 Received: from tnm.stsci.edu(130.167.1.235) by palantir.cv.nrao.edu via smap (V1.3) id sma003209; Mon Apr 12 14:02:23 1999 Received: by stsci.edu (SMI-8.6/SMI-SVR4-DNI-8.0) id NAA16221; Mon, 12 Apr 1999 13:55:39 -0400 Received: from sol-srvr.stsci.edu(130.167.100.1) by tnm.stsci.edu via smtp-stsci (V2.1) id xma016204; Mon, 12 Apr 99 13:55:10 -0400 Received: from iris.stsci.edu by sol-srvr (8.8.8+Sun/SMI-SVR4) id NAA18077; Mon, 12 Apr 1999 13:55:04 -0400 (EDT) Received: by iris.stsci.edu (8.8.8+Sun/SMI-SVR4) id NAA02326; Mon, 12 Apr 1999 13:55:03 -0400 (EDT) Date: Mon, 12 Apr 1999 13:55:03 -0400 (EDT) From: hanisch at stsci.edu (Bob Hanisch) Message-Id: <199904121755.NAA02326 at iris.stsci.edu> To: fitsbits at fits.cv.nrao.edu Subject: Version 100-2.0 of NASA FITS Standard released X-Sun-Charset: US-ASCII Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk 12 April 1999 To the FITS Community: I am pleased to announce that NASA's Office of Standards and Technology (NOST) Accreditation Panel has reviewed and endorsed the revised FITS standard. The new version of the standard, 100-2.0, is dated 29 March 1999 and is available in Postscript, compressed (gzip) Postscript, and PDF formats at http://fits.gsfc.nasa.gov/. On behalf of the FITS Technical Panel, I would like to thank everyone who submitted comments concerning the draft standard. These comments helped the Technical Panel identify ambiguities in the document which (we hope) we have been able to repair. Attached below is a statement from Don Wells, chair of the IAU FITS Working Group and member of the NOST Accreditation Panel. I encourage everyone with an interest in FITS to read it carefully, as Don has done an extremely thorough job of reviewing the new standard. He explains what the Technical Panel has done and why, and why he believes that the regional FITS Committees and IAU FITS Working Group should now move quickly to adopt the new standard also. Finally, as someone who has worked on the FITS Standard for many years now, I note with some pride that FITS has just passed its 20th anniversary. The adoption of V100-2.0 by NOST is a fitting birthday present for us all! Please circulate this message to others in the astronomy community who may have an interest in FITS. Thanks, Bob Hanisch Chair, NASA FITS Technical Panel Data Systems Division Space Telescope Science Institute ----- Notes on the NOST FITS Standard & Process Don Wells FITS community representative on NOST Accreditation Panel Chair of IAU FITS Working Group [IAU-FWG] 1999-03-19 SUMMARY: The NOST [NASA Office of Standards and Technology] process which produced the NOST_100-1.2 draft standard appears to me to have been conducted properly, and to have produced a result which is acceptable. I therefore vote 'yes' on the question of whether this document should be accredited and become the FITS standard for NASA. Furthermore, I conclude that NOST_100-1.2 contains no 'uncorrectable errors'. I therefore recommend that, if no such errors are uncovered by the FITS committees, the committees should approve NOST_100-1.2 as the new official FITS standard of the International Astronomical Union [IAU]. -=- Introduction -=- I was asked by NOST to act as the FITS community representative on their Accreditation Panel [NOST-AP], in order to review the *process* by which the NOST_100-1.2 document was produced. NOST specified that "..the Accreditation Panel should ensure that, - the proposed standard is of high general quality (well organized, readable), - the target community was adequately notified of the draft standard and was afforded adequate chances to comment on the draft, - and comments were appropriately handled. In addressing comments, consensus need not be reached, but the Technical Panel needs to address all issues raised. There should not be inordinate influence by any special interest group.." In the discussion which follows I will reference two documents which are available at http://ssdoo.gsfc.nasa.gov/nost/apanel, "FITS Accreditation Panel Support Materials" [FAPSM, 1999-03-04, 69 pages] and "Definition of FITS, version 1.2" [DoF1.2, 1999-01-22, 96 pages]. After addressing the three accreditation criteria listed above, I will discuss the relationship of the NOST Technical Panel [NOST-TP] to the International Astronomical Union [IAU] FITS Working Group [IAU-FWG] and the special problem of 'uncorrectable errors'. -=- Is NOST_100-1.2 of high general quality? -=- My answer to this question is an emphatic 'yes!'. However, I also reviewed the comments to see whether the FITS community is critical of the general character of the document. For example, comment#1 [FAPSM:5.2,#1,p34] asks that deprecated features be highlighted in bold font. Comment#19 [p37-38] wants the Random Groups discussion reorganized. Comment#127 [p.58] says that a different form of Backus-Naur notation should be used in Appendix A of DoF1.2. These are rather minor criticisms of the style of the document. In each case the NOST-TP declined to make the style change requested, and I consider the justifications given for these decisions to be reasonable enough. -=- Were notification and opportunities to comment adequate? -=- The April 1998 announcement [FAPSM:4.0,p7] that NOST_100-1.2 was available for review was posted to a number of Email exploders and newsgroups (see the 'To' line of the message header on p.7). In particular, it was posted to newsgroup sci.astro.fits and its associated exploder 'fitsbits' which are the official places on the Internet where discussions of FITS occur. The announcement specified that comments should be posted publicly, not sent privately to the NOST-TP. This resulted in public followups by the community to the comments, and followups to the followups. In effect, the opportunity to comment was publicly announced repeatedly over a three month period. Some controversial issues produced extensive threads of public discussion, giving the Technical Panel a good sampling of the opinions of the FITS community. Four notable cases can be seen in FAPSM: [1] the proposal that OBJECT strings should conform to IAU Designations recommendations [FAPSM:5.2,#77-91,p51-53], [2] the proposal that FITS should support 64-bit integers [FAPSM:5.2,#142,p.61], [3] the proposal that FITS should support unsigned integers [FAPSM:5.2,#143,p.61] and [4] the strong demand that the NOST-TP delete or soften its deprecation of Random Groups [FAPSM:5.2,#144,p.61]. In all four cases the NOST-TP refused to take the action requested. I have reviewed the four responses, and consider them to be reasonable enough. The extensive public discussion of these controversial (and perennial) issues is an exemplary aspect of the *process* of creation of this standard. Comments were received from a diverse group of people: 11 Europeans, 6 non-NASA US national center people, 9 US university people and 6 NASA-related people. Many of the 11 Europeans are members of the European FITS committee, of course. Designers associated with most of the major software packages of astronomy are in the group that offered comments on DoF1.2. I conclude that the comments received by NOST-TP were reasonably representative of opinion in the worldwide FITS community. -=- Were comments properly handled? -=- In my opinion, the NOST-TP was quite responsive to the technical comments they received. In many of the comments and responses there is plenty of room for reasonable people to differ; a good example of such differences is the manner of specifying the rules for 4-digit and 2-digit years in date strings [FAPSM:5.2,#71,p49-50]. The NOST-TP generally refused to establish new *policy* for FITS, declaring policy issues to be the prerogative of IAU-FWG and 'out of scope' for the Panel. The NOST-TP did make decisions on a variety of technical (non-policy) issues which were previously ambiguous in the FITS standards. The question of which issues are technical and which are policy (political) matters is certainly a judgement call, and reasonable people can differ in these matters. Items [1], [2] and [3] cited in the previous section are examples where the NOST-TP ruled that proposed changes were out-of-scope. In these three cases I think the NOST-TP made the only ruling which they could properly make. For example, consider item [1] above, in which I (Don Wells) asked the NOST-TP to specify that value strings for OBJECT keywords should be in conformance with recommendations of the IAU TG on Designations. The NOST-TP refused. I not only accept this ruling against me, I applaud it, because we should not attempt to short-circuit the political process for making such decisions. In fact, I predicted that NOST-TP would rule against me, but submitted my request anyway as a means to get the issue before the community, to start the necessary process of creating consensus which might lead, ultimately, to an IAU-FWG agreement on the issue. This particular issue is still being debated in the FITS community; only two weeks ago an astronomer asked about OBJECT rules and got this reply from a member of the NOST-TP: "The NOST panel decided it was out of scope of its charter to introduce new restrictions or rules for the value of the OBJECT keyword or to define a new reserved keyword such as IAUDESIG, without the prior general agreement of the FITS community." [W.Pence sci.astro.fits 1999-03-10] Has there been 'inordinate influence by any special interest group' in the responses of the NOST-TP to the comments they received? Some members of the worldwide FITS community might worry that requirements or desires of specific NASA flight missions or facilities might exert an undue influence on the deliberations of the NOST-TP, due to the large number of NASA-related people on the NOST-TP (see [DoF1.2:Preface,p.'i'] for current and past members of NOST-TP). I have reviewed this question, and have concluded that these people represent multiple distinct missions with differing goals and operating in different types of radiation (UV, optical, IR), and that probably no single private agenda could dominate the processes of the NOST-TP. Both science and computing people are represented on the current and past NOST panels. I have also concluded that no single large software system is over-represented on NOST-TP; for example, the current panel includes the designer of AIPS (radio synthesis imaging), the chair of the IRAF (optical) Technical Working Group and the designer of the FITSIO package (high energy). Each of these people has institutional and project ties to international partners, and can be expected to consider the international aspects of their decisions. I conclude that any FITS feature decision which is acceptable to this set of people and the rest of the NOST-TP is likely to be acceptable to the whole worldwide FITS community. -=- Accreditation -=- I conclude that the three criteria which NOST specified for the NOST-AP to review have been satisfied, and therefore +------------+ | I vote YES | +------------+ on the question of whether DoF1.2 should advance from draft status to become the NASA FITS standard. In the remainder of this memorandum, I will review other criteria which will be relevant in the process by which DoF1.2 might become the official FITS standard of the IAU. -=- NOST Technical Panel: history, membership, role -=- The history of the versions of NOST_100-x.y produced by the NOST-TP is tabulated at [DoF1.2:J.0,p91]. Five different 1.x versions of the document have been publicly released over the past six years. These documents have been in regular use throughout the FITS community as the de facto FITS standards, in spite of the fact that the IAU-FWG has not yet formally endorsed any of them. DoF1.2 differs from the 1.1 version by a set of incremental changes which are tabulated in [FAPSM:6.2.I,pp62-64]. Some of the changes are merely rearrangements (such as moving the BINTABLE definition from an unofficial appendix to the main body of the formal standard). The point of mentioning this history is to emphasize that DoF1.2 is the latest version of a sequence of draft documents which have, for nearly a decade now, been in regular use and regular review by the FITS community as the de facto FITS standards. DoF1.2 therefore entered this final formal review process with the knowledge that most parts of it have already been reviewed and effectively approved by its end-user community many times over many years. Regarding the membership of NOST-TP, a key fact to note is that a number of the members are also members of the North American (AAS-WGAS) FITS Committee and/or the IAU-FWG. This is not a conflict of interest if you view the NOST-TP and even the regional FITS committees as acting somewhat like committees and subcommittees in the typical legislative process: members of the full body are appointed to develop proposals for the full body to consider. What is the role of the NOST-TP with respect to the IAU-FWG and the three regional FITS committees? The IAU-FWG never voted to charter the NOST-TP activity, and so the NOST-TP has no official status from the IAU-FWG point of view. However, it is a fact that ten years ago I and other members of the FITS committees recommended that the NASA Astrophysics Division fund the FITS standardization effort as a part of the FITS Support Office activity under NOST. We understood that it would not be practical to negotiate the myriad of details of an official standards document by the usual FITS negotiation processes. At that time (and still today) there was no other agency which could fund such an effort. My opinion, as current Chair of IAU-FWG, is that the NOST-TP has acted as an ad hoc task force which has done the hard work of preparing a clean version of the FITS standards for the IAU-FWG. The Chair of the NOST-TP recently commented of the role of NOST-TP: "My view has always been that the Technical Panel was put into place to look at the options and select the best solution, rather than simply turn the discussion loose in the community." [Bob Hanisch, private communication 1999-03-10] I consider the diversity and the technical skills of the NOST-TP to be about as good as could be achieved in practice. If a similar but different set of individuals had been picked for NOST-TP, I expect that they would have produced a similar, but not identical result. I therefore see no reason to revisit any of the many issues which the NOST-TP has debated and settled in their many work sessions. If it is accredited, the NOST FITS standard will be submitted to the three regional FITS committees, and will thereby become an official document in the IAU-FWG process. +--------------------------------------------------------------+ | I recommend that the regional FITS committees and IAU-FWG | | accept the DoF1.2 document as-is, without further changes, | | assuming no 'uncorrectable errors' are discovered in review. | +--------------------------------------------------------------+ -=- On 'Uncorrectable Errors' -=- The FITS community has agreed that changes to FITS will always be backwards compatible (often described as 'once FITS, always FITS'). The policy is explicitly specified in NOST_100-1.2 (DoF1.2:9.0,p.51). The policy implies that FITS standards committees must be especially careful when drafting new FITS standards to avoid making decisions which they might later wish they had not made, because it will be difficult if not impossible to correct those errors. In particular, the committees should be cautious whenever they are specifying rules which will preclude whole paths which the future evolution of FITS might want to take. Furthermore, they should be cautious whenever they are specifying rules beyond the minimum set needed for interchange, because of the risk of precluding innovative uses of 'holes' in the ruleset. FITS must always leave room for growth and innovation. Therefore, I have reviewed the decisions of the NOST-TP to check for cases where decisions have been made by the NOST-TP which cannot be easily corrected by future IAU-FWG actions or where decisions have been made which might limit growth or innovation. The NOST-TP was sensitive to the future evolution of FITS; for example, in [FAPSM:5.2,#26,p39] they note that 'special records' are a key 'escape hatch' for the format and in [FAPSM:5.2,#28,p40] they deliberately leave room for a definition which they do not specify. I have reviewed the changes from DoF1.1 (1995-09) to DoF1.2 [FAPSM:6.2.I,p62]. In section 5.2, NOST-TP decided that keyword values cannot be an array of values. This is an instance in which NOST-TP has explicitly deleted functionality which was specified in the original FITS Agreement of 1979. Eric Greisen, who negotiated that Agreement with me in 1979, is a member of NOST-TP, and he tells me that the NOST-TP believed that the functionality has never been used, and so no harm is being done. I now believe that multivalued keywords are a bad design idea, on grounds that they are an example of 'repeating groups' in database design, and therefore I agree with this decision by NOST-TP. I reviewed the changes from DoF1.2draft to DoF1.2 [FAPSM:6.2.II,p64], but saw no 'uncorrectable error' issues. I reviewed my list of possible evolutionary paths for FITS (see section 5 of http://www.cv.nrao.edu/adass/adassVI/wellsd.html), but found nothing precluded by DoF1.2 rules. I reviewed the list of differences from the IAU FITS papers [DoF1.2:E,p71] but found no issues not discussed elsewhere in this memorandum. I am aware of three instances in which NOST-TP has definitely extended the FITS standards, not just clarified or codified them: * Section 5.1.2.3 [DoF1.2:p16] allows keyword value fields to be blank, i.e. 'undefined'. This concept has been invented by NOST-TP. * Section 5.2.1 [DoF1.2:p16-17] says: "..no length limit less than 68 is implied for character-valued keywords" (previously, FITS rules said that some keywords should carry their information in 8 chars). * Section 8.1.4 [DoF1.2:p38] says regarding the data arrays of TABLE extensions: "There may be characters in a table row that are not included in any field". I have searched, but have found no rule which limits what those characters may be, other than the opening sentence of 8.1.3 which says they must be "ASCII characters" (defined on p.7 as 7-bit ASCII, which includes the 'ASCII Control' column of Table G.1 on p.82). The TABLE extension paper [Astron. Astrophys. Suppl. Ser. 73, 365-372 (1988)] makes it absolutely clear that the TABLE data matrix is to be *printable* ASCII codes, but the NOST-TP rule will allow *non-printable* codes such as CR, LF and HT into characters which are not a part of table entry fields. In my opinion these three actions by NOST-TP are good things ('removing unneeded restrictions' as noted in [FAPSM:5.2,#135,p60]), and the community should endorse them implicitly by adopting DoF1.2. I believe they will not cause any uncorrectable error problems. In the cases where NOST-TP declared that some proposed change would be 'out of scope' for NOST-TP, and declined to act, there is nothing to prevent members of the FITS community submitting proposals to their regional FITS committees, persuading the other FITS committees to endorse them and then persuading IAU-FWG to adopt them. Future versions of NOST's DoF will then be modified to incorporate such rulings by IAU-FWG. The case of the 'deprecation' of the Random Groups format is somewhat troubling; it produced a major thread of discussion during the comment period [FAPSM:5.2,#144,p61]. This problem arose because ten years ago, when the BINTABLE extension became part of the FITS standards, there was a general desire to replace Random Groups with BINTABLE in all production applications, and it was generally believed that this would naturally happen during the 90s. The NOST-TP therefore deprecated Random Groups in early versions of DoF. It is still possible that BINTABLE will replace Random Groups in production, but it can be argued that the transition has failed for various sociological and political reasons, and that Random Groups will be used forevermore. The people who take the latter position strongly object to the deprecation of Random Groups in DoF1.2, while the NOST-TP takes the position that the issue was decided many years ago and they don't want to change back. This is a question of exactly how the definition of 'deprecated' is worded in Section 3 [p8] of DoF1.2, and of exactly how the deprecation is worded in the introductory paragraph of Section 7 [p31]. In any case, radio and optical interferometry instrument systems will continue to write Random Groups as needed, all future versions of the FITS standard will be obliged to continue reproducing the rules of random groups as an official part of the FITS standard *forever* and the relevant datasystems will be obliged to support the reading of Random Groups *forever*, so this wording dispute has no effect on astronomy research. In particular, it does not involve an uncorrectable error. +----------------------------------------------------------------+ | I conclude that decisions made by NOST-TP have not produced | | any 'uncorrectable errors' which would be risky for IAU-FWG to | | endorse by adopting DoF1.2 as the new IAU FITS standard. | +----------------------------------------------------------------+ -=- Trivial Typographical Errorss -=- * remove 'to' from 'Deprecated' definition on p.8 of DoF1.2. * reword the last sentence of item 33 on p.78 of DoF1.2. [Note: the above errors have been corrected, and the cover page, etc., have been updated to reflect the new version number and change in status from draft to final form. RJH, 29 March 1999.] From owner-fitsbits at kochab.cv.nrao.edu Wed Apr 14 18:54:53 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA19858 for fitsbits-spinner; Wed, 14 Apr 1999 18:54:32 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA19853 for ; Wed, 14 Apr 1999 18:54:29 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id SAA00226 for fitsbits at majordomo.cv.nrao.edu; Wed, 14 Apr 1999 18:54:28 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id FAA15712 for ; Wed, 14 Apr 1999 05:06:37 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id FAA31500 for ; Wed, 14 Apr 1999 05:06:35 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id FAA10369; Wed, 14 Apr 1999 05:06:34 -0400 To: fitsbits at fits.cv.nrao.edu Date: Wed, 14 Apr 1999 10:57:04 +0200 From: "Arno M. Plug" Message-ID: <37145860.3B658504 at iso.vilspa.esa.es> Organization: TERMA AS/Leiden Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!newsfeed.berkeley.edu!news-feed.inet.tele.dk!bofh.vszbr.cz!newsgate.cistron.nl!het.net!news.belnet.be!news.rediris.es!news-2.rediris.es!news.laeff.esa.es!not-for-mail Subject: FITS and Java Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Hi, I am looking for any information on any Java packages/implementations that provide ways of browsing and visualizing scientific data in FITS format. In case you know any or about any related information, please let me know. Thanks and regards, Arno. From owner-fitsbits at kochab.cv.nrao.edu Wed Apr 14 18:54:59 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA19851 for fitsbits-spinner; Wed, 14 Apr 1999 18:54:10 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA19846 for ; Wed, 14 Apr 1999 18:54:06 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id SAA00220 for fitsbits at majordomo.cv.nrao.edu; Wed, 14 Apr 1999 18:54:06 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id EAA11533 for ; Wed, 14 Apr 1999 04:03:53 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id EAA31330 for ; Wed, 14 Apr 1999 04:03:52 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id EAA09707; Wed, 14 Apr 1999 04:03:50 -0400 To: fitsbits at fits.cv.nrao.edu Date: Wed, 14 Apr 1999 09:02:31 +0100 From: Peter Bunclark Message-ID: <37144B96.543D2893 at ast.cam.ac.uk> Organization: Institute of Astronomy Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!remarQ-easT!supernews.com!remarQ.com!tank.news.pipex.net!pipex!newsfeed.eris.dera.gov.uk!diablo.dera.gov.uk!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail References: <7e999u$qjl$1 at clarknet.clark.net> Subject: Re: new to group Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk The last thing you did wrong was to not state precisely what the first error was. Peter. Greg Mazujian wrote: > Hello, > I am new to FITS . I have Microsoft Visual C++ v5.0. I am also new > to that. I downloaded the FITS programs from NASA and attempted to compile > them, but to no avail. I received so many errors. Any idea what I am doing > wrong? Thanks in advance > > Greg From owner-fitsbits at kochab.cv.nrao.edu Thu Apr 15 14:37:54 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id OAA29989 for fitsbits-spinner; Thu, 15 Apr 1999 14:37:14 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA29984 for ; Thu, 15 Apr 1999 14:37:11 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id OAA02462 for fitsbits at majordomo.cv.nrao.edu; Thu, 15 Apr 1999 14:37:10 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA29814 for ; Thu, 15 Apr 1999 10:18:13 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id KAA01942 for ; Thu, 15 Apr 1999 10:18:12 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA09909 for ; Thu, 15 Apr 1999 10:18:10 -0400 Received: from silk.gsfc.nasa.gov(128.183.16.209) by palantir.cv.nrao.edu via smap (V1.3) id sma009897; Thu Apr 15 10:17:57 1999 Received: by silk.gsfc.nasa.gov id AA22133; Thu, 15 Apr 1999 10:28:51 -0400 Message-Id: <3715F3DF.AE72AF6F at silk.gsfc.nasa.gov> Date: Thu, 15 Apr 1999 10:12:47 -0400 From: Tom McGlynn Organization: NASA/GSFC X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: "Arno M. Plug" Cc: fitsbits at fits.cv.nrao.edu Subject: Re: FITS and Java References: <37145860.3B658504 at iso.vilspa.esa.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Dear Arno, There are a systems available for handling FITS in Java. You may want to look at the Java FITS library that I've written to access image and binary table FITS data. [Try the links in http://heasarc.gsfc.nasa.gov/docs/heasarc/fits/fits_libraries.html ] There are higher level visualization packages avaiable. The NCSA's Horizon system does 2-D visualization of FITS images [ http://imagelib.ncsa.uiuc.edu/Horizon ] There's a package WebWinds developed at JPL which handles FITS data and includes visualization tools. [ http://webwinds.jpl.nasa.gov/ ] There are several other systems, e.g., SkyView, in which a visualizer for FITS images is embedded and where one might extract the relevant code. [ Try the Java interface under http://skyview.gsfc.nasa.gov ] Hope these starting points help. Regards, Tom McGlynn NASA/GSFC "Arno M. Plug" wrote: > > Hi, > > I am looking for any information on any Java packages/implementations > that provide ways of browsing and visualizing scientific data in FITS > format. In case you know any or about any related information, please > let me know. > > Thanks and regards, > > Arno. From owner-fitsbits at kochab.cv.nrao.edu Sun Apr 18 19:06:18 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id TAA04135 for fitsbits-spinner; Sun, 18 Apr 1999 19:02:53 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id TAA04130 for ; Sun, 18 Apr 1999 19:02:50 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id TAA11546 for fitsbits at majordomo.cv.nrao.edu; Sun, 18 Apr 1999 19:02:49 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA14994 for ; Fri, 16 Apr 1999 14:08:21 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id OAA05002 for ; Fri, 16 Apr 1999 14:08:20 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id OAA27178; Fri, 16 Apr 1999 14:08:19 -0400 To: fitsbits at fits.cv.nrao.edu Date: 16 Apr 1999 16:11:07 GMT From: nolan at deuteron.lpl.arizona.edu (Michael Nolan) Message-ID: <7f7ner$3a0$1 at news.ccit.arizona.edu> Organization: Arecibo Observatory / Cornell University Path: newsfeed.cv.nrao.edu!chaos.aoc.nrao.edu!newshost.nmt.edu!logbridge.uoregon.edu!feeder.qis.net!feed1.news.rcn.net!rcn!korova.insync.net!uunet!ffx.uu.net!in3.uu.net!news.Arizona.EDU!nolan References: <199904091724.NAA17415 at primate.cv.nrao.edu> Subject: Re: wcs.ps and scs.ps Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Comments on the wcs paper (1999 April 9 version): I can reasonably forsee the usefullness of airmass and unit optical depth as axis dimensions. In table 4, adu means A/D converter. Do you mean converter (as in physical device), or do you mean DN? I can see a value in both, and have a specific need for the former, since we have four parallel IF chains simultaneously sampled. You removed the trig functions, which are mainly useful for projections, and can be handled in paper II, but have other applications, such as airmass again. I suspect that if trig functions are needed, they will simply be used withut difficulty. The main problem would be how to represent the inverse trig functions, as it would be better to choose now than to have all of the possibilities be used later. -- Mike Nolan +1 809 878 2612 ext 280 Fax: +1 809 878 1861 nolan at naic.edu Arecibo Observatory/Cornell University POBox 995, Arecibo, Puerto Rico 00613 From owner-fitsbits at kochab.cv.nrao.edu Mon Apr 19 11:36:25 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA04916 for fitsbits-spinner; Mon, 19 Apr 1999 11:36:08 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA04911 for ; Mon, 19 Apr 1999 11:36:05 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id LAA13202 for fitsbits at majordomo.cv.nrao.edu; Mon, 19 Apr 1999 11:36:05 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA04862 for ; Mon, 19 Apr 1999 11:12:41 -0400 (EDT) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id LAA13116 for ; Mon, 19 Apr 1999 11:12:41 -0400 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA22968; Mon, 19 Apr 1999 11:12:39 -0400 (EDT) Date: Mon, 19 Apr 1999 11:12:39 -0400 (EDT) Message-Id: <199904191512.LAA22968 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: nolan at deuteron.lpl.arizona.edu (Michael Nolan) Cc: fitsbits at fits.cv.nrao.edu Subject: Re: wcs.ps and scs.ps Newsgroups: sci.astro.fits In-Reply-To: <7f7ner$3a0$1 at news.ccit.arizona.edu> References: <199904091724.NAA17415 at primate.cv.nrao.edu> <7f7ner$3a0$1 at news.ccit.arizona.edu> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Michael Nolan writes: > Comments on the wcs paper (1999 April 9 version): > > I can reasonably forsee the usefullness of airmass and unit optical depth > as axis dimensions. I am unfamiliar with airmass, does it have a clear definition? Optical depth is unitless. Can you describe how specifying that it is optical depth in the units string (rather than the CTYPEn string) is needed. > > In table 4, adu means A/D converter. Do you mean converter (as in > physical device), or do you mean DN? I can see a value in both, and > have a specific need for the former, since we have four parallel IF > chains simultaneously sampled. I am also unfamiliar with these units. Can Francois or one of the units gurus at OGIP comment on this? > > You removed the trig functions, which are mainly useful for projections, Actually they have no use whatsoever in celestial projections. The only units strings are 'deg' in Paper II, which should be announced in < 1 day I hope. > and can be handled in paper II, but have other applications, such > as airmass again. I suspect that if trig functions are needed, they > will simply be used withut difficulty. The main problem would be how to > represent the inverse trig functions, as it would be better to choose now than > to have all of the possibilities be used later. I do not know what use inverse trig functions could have and how to attach meaning to them as units. Do you have any specific examples in mind? Please describe some in detail. I agree that cos(elevation) axes have occurred to me. Are there other uses for even the forward trig functions? We need help from the community in such matters because our experience has serious limitations. BTW: I have put a new version of wcs.ps out with a few additions to the pixel regularization section - a keyword to specify the magnitude of the correction on each axis. See ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen/wcs.ps.gz Thanks, Eric W. Greisen From owner-fitsbits at kochab.cv.nrao.edu Mon Apr 19 12:13:02 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA05077 for fitsbits-spinner; Mon, 19 Apr 1999 12:13:00 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA05072 for ; Mon, 19 Apr 1999 12:12:57 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id MAA13326 for fitsbits at majordomo.cv.nrao.edu; Mon, 19 Apr 1999 12:12:57 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA05059 for ; Mon, 19 Apr 1999 12:05:22 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id MAA13306 for ; Mon, 19 Apr 1999 12:05:21 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id MAA17715 for ; Mon, 19 Apr 1999 12:05:18 -0400 Received: from aosun.naic.edu(192.65.176.4) by palantir.cv.nrao.edu via smap (V1.3) id sma017709; Mon Apr 19 12:05:07 1999 Received: from nevis.naic.edu (nevis.naic.edu [192.65.176.64]) by aosun.naic.edu (8.9.1/8.9.1) with SMTP id MAA09817 for ; Mon, 19 Apr 1999 12:02:31 -0400 (GMT-0400) Received: from radar.naic.edu by nevis.naic.edu (4.1/SMI-4.1) id AA12060; Mon, 19 Apr 99 12:02:25 AST Received: by radar.naic.edu (8.8.8+Sun/SMI-SVR4) id MAA11148; Mon, 19 Apr 1999 12:02:24 -0400 (AST) Date: Mon, 19 Apr 1999 12:02:24 -0400 (AST) From: nolan at naic.edu (Mike Nolan) Message-Id: <199904191602.MAA11148 at radar.naic.edu> To: fitsbits at fits.cv.nrao.edu Subject: Re: wcs.ps and scs.ps Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk > I am unfamiliar with airmass, does it have a clear definition? Airmass is atmospheric optical depth normalized to zenith optical depth assuming a spherically uniform atmosphere. It is usually approximated as sec(zenith angle), which is the only other case (besides sin za) I can think of that needs explicit trig. One generally measures extinction as a function of airmass for calibration of optical photometry. I don't have any idea why one would need inverse trig functions, I only wanted to note that they are one of the cases where you'd rather choose the notation in advance. -Mike --------------------------- Mike Nolan +1 787 878 2612 Home: +1 787 895 6746 Fax: +1 787 878 1861 Arecibo Observatory / Cornell University HC03 Box 53995, Arecibo, Puerto Rico 00612 From owner-fitsbits at kochab.cv.nrao.edu Mon Apr 19 13:55:52 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA05275 for fitsbits-spinner; Mon, 19 Apr 1999 13:55:38 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA05270 for ; Mon, 19 Apr 1999 13:55:35 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA13553 for fitsbits at majordomo.cv.nrao.edu; Mon, 19 Apr 1999 13:55:34 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA05223 for ; Mon, 19 Apr 1999 13:29:46 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id NAA13516 for ; Mon, 19 Apr 1999 13:29:44 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id NAA21744 for ; Mon, 19 Apr 1999 13:29:44 -0400 Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3) id sma021741; Mon Apr 19 13:29:42 1999 Received: from xebec.harvard.edu (xebec [131.142.52.100]) by head-cfa.harvard.edu (8.9.1a/8.9.0) with ESMTP id NAA19999; Mon, 19 Apr 1999 13:22:50 -0400 (EDT) From: Arnold Rots Received: (from arots at localhost) by xebec.harvard.edu (8.9.1/8.9.0) id NAA14111; Mon, 19 Apr 1999 13:22:50 -0400 (EDT) Message-Id: <199904191722.NAA14111 at xebec.harvard.edu> Subject: Re: wcs.ps and scs.ps In-Reply-To: <199904191512.LAA22968 at primate.cv.nrao.edu> from Eric Greisen at "Apr 19, 99 11:12:39 am" To: egreisen at valen.cv.nrao.edu (Eric Greisen) Date: Mon, 19 Apr 1999 13:22:49 -0400 (EDT) Cc: nolan at deuteron.lpl.arizona.edu, fitsbits at fits.cv.nrao.edu X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric Greisen wrote: > Michael Nolan writes: > > Comments on the wcs paper (1999 April 9 version): > > > > In table 4, adu means A/D converter. Do you mean converter (as in > > physical device), or do you mean DN? I can see a value in both, and > > have a specific need for the former, since we have four parallel IF > > chains simultaneously sampled. > > I am also unfamiliar with these units. Can Francois or one of the > units gurus at OGIP comment on this? adu is the (pseudo-)unit of the raw numbers as they come out of the A/D converter device - to be transformed into energy. In HEA, it typically (but nor exclusively) refers to the output of A/D converters that process CCD read-outs, - Arnold > > > Eric W. Greisen -------------------------------------------------------------------------- Arnold H. Rots AXAF Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 81 fax: +1 617 495 7356 Cambridge, MA 02138 arots at head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 20 10:01:25 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA26243 for fitsbits-spinner; Tue, 20 Apr 1999 10:00:29 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA26238 for ; Tue, 20 Apr 1999 10:00:26 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA15865 for fitsbits at majordomo.cv.nrao.edu; Tue, 20 Apr 1999 10:00:25 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id DAA17434 for ; Tue, 20 Apr 1999 03:49:26 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id DAA15119 for ; Tue, 20 Apr 1999 03:49:25 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id DAA10398 for ; Tue, 20 Apr 1999 03:49:24 -0400 Received: from crux.tip.csiro.au(130.155.194.32) by palantir.cv.nrao.edu via smap (V1.3) id sma010385; Tue Apr 20 03:49:22 1999 Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.tip.CSIRO.AU (8.9.0.Beta5/8.9.0.Beta5/TIPAT-1.1a) with ESMTP id RAA24070 for ; Tue, 20 Apr 1999 17:46:48 +1000 (EST) Received: from grus.atnf.CSIRO.AU (localhost [127.0.0.1]) by grus.atnf.CSIRO.AU (8.7.5/8.7.3) with ESMTP id RAA14656 for ; Tue, 20 Apr 1999 17:46:46 +1000 (EST) Message-Id: <199904200746.RAA14656 at grus.atnf.CSIRO.AU> X-Mailer: exmh version 2.0.2 2/24/98 To: fitsbits at fits.cv.nrao.edu Subject: WCS paper 2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Apr 1999 17:46:46 +1000 From: Mark Calabretta Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Paper II in the WCS series "Representations of Celestial Coordinates in FITS" is now available for comment. The draft dated 1999/04/20 is available immediately from my home page http://www.atnf.csiro.au/people/mcalabre. By the time most people read this it should also be available from Eric's ftp area ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen. Apart from changes required for conformity with Paper I, the main changes have been to clarify some subtle points, explain why some things had to be done as they were, provide additional background material, and provide a further example of header interpretation and three examples of header construction. At the request of the optical community, the TAN projection has been generalized with the addition of a distortion function and an example is given of translating a DSS header into it. There was also a minor correction to Eq. 45 for Airy's projection. Some material which should be common knowledge was removed to simplify the paper slightly. Some alternate and less useful forms of the projection equations were also removed. The graticules are now all drawn to scale. Thanks, Mark Calabretta (mcalabre at atnf.csiro.edu) Eric W. Greisen (egreisen at nrao.edu) From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 20 10:02:49 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA26256 for fitsbits-spinner; Tue, 20 Apr 1999 10:01:56 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA26251 for ; Tue, 20 Apr 1999 10:01:53 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA15884 for fitsbits at majordomo.cv.nrao.edu; Tue, 20 Apr 1999 10:01:52 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id HAA25894 for ; Tue, 20 Apr 1999 07:00:29 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id HAA15557 for ; Tue, 20 Apr 1999 07:00:28 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id HAA17562; Tue, 20 Apr 1999 07:00:27 -0400 To: fitsbits at fits.cv.nrao.edu Date: Tue, 20 Apr 1999 11:59:45 +0100 From: Peter Bunclark Message-ID: <371C5E21.265F0C35 at ast.cam.ac.uk> Organization: Institute of Astronomy Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!newsfeed.berkeley.edu!news-feed.inet.tele.dk!bofh.vszbr.cz!news.belnet.be!news-ge.switch.ch!diablo.dera.gov.uk!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail References: <199904191602.MAA11148 at radar.naic.edu> Subject: Re: wcs.ps and scs.ps Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Mike Nolan wrote: > atmosphere. It is usually > approximated as sec(zenith angle), which is the only other case I'd say ``it is usually calculated to high precision, often with a call to slaAirmas()''. Pete. From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 20 13:26:42 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA26976 for fitsbits-spinner; Tue, 20 Apr 1999 13:25:53 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA26971 for ; Tue, 20 Apr 1999 13:25:50 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA16240 for fitsbits at majordomo.cv.nrao.edu; Tue, 20 Apr 1999 13:25:50 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA26911 for ; Tue, 20 Apr 1999 12:25:36 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id MAA16130 for ; Tue, 20 Apr 1999 12:25:35 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id MAA32272 for ; Tue, 20 Apr 1999 12:25:35 -0400 Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3) id sma032269; Tue Apr 20 12:25:11 1999 Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.16.178]) by wheelo.gsfc.nasa.gov (8.8.8/8.8.8) with SMTP id MAA02028 for ; Tue, 20 Apr 1999 12:19:12 -0400 (EDT) Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4) id MAA18093; Tue, 20 Apr 1999 12:18:42 -0400 Message-ID: <371CA8E2.9F560C9D at tetra.gsfc.nasa.gov> Date: Tue, 20 Apr 1999 12:18:42 -0400 From: William Pence Organization: NASA/GSFC X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: FITSBITS Subject: Fverify for Version 100-2.0 of NASA FITS Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk New FITS File Conformance Test Program This is to announce the release of a new version of the FITS file verification program called 'fverify' that tests any FITS file to see if it conforms to the FITS Standard in every detail. This new version of fverify has been completely rewritten by HEASARC programmer Ning Gan to check that the FITS file meets every requirement in the newly released Version 100-2.0 of the NASA FITS Standard (available at http://fits.gsfc.nasa.gov/). A list of all the error and warning conditions fverify will detect is attached at the end of this message. Fverify is now available as a stand-alone utility program for most Unix platforms from the FTOOLS Web site at http://legacy.gsfc.nasa.gov/ftools/ftools_select.html It will also be included in the next release of the FTOOLS software package sometime later this year. While fverify is designed to exhaustively check every requirement or recommendation in the new FITS Standard, we cannot guarantee that it will in fact detect every possible nonconformance. We would appreciate receiving reports of any FITS format errors that it does not detect at ftoolshelp at athena.gsfc.nasa.gov. ERROR conditions reported by fverify: ------------------------------------- - Header contains illegal ASCII character (outside ASCII 32-126) - Keyword name contains illegal character - Keyword value field has illegal format - Value and comment fields not separated by a slash character - END keyword not blank in columns 9 - 80 - Required keywords out of order - Required keyword duplicated elsewhere in the header - Required or reserved keyword with wrong data type - Required or reserved keyword with value outside legal range - EXTEND not present in the primary array if there are extensions - BLOCKED, if present, not in the first 36 keywords in the primary array - BLANK is present when primary array or Image extension has BITPIX < 0 - XTENSION, EXTNAME, EXTVER, or EXTLEVEL in the primary array - TFIELDS, TBCOLn, TFORMn, TSCALn, TZEROn, TNULLn, TTYPEn, TUNITn, TDISPn, TDIMn, or THEAP in the primary array or Image extension - SIMPLE, EXTEND, or BLOCKED in any extension - BSCALE, BZERO, BUNIT, BLANK, DATAMAX, DATAMIN, CTYPEn, CRPIXn, CROTAn, CRVALn or CDELTn in an ASCII or Binary table - TDIMn or THEAP in an ASCII table - TBCOLn in a Binary table - XTENSION, TFORMn, TDISPn or TDIMn value contains leading spaces - Index on any of the WCS keywords (CRPIXn, CRVALn, CDELTn, CROTAn and CTYPEn) greater than NAXIS - Index on any of the table column descriptor keywords (TTYPEn, TFORMn, etc.) greater than TFIELDS - TSCALn or TZEROn present for an ASCII, logical, or Bit column - In Binary tables, TNULLn for a column with other than B, I, or J type - In Binary tables, THEAP exists and PCOUNT = 0 - TDISPn with a value that is inconsistent with the column datatype - All data values in the image or table have a valid format - The number of elements in a row of a variable length array column is greater than the maximum number of elements given by TFORMn - A value in a variable length array has an address which lies outside the data heap - The header fill bytes, if any, not all blanks - The data file bytes, if any, not all blanks in ASCII tables or all zeros in any other type of HDU. - Any characters, if any, between defined ASCII table fields with an ASCII value > 127 - Any extra bytes in the file beyond the end of the last HDU WARNING conditions reported by fverify: --------------------------------------- - SIMPLE = F - use of deprecated keywords BLOCKED or EPOCH - 2 HDUS have identical EXTNAME, EXTVER, and EXTLEVEL values - BSCALE = 0 - TSCALEn = 0 - TNULL < 0 or TNULL > 255 for B column in a Binary table - TNULL < -32768 or TNULL > 32767 for I column in a Binary table - TFORMn = 'rAw' and r is not a multiple of w - DATE = 'dd/mm/yy' and 00 <= yy <= 09 - duplicated keyword (except COMMENT, HISTORY, blank, etc.) - column name (TTYPEn) does not start with a letter - column name has characters other than letter, digit and underscore - column names are not unique within the first 16 chars - calculated checksum inconsistent with CHECKSUM and DATASUM --------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 20 23:08:23 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id XAA01215 for fitsbits-spinner; Tue, 20 Apr 1999 23:08:09 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id XAA01210 for ; Tue, 20 Apr 1999 23:08:06 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id XAA17399 for fitsbits at majordomo.cv.nrao.edu; Tue, 20 Apr 1999 23:08:05 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id UAA01123 for ; Tue, 20 Apr 1999 20:25:08 -0400 (EDT) Received: from gorilla.cv.nrao.edu (gorilla.cv.nrao.edu [192.33.115.9]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id UAA17039 for ; Tue, 20 Apr 1999 20:25:06 -0400 Received: (from bcotton at localhost) by gorilla.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id UAA22980; Tue, 20 Apr 1999 20:25:05 -0400 (EDT) Date: Tue, 20 Apr 1999 20:25:05 -0400 (EDT) From: Bill Cotton Message-Id: <199904210025.UAA22980 at gorilla.cv.nrao.edu> To: fitsbits at fits.cv.nrao.edu CC: bcotton at gorilla.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released In-Reply-To: <199904121755.NAA02326 at iris.stsci.edu> References: <199904121755.NAA02326 at iris.stsci.edu> Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk I note with dismay that this version of the NASA FITS standard still tries to deprecate the FITS random groups format. This format is in widespread use in the radio interferometry community. The attempt to deprecate this format is in violation of the fundamental principle of FITS, "once FITS, always FITS". Clintonian weasel words on the subject are not helpful. I am forced to question the responsiveness of the NASA committee to the non-NASA FITS community. -Bill Cotton From owner-fitsbits at kochab.cv.nrao.edu Sun Apr 25 14:59:41 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id OAA04505 for fitsbits-spinner; Sun, 25 Apr 1999 14:57:34 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA04500 for ; Sun, 25 Apr 1999 14:57:31 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id OAA30287 for fitsbits at majordomo.cv.nrao.edu; Sun, 25 Apr 1999 14:57:31 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA27585 for ; Fri, 23 Apr 1999 15:20:44 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id PAA24269 for ; Fri, 23 Apr 1999 15:20:43 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id PAA18467; Fri, 23 Apr 1999 15:20:42 -0400 To: fitsbits at fits.cv.nrao.edu Date: Fri, 23 Apr 1999 14:58:26 -0400 From: Peter Teuben Message-ID: <3720C2D2.4744147D at astro.umd.edu> Organization: Astronomy Department - University of Maryland Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!nuq-peer.news.verio.net!iad-artgen.news.verio.net!iad-read.news.verio.net.POSTED!not-for-mail References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Having been on the original NOST-1 panel, and working with FITS Random Format files almost on a daily basis I've of course also been weary about what "deprecate" really means. You can even find a definition in the current NOST manual. We (the panel) meant to tell the community that new data should not be using this format, since "better" ones are available (binary tables). However, existing ones should indeed fall under the "once fits, always fits" chapter. In an older version we defined it as: "To express earnest disapproval of. This term is used to refer to obsolete structures that ought not to be used but remain valid." However, there has been some discussion that the word "ought" in that definition may be too strong. I remind you that we deprecated 3 FITS features: - random groups - the BLOCKED keyword - the EPOCH keyword but again, it remains true that old data will not be deprecated, one will be able to read it. It's meant to refer to new data, but does not disallow it, but may be frowned upon. Bill Cotton wrote: > I note with dismay that this version of the NASA FITS standard > still tries to deprecate the FITS random groups format. This format > is in widespread use in the radio interferometry community. The > attempt to deprecate this format is in violation of the fundamental > principle of FITS, "once FITS, always FITS". Clintonian weasel words > on the subject are not helpful. I am forced to question the > responsiveness of the NASA committee to the non-NASA FITS community. > > -Bill Cotton peter From owner-fitsbits at kochab.cv.nrao.edu Mon Apr 26 10:36:01 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA18750 for fitsbits-spinner; Mon, 26 Apr 1999 10:35:32 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA18745 for ; Mon, 26 Apr 1999 10:35:29 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA32408 for fitsbits at majordomo.cv.nrao.edu; Mon, 26 Apr 1999 10:35:28 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA18610 for ; Mon, 26 Apr 1999 09:28:04 -0400 (EDT) Received: from gorilla.cv.nrao.edu (gorilla.cv.nrao.edu [192.33.115.9]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id JAA32264 for ; Mon, 26 Apr 1999 09:27:49 -0400 Received: (from bcotton at localhost) by gorilla.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA28468; Mon, 26 Apr 1999 09:27:48 -0400 (EDT) Date: Mon, 26 Apr 1999 09:27:48 -0400 (EDT) From: Bill Cotton Message-Id: <199904261327.JAA28468 at gorilla.cv.nrao.edu> To: fitsbits at fits.cv.nrao.edu CC: bcotton at gorilla.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits In-Reply-To: <3720C2D2.4744147D at astro.umd.edu> References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Peter Teuben writes: > Having been on the original NOST-1 panel, and working with > FITS Random Format files almost on a daily basis I've of course > also been weary about what "deprecate" really means. You can > even find a definition in the current NOST manual. > > We (the panel) meant to tell the community that new data should > not be using this format, since "better" ones are available > (binary tables). However, existing ones should indeed fall under > the "once fits, always fits" chapter. > > > In an older version we defined it as: > > "To express earnest disapproval of. This term is used to refer to obsolete > structures that ought not to be used but remain valid." > > However, there has been some discussion that the word "ought" in > that definition may be too strong. > > > I remind you that we deprecated 3 FITS features: > > - random groups > - the BLOCKED keyword > - the EPOCH keyword > > but again, it remains true that old data will not be deprecated, > one will be able to read it. It's meant to refer to new data, but > does not disallow it, but may be frowned upon. > > > Bill Cotton wrote: > > > I note with dismay that this version of the NASA FITS standard > > still tries to deprecate the FITS random groups format. This format > > is in widespread use in the radio interferometry community. The > > attempt to deprecate this format is in violation of the fundamental > > principle of FITS, "once FITS, always FITS". Clintonian weasel words > > on the subject are not helpful. I am forced to question the > > responsiveness of the NASA committee to the non-NASA FITS community. > > > > -Bill Cotton > > > peter > This is yet a further redefinition of "deprecated". My understanding was that the weasel words were intended to apply to new applications (projects), not new data. Many new random groups FITS files are generated daily and will for the foreseeable future. The BLOCKED keyword is largely irrelevant and EPOCH was a mistake, at least in its intended usage. Deprecation of random groups is a denial of present reality. -Bill Cotton From owner-fitsbits at kochab.cv.nrao.edu Mon Apr 26 10:37:23 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA18767 for fitsbits-spinner; Mon, 26 Apr 1999 10:37:21 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA18762 for ; Mon, 26 Apr 1999 10:37:18 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA32424 for fitsbits at majordomo.cv.nrao.edu; Mon, 26 Apr 1999 10:37:17 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA18731 for ; Mon, 26 Apr 1999 10:30:12 -0400 (EDT) Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id KAA32381 for ; Mon, 26 Apr 1999 10:30:11 -0400 Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA26240; Mon, 26 Apr 1999 10:30:09 -0400 (EDT) Date: Mon, 26 Apr 1999 10:30:09 -0400 (EDT) Message-Id: <199904261430.KAA26240 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Teuben Cc: fitsbits at fits.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits In-Reply-To: <3720C2D2.4744147D at astro.umd.edu> References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Peter Teuben writes: > Having been on the original NOST-1 panel, and working with > FITS Random Format files almost on a daily basis I've of course > also been weary about what "deprecate" really means. You can > even find a definition in the current NOST manual. > > We (the panel) meant to tell the community that new data should > not be using this format, since "better" ones are available > (binary tables). However, existing ones should indeed fall under > the "once fits, always fits" chapter. > > > In an older version we defined it as: > > "To express earnest disapproval of. This term is used to refer to obsolete > structures that ought not to be used but remain valid." > > However, there has been some discussion that the word "ought" in > that definition may be too strong. > > > I remind you that we deprecated 3 FITS features: > > - random groups > - the BLOCKED keyword > - the EPOCH keyword > > but again, it remains true that old data will not be deprecated, > one will be able to read it. It's meant to refer to new data, but > does not disallow it, but may be frowned upon. > > > Bill Cotton wrote: > > > I note with dismay that this version of the NASA FITS standard > > still tries to deprecate the FITS random groups format. This format > > is in widespread use in the radio interferometry community. The > > attempt to deprecate this format is in violation of the fundamental > > principle of FITS, "once FITS, always FITS". Clintonian weasel words > > on the subject are not helpful. I am forced to question the > > responsiveness of the NASA committee to the non-NASA FITS community. > > > > -Bill Cotton > > The real problem is the word "deprecate" itself. That word has been given a meaning by the ANSI which has been used then with Fortran and other languages (at least). The word means that the deprecated feature will be no longer supported at some future date. I suspect that we cannot use an arbitrary definition of the word which we make up and spell out. The word has a meaning to the standards business and we do not mean that meaning. I think we should find a new word. The problem is that I do not know what that word is. Does anyone anywhere have a suggestion? Thanks, Eric W Greisen From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 27 08:17:27 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA04755 for fitsbits-spinner; Tue, 27 Apr 1999 08:16:28 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA04750 for ; Tue, 27 Apr 1999 08:16:25 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id IAA02296 for fitsbits at majordomo.cv.nrao.edu; Tue, 27 Apr 1999 08:16:25 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id WAA22923 for ; Mon, 26 Apr 1999 22:49:11 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id WAA01058 for ; Mon, 26 Apr 1999 22:49:10 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id WAA00985; Mon, 26 Apr 1999 22:49:10 -0400 To: fitsbits at fits.cv.nrao.edu Date: Mon, 26 Apr 1999 18:27:10 +0200 From: Lucio Chiappetti Message-ID: Organization: Consiglio Nazionale delle Ricerche Path: newsfeed.cv.nrao.edu!chaos.aoc.nrao.edu!newshost.nmt.edu!logbridge.uoregon.edu!isdnet!news-ge.switch.ch!serra.unipi.it!newsserver.cilea.it!leonardo.area.mi.cnr.it!poseidon.ifctr.mi.cnr.it!lucio References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> <199904261430.KAA26240 at primate.cv.nrao.edu> Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk On Mon, 26 Apr 1999, Eric Greisen wrote: > > "To express earnest disapproval of. This term is used to refer to obsolete > > structures that ought not to be used but remain valid." > > > The real problem is the word "deprecate" itself. That word has > been given a meaning by the ANSI which has been used then [...] > and we do not mean that meaning. I think we should find a new word. > The problem is that I do not know what that word is. Does anyone > anywhere have a suggestion? What about "discouraged" ? ---------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy) ---------------------------------------------------------------------------- L'Italia ripudia la guerra [...] come Italy repudiates war {...] as a mezzo di risoluzione delle controversie way of resolution of international internazionali controversies [Art. 11 Constitution of the Italian Republic] ---------------------------------------------------------------------------- For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html ---------------------------------------------------------------------------- From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 27 08:19:21 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA04774 for fitsbits-spinner; Tue, 27 Apr 1999 08:19:19 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA04769 for ; Tue, 27 Apr 1999 08:19:15 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id IAA02314 for fitsbits at majordomo.cv.nrao.edu; Tue, 27 Apr 1999 08:19:15 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id FAA01517 for ; Tue, 27 Apr 1999 05:46:36 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id FAA02056 for ; Tue, 27 Apr 1999 05:46:35 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id FAA07776; Tue, 27 Apr 1999 05:46:34 -0400 To: fitsbits at fits.cv.nrao.edu Date: Tue, 27 Apr 1999 10:44:26 +0100 From: Peter Bunclark Message-ID: <372586FA.EA3D9FAC at ast.cam.ac.uk> Organization: Institute of Astronomy Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!newsfeed.mathworks.com!newsfeed.cwix.com!146.80.9.55!diablo.dera.gov.uk!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> <199904261430.KAA26240 at primate.cv.nrao.edu> Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk > UNFITTED. > > The real problem is the word "deprecate" itself. That word has > been given a meaning by the ANSI which has been used then with Fortran > and other languages (at least). The word means that the deprecated > feature will be no longer supported at some future date. I suspect > that we cannot use an arbitrary definition of the word which we make > up and spell out. The word has a meaning to the standards business > and we do not mean that meaning. I think we should find a new word. > The problem is that I do not know what that word is. Does anyone > anywhere have a suggestion? > > Thanks, > Eric W Greisen From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 27 10:14:03 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA04922 for fitsbits-spinner; Tue, 27 Apr 1999 10:14:01 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA04917 for ; Tue, 27 Apr 1999 10:13:57 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id KAA02539 for fitsbits at majordomo.cv.nrao.edu; Tue, 27 Apr 1999 10:13:57 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA04906 for ; Tue, 27 Apr 1999 09:56:28 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id JAA02504 for ; Tue, 27 Apr 1999 09:56:27 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id JAA26820 for ; Tue, 27 Apr 1999 09:56:26 -0400 Received: from star.rl.ac.uk(130.246.36.1) by palantir.cv.nrao.edu via smap (V1.3) id sma026752; Tue Apr 27 09:56:20 1999 Received: from rlsaxps.bnsc.rl.ac.uk (ptw at rlsaxps.bnsc.rl.ac.uk [130.246.32.128]) by star.rl.ac.uk (8.9.1/8.9.1) with ESMTP id OAA28718; Tue, 27 Apr 1999 14:52:23 +0100 (BST) Received: from localhost (ptw at localhost) by rlsaxps.bnsc.rl.ac.uk (8.9.1/8.9.1) with SMTP id OAA19417; Tue, 27 Apr 1999 14:52:10 +0100 (BST) X-Authentication-Warning: rlsaxps.bnsc.rl.ac.uk: ptw owned process doing -bs Date: Tue, 27 Apr 1999 14:52:10 +0100 (BST) From: Patrick Wallace X-Sender: ptw at rlsaxps.bnsc.rl.ac.uk To: Lucio Chiappetti cc: fitsbits at fits.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk > > The real problem is the word "deprecate" itself. That word has > > been given a meaning by the ANSI which has been used then [...] > > and we do not mean that meaning. I think we should find a new word. I think "deprecate" is just fine. It's an English word, not owned by ANSI the last time I consulted the OED, and we can have it mean whatever shade of disapproval we choose. What I assume all we mean is that we are recommending to implementors of new FITS-writing programs that they avoid using the feature. The reasons for deprecation are really a separate matter, but we should list a few examples to encourage compliance. (For example don't use feature A when feature B works much better.) If someone in a few years decides to write a program that reads FITS files, and decides not to bother supporting one or more deprecated features, then to my mind that's acceptable as long as they own up. The program they've written is a reader of a subset of valid FITS files; as long as they don't try and pass it off as a completely universal FITS reader we surely have no grounds for complaint. Patrick Wallace ____________________________________________________________________________ Starlink Project Manager Internet: ptw at star.rl.ac.uk Rutherford Appleton Laboratory Tel: +44-1235-445372 Chilton, Didcot, Oxon OX11 0QX, UK Fax: +44-1235-446667 ____________________________________________________________________________ From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 27 11:58:25 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA05394 for fitsbits-spinner; Tue, 27 Apr 1999 11:58:17 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA05389 for ; Tue, 27 Apr 1999 11:58:14 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id LAA02866 for fitsbits at majordomo.cv.nrao.edu; Tue, 27 Apr 1999 11:58:14 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA05120 for ; Tue, 27 Apr 1999 11:22:18 -0400 (EDT) Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id LAA02647 for ; Tue, 27 Apr 1999 11:22:17 -0400 Received: (from news at localhost) by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id LAA10938; Tue, 27 Apr 1999 11:22:17 -0400 To: fitsbits at fits.cv.nrao.edu Date: Tue, 27 Apr 1999 09:15:49 -0400 From: Doug Mink Message-ID: <3725B885.A01939EB at cfa.harvard.edu> Organization: Harvard University Path: newsfeed.cv.nrao.edu!chaos.aoc.nrao.edu!lynx.unm.edu!newshub.tc.umn.edu!news.eecs.umich.edu!news-feed.inet.tele.dk!bofh.vszbr.cz!news.maxwell.syr.edu!newshub.northeast.verio.net!iad-peer.news.verio.net!news.harvard.edu!cfanews.harvard.edu!131.142.24.153 References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> <199904261430.KAA26240 at primate.cv.nrao.edu> Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric Greisen wrote: > The real problem is the word "deprecate" itself. That word > has been given a meaning by the ANSI which has been used then > with Fortran and other languages (at least). The word means > that the deprecated feature will be no longer supported at > som> future date. I suspect that we cannot use an arbitrary > definition of the word which we make up and spell out. The > word has a meaning to the standards business and we do not > mean that meaning. I think we should find a new word. The > problem is that I do not know what that word is. Does anyone > anywhere have a suggestion? I second Lucio's "use is discouraged". As an archival standard, FITS *has* to continue to support every past legal format and keyword. The standard can also note that use of binary tables format instead of random groups is encouraged for new projects. -Doug Mink From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 27 14:12:06 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id OAA05844 for fitsbits-spinner; Tue, 27 Apr 1999 14:11:41 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA05839 for ; Tue, 27 Apr 1999 14:11:37 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id OAA03101 for fitsbits at majordomo.cv.nrao.edu; Tue, 27 Apr 1999 14:11:37 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA05683 for ; Tue, 27 Apr 1999 13:55:25 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id NAA03061 for ; Tue, 27 Apr 1999 13:55:24 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id NAA17560 for ; Tue, 27 Apr 1999 13:55:23 -0400 Received: from malama.jach.hawaii.edu(128.171.90.203) by palantir.cv.nrao.edu via smap (V1.3) id sma017514; Tue Apr 27 13:55:17 1999 Received: from lilikoi [128.171.90.227] by malama with smtp (Exim 1.81 #3) id 10cBxo-0003OG-00; Tue, 27 Apr 1999 07:48:08 -1000 Message-ID: <3725F857.77E2 at jach.hawaii.edu> Date: Tue, 27 Apr 1999 07:48:07 -1000 From: Maren Purves Organization: Joint Astronomy Centre, Hilo, HI X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.6 sun4m) MIME-Version: 1.0 To: Patrick Wallace CC: Lucio Chiappetti , fitsbits at fits.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Patrick Wallace wrote: > > > > The real problem is the word "deprecate" itself. That word has > > > been given a meaning by the ANSI which has been used then [...] > > > and we do not mean that meaning. I think we should find a new word. > > I think "deprecate" is just fine. It's an English word, not owned by > ANSI the last time I consulted the OED, and we can have it mean whatever > shade of disapproval we choose. I like Lucio Chiapetti's suggestion, "discouraged". For one, hate to admit it, it is a word I understand :-) Maren Purves, UKIRT From owner-fitsbits at kochab.cv.nrao.edu Tue Apr 27 15:50:35 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id PAA06899 for fitsbits-spinner; Tue, 27 Apr 1999 15:50:22 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA06894 for ; Tue, 27 Apr 1999 15:50:19 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id PAA03258 for fitsbits at majordomo.cv.nrao.edu; Tue, 27 Apr 1999 15:50:19 -0400 Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA06884 for ; Tue, 27 Apr 1999 15:49:59 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id PAA03239; Tue, 27 Apr 1999 15:49:58 -0400 Date: Tue, 27 Apr 1999 15:49:58 -0400 Message-Id: <199904271949.PAA03239 at fits.cv.nrao.edu> From: Don Wells MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fitsbits at fits.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released Newsgroups: sci.astro.fits In-Reply-To: <199904261430.KAA26240 at primate.cv.nrao.edu> References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> <199904261430.KAA26240 at primate.cv.nrao.edu> X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Eric Greisen writes: > The real problem is the word "deprecate" itself. That word has > been given a meaning by the ANSI which has been used then with Fortran > and other languages (at least). The word means that the deprecated > feature will be no longer supported at some future date.. The Fortran-90 committee *may* have used the word with that meaning (but see below for evidence that they used a different word). However, after searching the Web, I can find no reason to conclude that the definition given in the quote above has been formally adopted by ANSI itself. Indeed, the available evidence (inconsistent usage of the word by standards-committee-related personnel) suggests the contrary. -=-=-=- A good summary of the Fortran-90 situation is at this URL: http://www.nsc.liu.se/~boein/f77to90/a4.html#obsolescent "..the concept 'obsolescence' is introduced. This means that some constructs may be removed at the next change of Fortran.." It clear that the Fortran-90 committee was serious; for example, see the deleted features discussion for Fortran-95 at: http://www.nsc.liu.se/~boein/f77to90/f95.html#17.2 "..Five features are deleted from Fortran 90. 1.real and double precision DO loop index variables 2.branching to END IF from an outer block 3.PAUSE statements 4.ASSIGN statements and assigned GO TO statements and the use of an assigned integer as a FORMAT specification 5.Hollerith editing in FORMAT. These are all from the list of obsolescent features of Fortran 90 (but not the complete list).." Please note that 'deprecate' per se does not appear in the above texts; 'obsolescent' is used instead. I do not have access to the official Fortran-90 standard, so I cannot check whether 'deprecate' was used in it. If 'obsolescent' was used, then Fortran cannot be cited in our discussions about use of the word 'deprecate' in the NOST FITS standard. -=-=-=- I decided to try a Web search engine with the string "deprecate AND ansi". My goal was to find examples of usage of 'deprecate' in computer-standards discussions; I hoped that the precise meaning of the word would be clear in context. For example, the page at URL http://www.uni-giessen.de/hrz/programmiersprachen/C/b.html contains an extended discussion of the ANSI C standard. The word 'deprecate' appears once in the text, in this paragraph: "..The distinction between internal and external codes most needs emphasis with respect to new-line. ANSI X3L2 (Codes and Character Sets) uses the term to refer to an external code used for information interchange whose display semantics specify a move to the next line. Both ANSI X3L2 and ISO 646 deprecate the combination of the motion to the next line with a motion to the initial position on the line. The C Standard, on the other hand, uses new-line to designate the end-of-line internal code represented by the escape sequence '\n'. While this ambiguity is perhaps unfortunate, use of the term in the latter sense is nearly universal within the C community. But the knowledge that this internal code has numerous external representations, depending upon operating system and medium, is equally widespread.." This usage of 'deprecate' in an ANSI computer language standard context definitely falls into the "to express disapproval of" category, not in the "to be deleted in a future version of the standard" category. I also found several uses of 'deprecate' in discussions of C++: http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/sect4/index.html "..[Stroustrup 94] also voices the opinion that default int is bad. He had tried to make the type specifier explicit, but was forced to withdraw by users: 'I backed out the change. I don't think I had a choice. Allowing that implicit int is the source of many of the annoying problems with C++ grammar today. Note the pressure came from users, not management or arm-chair language experts. Finally, ten years later, the C++ ANSI/ISO standard committee has decided to deprecate implicit int.'.." http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/sect3/index.html "..[Stroustrup 94] indicates a desire to discard the C casts: 'I intended the new-style casts as a complete replacement for the (T)e notation. I proposed to deprecate (T)e ; that is, for the committee to give users warning that the (T)e notation would most likely not be part of a future revision of the C++ standard. ... However, that idea didn't gain a majority, so that cleanup of C++ will probably never happen.'.." So, in a discussion of the ANSI C standard the word is used with the 'discourage' meaning, while in at least one discussion of ANSI C++ 'deprecate' is defined as 'to be deleted in the future'. Another case I found is a review of ANSI X3J13 Common Lisp standards debates at: http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/html/hyperspec/HyperSpec/Issues/iss149-writeup.html "..David Moon says: Seems okay, except that if we are going to deprecate these things, I would much rather just remove them. You would surely argue that no significant program could possibly be depending on EVALHOOK, since it has no semantics, so there can't be a compatibility issue. If we agree that something is a bad idea, I would rather remove it entirely unless there is a compelling compatibility reason to only deprecate it. In fact even if some programs used EVALHOOK, I would still want to remove it, as I long ago ceased to believe in any fantasy of seamless compatibility between CLtL and ANSI CL. But others might not agree with me there.." Obviously the usage above implies disapproval, not deletion. But consider another example which is discussing the same X3J13 debates: http://www2.camellia.org/cltl-html/clm/node141.html "..X3J13 voted in January 1989 (TEST-NOT-IF-NOT) to deprecate the use of :test-not keyword arguments and -if-not functions. This means that these features are very likely to be retained in the forthcoming standard but are regarded as candidates for removal in a future revision of the ANSI standard. X3J13 also voted in January 1989 (FUNCTION-COMPOSITION) to add the complement function, intended to reduce or eliminate the need for these deprecated features. Time will tell. I note that many features in Fortran have been deprecated but very few indeed have actually been removed or altered incompatibly.." So, in one discussion of ANSI Lisp 'deprecate' is used as 'discourage' while in another discussion it is defined as 'candidate for removal'. COBOL is an ANSI language; here is a usage in the 'Frequently Asked Questions about COBOL' document at: http://obelix.unicamp.br/pub/FAQ/computer-lang/cobol-faq "..16. Contributors to the FAQ. Many people have contributed to this FAQ in each of its iterations. In the past an ongoing list of these people have been included within the FAQ. At this time, i am stopping this practice, although I ,in no way, want to deprecate all the work and input that these people have provided. I have continued to identify people whom I am quoting (directly or indirectly) and do still hope that everyone who has input for this document will continue to provide it.." The implied meaning in the above case is roughly "discourage". I am unsure whether Java is already in the ANSI standards process, but I expect it will be eventually. In the book "Java [1.1] AWT Reference" (J.Zukowski, O'Reilly, 1997), on p.xvii, we find: "..Comments in the JDK source code indicate that the older method names have been 'deprecated', which means that you should consider the old names obsolete and avoid using them; they could disappear in a future release.." -=-=-=- In addition to computer languages, we could broaden the scope to include discussions of networking standards. Consider RFC2130, at: http://info.internet.isi.edu/in-notes/rfc/files/rfc2130.txt "..This report recommends the use of ISO 10646 as the default Coded Character Set, and UTF-8 as the default Character Encoding Scheme in the creation of new protocols or new version of old protocols which transmit text. These defaults do not deprecate the use of other character sets when and where they are needed; they are simply intended to provide guidance and a specification for interoperability.." and the commentary document at: http://www.imib.med.tu-dresden.de/imib/Internet/Literatur/IPSec/draft-rogaway-ipsec-comments-00.txt "..As a general principle, since ALL that an ESP mechanism ought guarantee is privacy, it is NEVER useful to encrypt known text. Doing so increases the size of packets and the computational complexity of making them, while it provides no security benefit. RECOMMENDATION 3: Modify the architecture to forbid or deprecate the encryption of known headers.." Both of the above usages imply "discourage". I also found a usage in documentation for the netCDF package at: http://dos-debian.kosnet.ru/doc/netcdf/CHANGES "..added the `-p fdigs,ddigs' option to ncdump. This replaces and behaves like the (now deprecated and undocumented) `-d' option, except that it overrides any values specified by the `C_format' attribute for float or double values. Made precisions specified by the `-p' or (now deprecated) `-d' options apply to float or double attributes as well as data values.." Here it is clear that the deprecated feature remains supported but will no longer be documented. -=-=-=- Finally, we can consult the Jargon File's 4.0.0 version (released 25 July 1996, published in cellulose fiber and carbon particles as 'The New Hacker's Dictionary') at: http://www.fh-zwickau.de/~linux/info/jargon/jargon_19.html#SEC26 deprecated /adj./ Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favor of a specified replacement. Deprecated features can, unfortunately, linger on for many years. This term appears with distressing frequency in standards documents when the committees writing the documents realize that large amounts of extant (and presumably happily working) code depend on the feature(s) that have passed out of favor. Lest you think the above definition is definitive, compare this usage from the same URL: dd /dee-dee/ /vt./ [Unix: from IBM JCL] Equivalent to cat or BLT. Originally the name of a Unix copy command with special options suitable for block-oriented devices; it was often used in heavy-handed system maintenance, as in "Let's dd the root partition onto a tape, then use the boot PROM to load it back on to a new disk". The Unix dd(1) was designed with a weird, distinctly non-Unixy keyword option syntax reminiscent of IBM System/360 JCL (which had an elaborate DD `Dataset Definition' specification for I/O devices); though the command filled a need, the interface design was clearly a prank. The jargon usage is now very rare outside Unix sites and now nearly obsolete even there, as dd(1) has been deprecated for a long time (though it has no exact replacement). The term has been displaced by BLT or simple English `copy'. -Don -- Donald C. Wells Scientist - GBT Project dwells at nrao.edu http://www.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From owner-fitsbits at kochab.cv.nrao.edu Wed Apr 28 15:42:48 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id PAA22069 for fitsbits-spinner; Wed, 28 Apr 1999 15:41:26 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA22064 for ; Wed, 28 Apr 1999 15:41:23 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id PAA05780 for fitsbits at majordomo.cv.nrao.edu; Wed, 28 Apr 1999 15:41:22 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA07646 for ; Tue, 27 Apr 1999 21:47:44 -0400 (EDT) Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id VAA03882 for ; Tue, 27 Apr 1999 21:47:43 -0400 Received: (from tismail at localhost) by palantir.cv.nrao.edu (8.8.5/8.8.5) id VAA00795 for ; Tue, 27 Apr 1999 21:47:42 -0400 Received: from crux.tip.csiro.au(130.155.194.32) by palantir.cv.nrao.edu via smap (V1.3) id sma000792; Tue Apr 27 21:47:31 1999 Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.tip.CSIRO.AU (8.9.0.Beta5/8.9.0.Beta5/TIPAT-1.1a) with ESMTP id LAA12333 for ; Wed, 28 Apr 1999 11:44:31 +1000 (EST) Received: from grus.atnf.CSIRO.AU (localhost [127.0.0.1]) by grus.atnf.CSIRO.AU (8.7.5/8.7.3) with ESMTP id LAA00499 for ; Wed, 28 Apr 1999 11:44:29 +1000 (EST) Message-Id: <199904280144.LAA00499 at grus.atnf.CSIRO.AU> To: fitsbits at fits.cv.nrao.edu Subject: WCS Paper II, revision Date: Wed, 28 Apr 1999 11:44:29 +1000 From: Mark Calabretta Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Thank you to those who responded to the call for comments on WCS Paper II, "Representations of celestial coordinates in FITS". A revised draft based on this feedback and dated 1999/04/28 is now available from my home page http://www.atnf.csiro.au/people/mcalabre or from Eric's ftp area (soon, check the date) ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen. The changes could probably best be described as fine tuning. "diff -C 1" output on the LaTeX file is appended (insignificant typesetting changes have been removed from this output). Changes were also made to correct keyword nomenclature in Fig. 1 and to correctly identify the angle theta in Fig. 4. There is still time to make further comments, particularly on Sect. 4.1.5, Eqs. (40) & (41). Mark Calabretta ATNF ------------------------------------------------------------------------------ *** ccs.tex 1999/04/20 04:19:14 1.13 --- ccs.tex 1999/04/28 00:04:00 *************** *** 576,578 **** the time of observation. The new keyword takes preference over the old one if ! both are given. Note that \EQUINOX{s} also applies to ecliptic as well as equatorial coordinates. --- 576,578 ---- the time of observation. The new keyword takes preference over the old one if ! both are given. Note that \EQUINOX{s} applies to ecliptic as well as to equatorial coordinates. *************** *** 834,839 **** (ca.\,624-547\,{\sc b.c.}). The stereographic and orthographic date to ! Hipparchus (ca.\,190-after 126\,{\sc b.c.}).}, is widely used in optical astronomy and was given its own code within the AIPS convention, namely ! \keyv{TAN}. However, the \keyv{TAN} projection is here extended to include ! corrections for instrumental distortions and is covered separately in Sect.~\ref{sec:TAN}. If a simple gnomonic projection is required it can be --- 834,841 ---- (ca.\,624-547\,{\sc b.c.}). The stereographic and orthographic date to ! Hipparchus (ca.\,190-after 126\,{\sc b.c.}).} is widely used in optical astronomy and was given its own code within the AIPS convention, namely ! \keyv{TAN}\footnote{Referring to the dependence of $\Rt$ on the angular ! separation between the tangent point and field point, i.e. the native ! {\em co}-latitude.}. However, the \keyv{TAN} projection is here extended to ! include corrections for instrumental distortions and is covered separately in Sect.~\ref{sec:TAN}. If a simple gnomonic projection is required it can be *************** *** 899,903 **** widely used in aperture synthesis radioastronomy and was given its own code ! within the AIPS convention, namely \keyv{SIN}. Use of this projection code ! obviates the need to specify an infinite value as a parameter of \keyv{AZP}. ! In this case, Eq.~(\ref{eq:AZPRt}) becomes --- 901,906 ---- widely used in aperture synthesis radioastronomy and was given its own code ! within the AIPS convention, namely \keyv{SIN}\footnote{Similar etymology to ! \keyv{TAN}.}. Use of this projection code obviates the need to specify an ! infinite value as a parameter of \keyv{AZP}. In this case, ! Eq.~(\ref{eq:AZPRt}) becomes *************** *** 1086,1108 **** high-precision with a measuring engine. These plate coordinates are usually ! measured in $\mu$m rather than degrees. ! Astrometrists refer to the $(\xi,\eta)$ coordinates obtained by application of ! the distortion function as {\em standard} coordinates. They correspond to ! projection plane coordinates for a non-distorted projection, usually gnomonic ! or zenithal equidistant. We will confine ourselves here to the gnomonic case ! since the field sizes of interest are sufficiently small, typically less than ! $6\degr \times 6\degr$, that the distortion function itself can account for ! the difference between it and other projections. ! ! In the current treatment we require that $(\xi,\eta)$ be measured in degrees. ! However, in order to more easily accomodate traditional astrometric practices ! and facilitate translation of existing plate measurements, we recommend but do ! not require that $(x,y)$ be measured in degrees. This is possible because the ! linear terms of the distortion function provide an opportunity to rescale ! $(\xi,\eta)$ appropriately. The distortion function effectively becomes an ! attachment of the the linear transformation matrix rather than part of the ! projection itself. Ideally the linear terms of the distortion function should ! define an identity transformation with translation, rotation, skewness and ! scale handled solely by Eq.~(\ref{eq:ijCDxy}). In that case the distortion ! function becomes a second-order correction. --- 1089,1106 ---- high-precision with a measuring engine. These plate coordinates are usually ! measured in $\mu$m or mm rather than degrees. ! The {\em standard} coordinates, $(\xi,\eta)$, correspond to projection plane ! coordinates for a gnomonic projection (Murray \cite{kn:Mu}). Standard ! coordinates are usually measured in radians but in the current treatment we ! require that $(\xi,\eta)$ be measured in degrees. However, in order to more ! easily accomodate traditional astrometric practices and facilitate translation ! of existing plate measurements, we recommend but do not require that $(x,y)$ ! be measured in degrees. This is possible because the linear terms of the ! distortion function provide an opportunity to rescale $(\xi,\eta)$ ! appropriately. The distortion function effectively becomes an attachment of ! the the linear transformation matrix rather than part of the projection ! itself. Ideally the linear terms of the distortion function should define an ! identity transformation with translation, rotation, skewness and scale handled ! solely by Eq.~(\ref{eq:ijCDxy}). In that case the distortion function becomes ! a second-order correction. *************** *** 1396,1403 **** ! Lambert's\footnote{Johann Heinrich Lambert (1728-1777) formulated and gave his ! name to a number of important projections as listed in ! Table~\ref{ta:aliases}.} equal area projection, the case with $\lambda = 1$, ! is illustrated in Fig.~\ref{fig:CEA}. It shows the extreme compression of the ! parallels of latitude at the poles typical of all cylindrical equal area ! projections. --- 1394,1401 ---- ! Lambert's\footnote{The mathematician, astronomer and physicist Johann Heinrich ! Lambert (1728-1777) formulated and gave his name to a number of important ! projections as listed in Table~\ref{ta:aliases}.} equal area projection, the ! case with $\lambda = 1$, is illustrated in Fig.~\ref{fig:CEA}. It shows the ! extreme compression of the parallels of latitude at the poles typical of all ! cylindrical equal area projections. *************** *** 1991,1993 **** and use the fact that for a cone tangent to the sphere at latitude $\theta_1$ ! as shown in Fig.~\ref{fig:COP} then $R_{\theta_1} = \rd\cot\theta_1$. --- 1989,1991 ---- and use the fact that for a cone tangent to the sphere at latitude $\theta_1$ ! as shown in Fig.~\ref{fig:COP} we have $R_{\theta_1} = \rd\cot\theta_1$. *************** *** 2653,2658 **** ! However, FITS-writers should never mix \CDELT{i} or \CROTA{j} together with ! the new keyword values. We make this requirement primarily to minimize ! confusion. However, there is the practical case described in ! Sect.~\ref{sec:AITGLSMER} where the presence of \CDELT{j} header cards distinguishes between the old and new interpretations of the \keyv{AIT}, --- 2651,2657 ---- ! Modern FITS-writers must not attempt to help older interpreters by mixing ! \CDELT{i} or \CROTA{j} together with the new keyword values (assuming the ! \CD{j}{is} matrix is amenable to such translation). We make this requirement ! primarily to minimize confusion although there is the practical case described ! in Sect.~\ref{sec:AITGLSMER} where the presence of \CDELT{j} header cards distinguishes between the old and new interpretations of the \keyv{AIT}, *************** *** 2833,2839 **** optical telescopes is closer to a gnomonic (\keyv{TAN}) projection. On the ! other hand, the optics of the telescope used for the Sloan Digital Sky Survey ! produce a cylindrical perspective projection. Similarly a map of the surface ! of the moon as it appears from Earth requires a zenithal perspective ! (\keyv{AZP}) projection with $\mu = -60$. Likewise for spacecraft generated ! images of distant moons and planets. --- 2832,2838 ---- optical telescopes is closer to a gnomonic (\keyv{TAN}) projection. On the ! other hand, the great circle scanning technique of the the Sloan Digital Sky ! Survey produce a cylindrical projection. Similarly a map of the surface of ! the moon as it appears from Earth requires a zenithal perspective (\keyv{AZP}) ! projection with $\mu \approx -60$. Likewise for spacecraft generated images ! of distant moons and planets. *************** *** 2915,2917 **** \keyv{STG}, \keyv{ARC}, \keyv{ZEA}, \keyv{CAR}, \keyv{MER}, \keyv{BON}, ! \keyv{PCO}, \keyv{GLS}, \keyv{AIT}. The following are scaled true at the reference point for the particular conditions indicated: \keyv{TAN} --- 2915,2917 ---- \keyv{STG}, \keyv{ARC}, \keyv{ZEA}, \keyv{CAR}, \keyv{MER}, \keyv{BON}, ! \keyv{PCO}, \keyv{SFL}, \keyv{AIT}. The following are scaled true at the reference point for the particular conditions indicated: \keyv{TAN} *************** *** 3106,3109 **** \verb+CD1_1A = -0.005 / Transformation matrix element+ \\ ! \verb+CD1_2A = 0.00001 / Transformation matrix element+ \\ ! \verb+CD2_1A = 0.00001 / Transformation matrix element+ \\ \verb+CD2_2A = 0.005 / Transformation matrix element+ \\ --- 3106,3109 ---- \verb+CD1_1A = -0.005 / Transformation matrix element+ \\ ! \verb+CD1_2A = 0.00002 / Transformation matrix element+ \\ ! \verb+CD2_1A = -0.00001 / Transformation matrix element+ \\ \verb+CD2_2A = 0.005 / Transformation matrix element+ \\ *************** *** 3358,3360 **** $\phi\sub{p}$ to give $(\ell,b)$ in terms of $(\phi,\theta)$. This is easy ! because we know $\ell\sub{p}=90\degr$ and the simple special case Eqs.~(\ref{eq:nat2std90}) apply so --- 3354,3356 ---- $\phi\sub{p}$ to give $(\ell,b)$ in terms of $(\phi,\theta)$. This is easy ! because we know $b\sub{p}=90\degr$ and the simple special case Eqs.~(\ref{eq:nat2std90}) apply so *************** *** 3404,3406 **** \noindent ! Equations~(\ref{eq:nat2stdm90}) apply for $\ell\sub{p}=-90\degr$ so --- 3400,3402 ---- \noindent ! Equations~(\ref{eq:nat2stdm90}) apply for $b\sub{p}=-90\degr$ so *************** *** 3597,3599 **** approximation since typically $B_1 \approx A_1$. On the other hand, setting ! $\lambda = 1$ preserves $(x,y)$ as plate coordinates measured in mm. --- 3593,3596 ---- approximation since typically $B_1 \approx A_1$. On the other hand, setting ! $\lambda = 1$ preserves $(x,y)$ as plate coordinates measured in mm. The ! choice will be left open here. *************** *** 3690,3693 **** & \keyw{PV1\_14} &=& a_{14} &=& 0 \, , \\ ! & \keyw{PV1\_15} &=& a_{15} &=& 0 \, , \\ ! & \keyw{PV1\_16} &=& a_{16} &=& 0 \, . \end{array} --- 3687,3689 ---- & \keyw{PV1\_14} &=& a_{14} &=& 0 \, , \\ ! & \keyw{PV1\_15} &=& a_{15} &=& 0 \, . \end{array} *************** *** 3714,3717 **** & \keyw{PV2\_14} &=& b_{14} &=& 0 \, , \\ ! & \keyw{PV2\_15} &=& b_{15} &=& 0 \, , \\ ! & \keyw{PV2\_16} &=& b_{16} &=& 0 \, . \end{array} --- 3710,3712 ---- & \keyw{PV2\_14} &=& b_{14} &=& 0 \, , \\ ! & \keyw{PV2\_15} &=& b_{15} &=& 0 \, . \end{array} *************** *** 3792,3793 **** --- 3787,3803 ---- ! Most optical telescopes are better described by the \keyv{TAN} projection. In ! this case the only difference in the header would be ! \noindent ! \begin{eqnarray*} ! \keyw{CTYPE2} & = & \keyv{'RA---TAN'} \, , \\ ! \keyw{CTYPE3} & = & \keyv{'DEC--TAN'} \, , \\ ! \end{eqnarray*} ! \noindent ! Verifying it with the same values as before yields the same $(s,x,y)$ and thus ! the same wavelength. From Eqs.~(\ref{eq:azrt}), (\ref{eq:azphi}) and ! (\ref{eq:GNORt}) we get $(\phi,\theta) = (90\degr,89\fdg4314076)$, the offset ! of 2046\farcs933 differing by only 67~mas. The right ascension and ! declination are $(\alpha,\delta) = (150\fdg3449926,-34\fdg5070956)$. *************** *** 4303,4305 **** described in this paper. One, Mollweide's, even requires solution of a ! transcentental equation for the forward equations. However, these do not give rise to any particular difficulties. --- 4314,4316 ---- described in this paper. One, Mollweide's, even requires solution of a ! transcendental equation for the forward equations. However, these do not give rise to any particular difficulties. *************** *** 4355,4357 **** Sinusoidal & \keyv{SFL} \\ ! \In Global sinusoid \\ \In Mercator equal-area \\ --- 4366,4368 ---- Sinusoidal & \keyv{SFL} \\ ! \In Global sinusoid (\keyv{GLS}) \\ \In Mercator equal-area \\ *************** *** 4500,4501 **** --- 4511,4515 ---- + \bibitem[1983]{kn:Mu} Murray, C. A., 1983, Vectorial Astrometry, + Adam Hilger Ltd., Bristol. + \bibitem[1976]{kn:OL} O'Neill, E. M., Laubscher, R. E., 1976, From owner-fitsbits at kochab.cv.nrao.edu Wed Apr 28 15:43:07 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id PAA22130 for fitsbits-spinner; Wed, 28 Apr 1999 15:43:06 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA22125 for ; Wed, 28 Apr 1999 15:43:03 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id PAA05792 for fitsbits at majordomo.cv.nrao.edu; Wed, 28 Apr 1999 15:43:02 -0400 Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA21280 for ; Wed, 28 Apr 1999 09:23:53 -0400 (EDT) Received: from gorilla.cv.nrao.edu (gorilla.cv.nrao.edu [192.33.115.9]) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) with ESMTP id JAA05102 for ; Wed, 28 Apr 1999 09:23:52 -0400 Received: (from bcotton at localhost) by gorilla.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA02772; Wed, 28 Apr 1999 09:23:49 -0400 (EDT) Date: Wed, 28 Apr 1999 09:23:49 -0400 (EDT) From: Bill Cotton Message-Id: <199904281323.JAA02772 at gorilla.cv.nrao.edu> To: Steve Allen CC: bcotton at gorilla.cv.nrao.edu, fitsbits at fits.cv.nrao.edu Subject: Re: Version 100-2.0 of NASA FITS Standard released In-Reply-To: <19990427140700.A16692 at ucolick.org> References: <199904121755.NAA02326 at iris.stsci.edu> <199904210025.UAA22980 at gorilla.cv.nrao.edu> <3720C2D2.4744147D at astro.umd.edu> <199904261327.JAA28468 at gorilla.cv.nrao.edu> <19990427140700.A16692 at ucolick.org> Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk Steve Allen writes: > On Mon 1999-04-26T10:36:23 -0400, Bill Cotton hath writ: > > This is yet a further redefinition of "deprecated". My > > understanding was that the weasel words were intended to apply to new > > applications (projects), not new data. Many new random groups FITS > > files are generated daily and will for the foreseeable future. > > The BLOCKED keyword is largely irrelevant and EPOCH was a mistake, at > > least in its intended usage. Deprecation of random groups is a > > denial of present reality. > > Dr. Cotton, > > The discussion could be more focussed it you would make it clear > whether you object to the word or the concept of deprecation. > > For example, I think it would help to know whether you would object to > a longwinded "Prithee do not employ this for any purpose which does > not already use it". > I object only to the term "deprecate" which I interprete as meaning "likely to be disallowed". I am certainly no fan of random groups and was part of an effort to get it replaced in the radio community by a tables-based scheme. Unfortunately, this effort largely failed. The radio community isn't in a position to make this sort of change for the foreseeable future as most working software is on minimal (or less) life support. On the other hand, discouraging use of random groups in new applications is entirely appropriate; I would have no problem with your wording or something of this nature. A common current practice is for radio telescopes to produce raw data in binary tables format but processed interferometer data is almost always archived and interchanged between packages in random groups format. I object to even potentially disallowing a working format while it's still being actively used. The question is how to express disaproval of the usage of random groups in future applications, if that is indeed the intent. Don Wells' tome on "deprecate" illustrates the ambiguity of the term in common usage. A simple phrase like "use discouraged in future applications" (or even the suggestion above) uses only words whose meaning is relatively unambiguous. -Bill Cotton From owner-fitsbits at kochab.cv.nrao.edu Wed Apr 28 19:51:29 1999 Received: (from majordom at localhost) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id TAA16399 for fitsbits-spinner; Wed, 28 Apr 1999 19:50:58 -0400 (EDT) Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id TAA16394 for ; Wed, 28 Apr 1999 19:50:55 -0400 (EDT) Received: (from dwells at localhost) by fits.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id TAA06286 for fitsbits at majordomo.cv.nrao.edu; Wed, 28 Apr 1999 19:50:54 -0400 Received: from primate.cv.nrao.edu (primate.cv.nrao.edu [192.33.115.67]) by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA23005 for ; Wed, 28 Apr 1999 16:01:06 -0400 (EDT) Received: (from egreisen at localhost) by primate.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id QAA01171; Wed, 28 Apr 1999 16:01:05 -0400 (EDT) Date: Wed, 28 Apr 1999 16:01:05 -0400 (EDT) Message-Id: <199904282001.QAA01171 at primate.cv.nrao.edu> From: Eric Greisen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fitsbits at primate.cv.nrao.edu Subject: updated wcs papers X-Mailer: VM 6.35 under Emacs 20.2.1 Sender: owner-fitsbits at kochab.cv.nrao.edu Precedence: bulk All three papers on wcs have been updated today at my site ftp://ftp.cv.nrao.edu/NRAO-staff/egreisen The ccs.ps reflects Mark's recent changes. wcs.ps was changed to fix the nomenclature in Figure 1. Typos in scs.ps were fixed, the reminder of which symbol is CRVALk was placed everywhere, a comment on the changes since Wells, Greisen, Harten was added, units for RESTFREWQ and RESTWAVE were restricted so that we don't have to have a units keyword for them, wording in Section 4 was expanded and clarified, OBS-LONG really means observation not observatory (et al), a comment disassociating the OBS- keywords from real geodesy was added, and there will probably be a bit more in the next few minutes. Please read these. Votes will be taken sometime soon - at ADASS if not sooner! Many thanks to Steve Allen and Pat Wallace for all their comments. Eric Greisen