From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 2 16:38:00 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA13026; Mon, 2 Sep 1996 16:38:00 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id HAA05440; Sun, 1 Sep 1996 07:11:01 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id HAA00123 for ; Sun, 1 Sep 1996 07:10:04 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA27056; Sun, 1 Sep 96 07:10:00 EDT To: fitsbits at fits.cv.nrao.edu Date: 31 Aug 1996 00:03:42 GMT From: sla at umbra.ucolick.org (Steve Allen) Message-Id: <507vgu$dn8 at darkstar.ucsc.edu> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in3.uu.net!news.mathworks.com!newsfeed.internetmci.com!howland.erols.net!agate!news.ucsc.edu!umbra.ucolick.org!sla References: <199608301312.JAA06260 at tetra.gsfc.nasa.gov> <5079np$ae7 at darkstar.ucsc.edu> <30AUG199616195125 at nssdca.gsfc.nasa.gov> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <30AUG199616195125 at nssdca.gsfc.nasa.gov>, Barry M. Schlesinger wrote: >The standard says that all data must be ASCII text, not only data in >fields. Given the wording in 8.1.3 and the section title of 8.1.5 this is not clear. >The original Harten et al. tables paper states, "The data records are >stored as a large character array....All information is stored as >8-bit printable ASCII characters..." This language excludes control >characters. There is no entry in appendix C to indicate that the >standard differs from the FITS papers in this regard. I believe that it is arguable that in the context of this paper the word "information" only applies to the content within the fields of the rows. This interpretation appears defensible, and it has demonstrable benefits. Are there any technical arguments against it? >This question will probably be discussed at the FITS Technical Panel >meeting next month. See y'all at ADASS. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 2 16:38:57 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA13035; Mon, 2 Sep 1996 16:38:57 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id FAA10310; Mon, 2 Sep 1996 05:37:17 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id FAA08866 for ; Mon, 2 Sep 1996 05:36:10 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA11573; Mon, 2 Sep 96 05:36:02 EDT To: fitsbits at fits.cv.nrao.edu Date: 31 Aug 1996 14:10:51 GMT From: groth at pupgg.princeton.edu (Edward J. Groth 609-258-4361) Message-Id: <509h5b$4np at cnn.Princeton.EDU> Organization: Physics Department, Princeton University Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!gatech!enews.sgi.com!news.mathworks.com!newsfeed.internetmci.com!newsserver.jvnc.net!princeton!cnn.Princeton.EDU!pupgg.princeton.edu!GROTH References: <199608301312.JAA06260 at tetra.gsfc.nasa.gov>,<5079np$ae7 at darkstar.ucsc.edu> Reply-To: groth at pupgg.princeton.edu Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <5079np$ae7 at darkstar.ucsc.edu>, sla at umbra.ucolick.org (Steve Allen) writes: >In article <199608301312.JAA06260 at tetra.gsfc.nasa.gov>, >William Pence wrote: >>Steve Allen wrote: >>> Does the standard permit this, or did I miss some constraint? >> >>The FITS Standard does not allow the ASCII newline character or any >>other ASCII control characters in an ASCII table. Section 8.1.5 states >>that "All data in an ASCII tables extension record shall be ASCII text ..." >>and "ASCII text" is defined to be the ASCII characters hexidecimal 20-7E. > >But wait, playing standards lawyer for a moment I point out that >section 8.1.5 is about "entries" in the table. > >In section 8.1.3 it states > "The table is constructed from a two-dimensional array of ASCII characters." >which means anything in 7-bit ASCII. > >I believe the standard is saying that the data fields themselves may >only contain printable text, but that portions of the table outside >the fields may contain other ASCII charcters. > >In particular, I believe this permits the tricks I suggested. > >If this is not what the standards writers intended then the >language of section 8.1.3 needs clarification. > >-- >Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 >sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 >WWW: http://www.ucolick.org/~sla PGP public keys: see WWW Well, the standards writers certainly never intended that one play tricks and we certainly don't need people to look for loopholes and take advantage of them. I point out that the newline character is a line feed only on Unix. On Macs it's a carriage return. On PCs it's a carriage return and a line feed. On VMS it can be any of the above as well as other formats. Are you prepared to deal with the following? PC user ftp's table, messes around with it, uploads a new version and all of a sudden your software croaks because there are now carriage returns as well as line feeds where they used to be only line feeds and all the positions of the fields are off???? - Ed /----------------------------------------------------------------------\ | Edward J. Groth | Phone: 609-258-4361 Fax: 609-258-6853 | | Physics Dept., Jadwin Hall | URL: http://pupgg.princeton.edu/~groth/ | | Princeton University | SPAN/HEPNET: PUPGG::GROTH=44117::GROTH | | Princeton, NJ 08544 | Internet: groth at pupgg.princeton.edu | \----------------------------------------------------------------------/ From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 2 16:43:02 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA13061; Mon, 2 Sep 1996 16:43:02 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id KAA11570; Mon, 2 Sep 1996 10:46:10 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id KAA10907 for ; Mon, 2 Sep 1996 10:45:08 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA18780; Mon, 2 Sep 96 10:45:05 EDT To: fitsbits at fits.cv.nrao.edu Date: 30 Aug 1996 16:19 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <30AUG199616195125 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!portal.gmu.edu!newsfeed.internetmci.com!howland.erols.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!lerc.nasa.gov!purdue!haven.umd.edu!cs.umd.edu!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: <199608301312.JAA06260 at tetra.gsfc.nasa.gov> <5079np$ae7 at darkstar.ucsc.edu> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <5079np$ae7 at darkstar.ucsc.edu>, sla at umbra.ucolick.org (Steve Allen) writes... >In article <199608301312.JAA06260 at tetra.gsfc.nasa.gov>, >William Pence wrote: >> >>The FITS Standard does not allow the ASCII newline character or any >>other ASCII control characters in an ASCII table. Section 8.1.5 states >>that "All data in an ASCII tables extension record shall be ASCII text ..." >>and "ASCII text" is defined to be the ASCII characters hexidecimal 20-7E. > >But wait, playing standards lawyer for a moment I point out that >section 8.1.5 is about "entries" in the table. > >In section 8.1.3 it states > "The table is constructed from a two-dimensional array of ASCII characters." >which means anything in 7-bit ASCII. It says that only ASCII characters are allowed, not that all ASCII characters are allowed. > >I believe the standard is saying that the data fields themselves may >only contain printable text, but that portions of the table outside >the fields may contain other ASCII charcters. > The standard says that all data must be ASCII text, not only data in fields. The original Harten et al. tables paper states, "The data records are stored as a large character array....All information is stored as 8-bit printable ASCII characters..." This language excludes control characters. There is no entry in appendix C to indicate that the standard differs from the FITS papers in this regard. This question will probably be discussed at the FITS Technical Panel meeting next month. Barry Schlesinger FITS Support Office GSFC/ADF From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 2 16:45:19 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA13079; Mon, 2 Sep 1996 16:45:19 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id QAA13001; Mon, 2 Sep 1996 16:31:43 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA13281 for ; Mon, 2 Sep 1996 16:30:39 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA01935; Mon, 2 Sep 96 16:30:36 EDT To: fitsbits at fits.cv.nrao.edu Date: 2 Sep 1996 06:55:33 GMT From: sla at umbra.ucolick.org (Steve Allen) Message-Id: <50e0d5$nht at darkstar.ucsc.edu> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!gatech!enews.sgi.com!news.mathworks.com!nntp.primenet.com!howland.erols.net!agate!news.ucsc.edu!umbra.ucolick.org!sla References: <199608301312.JAA06260 at tetra.gsfc.nasa.gov> <5079np$ae7 at darkstar.ucsc.edu> <509h5b$4np at cnn.princeton.edu> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <509h5b$4np at cnn.princeton.edu>, Edward J. Groth 609-258-4361 wrote: >Are you prepared to deal with the following? > >PC user ftp's table, messes around with it, uploads a new version >and all of a sudden your software croaks because there are now >carriage returns as well as line feeds where they used to be only >line feeds and all the positions of the fields are off???? Using a good editor the file is just as trivial to return to FITS conformance as it was for a bad editor to break it. There are far worse things that can happen when accepting files from a careless or disreputable PC user. The casual inspection and modification of FITS tables using generic text editors rather than FITS-specific ones opens many possibilities. ASCII tables could be subjected to powerful regular expression matching, substituting, and sorting tools which do not otherwise exist for FITS. The similarity with database inload/outload functions can permit FITS tables to be used as a state-saving and transfer device for the contents of relational databases. FITS ASCII tables are much more robust and self-documenting than most such RDB tools. I see this as a way of putting FITS capabilities into the hands of people who would otherwise not have it because of the bother of constructing programs that do FITS I/O. I doubt that there can be any FITS ASCII table reader which would be unable to read such files. Whether intentional or not the standards documents seem to have permitted a format which could make the data in ASCII tables much more accessible to everyone. Is this a bad thing that must be squelched or a good thing that should be pursued? -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From owner-fitsbits at tarsier.cv.nrao.edu Thu Sep 5 10:41:25 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA28508; Thu, 5 Sep 1996 10:41:25 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id DAA27112; Thu, 5 Sep 1996 03:11:26 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA01402 for ; Thu, 5 Sep 1996 03:10:09 -0400 (EDT) Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA19783 for ; Thu, 5 Sep 1996 03:10:06 -0400 (EDT) Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3) id JAA17403; Thu, 5 Sep 1996 09:06:19 +0200 (MET DST) Message-Id: <199609050708.JAA03948 at ns2.hq.eso.org> Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3) id JAA03948; Thu, 5 Sep 1996 09:08:33 +0200 (MET DST) To: fitsbits at fits.cv.nrao.edu Subject: Poll on the 'DATExxxx' year 2000 issue Date: Thu, 05 Sep 1996 09:08:32 +0200 From: Preben Grosbol Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Dear Friends of FITS, The next millennium is approaching fast which raises the ambiguity issue for the FITS 'DATExxxx' keywords, as Peter Bunclark of RGO noted in his posting "DATE-OBS='31/12/99'" to sci.astro.fits/fitsbits on 1996-06-24. Don Wells, Chair of IAU-FWG, outlined the procedure to identify a solution in his posting of 1996-07-26 and has asked me to conduct it. Two types of solutions were proposed during the discussion in the sci.astro.fits News group, namely: 1) a new data value string definition for the 'DATExxxx' keywords, or 2) a new set of keywords to replace the 'DATExxxx' ones. The main arguments for and against these proposals can be summarized as follows: 1) New format for 'date value string': Pro: The semantic of all 'DATExxxx' keywords is maintained. It is easy for human readers of FITS headers to understand. Con: Direct conflict with definition of format in basic FITS paper. It may result in wrong values or even failure of readers. Readers must be modified to decode the new format correctly. 2) New set of 'date' keywords: Pro: Any format for the 'value string' can be defined. The semantics can be clearly defined e.g. use of time system. Old readers will not fail or give wrong date. Con: Readers must be modified to use the new keyword correctly. Human readers must learn to interpret the new keyword. For either option, all FITS writers which write DATExxxx keywords will need to be changed, and all FITS readers which interpret DATExxxx keywords will need to be changed. Most comments favored the extended ISO 8601 style format for a new date value string, possibly including its time definition. Thus, the main issue at this point is which of the two options is the better rather than the actual new format. The members of the IAU FITS WG were asked to express their opinion on the two options. The main conclusions were: 1) Both options have a chance to be approved by the IAU FITS WG but option 2 only with great difficulty. 2) There is a preference for maintaining the 'DATExxxx' keywords but with an ISO style data value string. 3) There is some preference to allow the date/time ISO format. The main issue is the less precise definition of many 'DATExxxx' keywords (e.g. DATE-OBS), making it meaningless to specify an exact time. As stated above, any solution will require some code changes. Thus, it is important to know the opinion of the general FITS user community before a final proposal is made. I therefore ask you to answer the following questions: a) Which of the two types of solution would you prefer? 1) a new date value string definition for the 'DATExxxx' keywords 2) a new set of keywords to replace the 'DATExxxx' ones b) Do you have any preference for the new 'date value string'? 1) 'CCYY-MM-DD' e.g. '2123-10-21' 2) 'ISO_STYLE CCYY-MM-DD' e.g. 'ISO_STYLE 2123-10-21' 3) a non-ISO format e.g. '21/10/2123' c) Should a full date/time format (e.g. ISO 8601) be allowed? This is an informal questionnaire which is intended to indicate which options will have the higher chance to succeed. The result will be forwarded to the FITS groups and will thereby help them in their decision process. Please send your answers to these three questions to me with copy to Don before 1996-09-18, so that the results of this poll can be discussed at the ADASS'96 meeting. Best regards, Preben Grosbol From owner-fitsbits at tarsier.cv.nrao.edu Thu Sep 5 10:41:45 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA28514; Thu, 5 Sep 1996 10:41:45 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id EAA27882; Thu, 5 Sep 1996 04:08:52 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id EAA01445 for ; Thu, 5 Sep 1996 04:07:35 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA28313; Thu, 5 Sep 96 04:07:30 EDT To: fitsbits at fits.cv.nrao.edu Date: 5 Sep 1996 00:18:52 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <50l69c$a9d at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!news.msfc.nasa.gov!newsfeed.internetmci.com!swrinde!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman References: <50kngg$h72 at post.gsfc.nasa.gov> Subject: Re: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Bill Thompson writes: > Note, by the way that there isn't any ambiguity about an ISO-8601 entry > such as > > DATE_OBS= "1996-09-04T14:41:57.000Z" Um - is that the beginning, middle or end of the exposure? Topocentric or barycentric? Rob :-) -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at tarsier.cv.nrao.edu Thu Sep 5 15:57:49 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA29318; Thu, 5 Sep 1996 15:57:49 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id PAA29211; Thu, 5 Sep 1996 15:29:31 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id PAA03792 for ; Thu, 5 Sep 1996 15:28:12 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA19114; Thu, 5 Sep 96 15:28:09 EDT To: fitsbits at fits.cv.nrao.edu Date: 5 Sep 1996 08:17:38 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <50m2b2$jtn at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!news.msfc.nasa.gov!newsfeed.internetmci.com!csn!nntp-xfer-1.csn.net!ncar!noao!seaman References: <199608301312.JAA06260 at tetra.gsfc.nasa.gov> <50e0d5$nht at darkstar.ucsc.edu> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Steve Allen asserts: >I believe the standard is saying that the data fields themselves may >only contain printable text, but that portions of the table outside >the fields may contain other ASCII charcters. Ed Groth says: > Well, the standards writers certainly never intended that one play > tricks and we certainly don't need people to look for loopholes and > take advantage of them. Steve counters with: > Whether intentional or not the standards documents seem to have > permitted a format which could make the data in ASCII tables much > more accessible to everyone. Is this a bad thing that must be > squelched or a good thing that should be pursued? I'll register my vote against squelching... Another thread in this newsgroup also just touched (tangentially) on the question of ambiguous FITS usage. It seems to me that FITS can be viewed as ambiguous in a couple of different ways. The first is by intent. As with other standards such as X11 and PostScript, FITS mandates no strong usage policy of its own, but relies on contingent standards (or software) to define the policies. Examples are Motif for X11 and EPSF for PostScript - while FITS relies on header keyword conventions (for instance) that are put forth by the different segments of the astronomical community, or de facto usage as defined by AIPS, IRAF or whatever. Like other standards, FITS can also be unintentionally ambiguous (and hopefully only ambiguous and not internally inconsistent). Of course, there are also always examples of data that are simply non-conforming. The usual way to allow for ambiguity is for software that writes data structures to strictly adhere to the standard, but for software that interprets the data structures to only loosely require adherence to the standard. Ideally a FITS reader would require only the loosest possible self-consistent interpretation of the standard. Question: Does the robust functioning of a FITS table reader really require that only printable ASCII characters appear in the data array? The NOST standard is more ambiguous than the original paper (A&A Suppl 73, p365) about the question of non-printing characters. While a little maneuvering room is still available in Harten, et.al., it's hard to argue that the authors' original intent was to allow non-printing ASCII anywhere in the data array. This surely would have been discussed in the paper - precisely because it's a useful feature as Steve has pointed out. However, I don't think we need be inordinately solicitous of the intent of the standards writers (or rather, of the apparent lack of intent in this case). The astronomical community governs FITS, not the other way around. If the wording of the standard allows a particular usage, then either the wording should be changed - or the usage should be accepted. One could even use the golden rule of "once FITS, always FITS" to argue that any ambiguity that creeps through is instantly incorporated into the standard for all time. If nothing else, this certainly argues for wording every proposed change to the standard with extreme care. But I think we should think twice about rejecting all "loopholes" out of hand... A lot of the FITS deliberations lately have risen out of these same loopholes - or out of the seams between different parts of the standard. I'd argue that this is a sign of the maturity of FITS. Issues that were left unaddressed by the early history of FITS are now of increasing importance. Without the elbow room provided by the (intentional or unintentional) ambiguity of the standard, FITS would be handcuffed when dealing with the current issues. An alternate interpretation is that each change to the standard should be as tightly constraining as possible, since it will always be possible to relax the constraints later should that prove to be desirable. Perhaps including non-printing characters in FITS ASCII tables is an example of this. Note that even if the original tables specification is reaffirmed as not allowing non-printing characters, adding this as a new feature is entirely consistent with the rules of FITS. No preexisting data would be harmed. Software might break, but it would likely break in the politically accepted manner - by totally bombing, that is. On the other hand, it would also be unsurprising if current tables software passed over non-printing characters with nary a burp. Steve's suggestion appears to make ASCII tables much easier to use. Non-printing characters, especially between fields if not in the fields themselves, do not complicate the standard to any great extent. Meanwhile, Lucio Chiappetti wonders: > Is anyone using FITS ASCII tables at all nowadays, or not only BINTABLEs ? Folks likely will continue to use ASCII tables for the same purposes they originally did - for large catalogs and as an easily accessible human readable format. Note that ease of use was integral to the original design and may certainly continue to distinguish ASCII from binary FITS tables. Also, not withstanding that Harten, et.al., state that "... the format is primarily intended to be used for the transfer of information rather than the storage of information", ASCII tables are likely to be preferred for archival applications. Why am I showing any interest in this issue? Well, it occurs to me that by permitting non-printing ASCII field and record separators, it would be immediately possible to store a /rdb database in a FITS table extension - or rather, a legal FITS table could be operated on and maintained by this relational database. /rdb is a Unix tools style RDB that uses ASCII files with tab delimited fields. It can support surprisingly large databases - 800,000 image headers from the NOAO archive occupy about 145Mb in one R&D database we've constructed. Separate binary index files can be generated as needed. By design, /rdb encourages access to the DB using tools such as awk, sed, perl and the Unix shells. This is precisely the same functionality that Steve has suggested for FITS tables. Note that while some scripting languages nominally support remappable field and record delimiting characters (perhaps providing a way of working with FITS tables using generic tools from the other end) - these are only marginally useful in practice. Embarrassingly, probably the best known example of such usage for shell scripts is as the prototypical setuid security hole. Allowing easy user level FITS support for such text based tools would indeed require permitting tabs, newlines and perhaps other ASCII control characters into the data. Is this feature worth the trouble? I think so. Is this extremely dangerous? No. Is this something to worry about right now? Opinions will differ. On the other hand, constraining tabular data arrays (not only FITS) to contain only printable ASCII makes many classes of applications that rely on "out-of-band" data (non-printing control characters, in the case of ASCII) impossible. Rob -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at tarsier.cv.nrao.edu Thu Sep 5 17:22:18 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA29567; Thu, 5 Sep 1996 17:22:18 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id QAA29494; Thu, 5 Sep 1996 16:45:03 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA04369 for ; Thu, 5 Sep 1996 16:43:43 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA21857; Thu, 5 Sep 96 16:43:38 EDT To: fitsbits at fits.cv.nrao.edu Date: Wed, 4 Sep 1996 19:00:58 GMT From: alspehr at mhd3.uchicago.edu (Alanna Spehr) Message-Id: Organization: University of Chicago, Astronomy and Astrophysics Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!interpath!news.interpath.net!news.sprintlink.net!news-fw-22.sprintlink.net!news.ultranet.com!homer.alpha.net!uwm.edu!spool.mu.edu!newspump.sol.net!www.nntp.primenet.com!nntp.primenet.com!cs.utexas.edu!howland.erols.net!vixen.cso.uiuc.edu!uchinews!mhd3.uchicago.edu!alspehr Subject: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk I have fits files that have: OBS_TIME= 52917 in their header. (Along with OBS_DATE and DATE, if it matters.) Can somebody tell me what the 52917 is, and how I can change it to something more useful? Or, is there someplace that would document things like this? Thanks Als From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 6 01:18:03 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA31013; Fri, 6 Sep 1996 01:18:03 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id SAA29781; Thu, 5 Sep 1996 18:38:27 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id SAA05244 for ; Thu, 5 Sep 1996 18:37:08 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA26034; Thu, 5 Sep 96 18:37:05 EDT To: fitsbits at fits.cv.nrao.edu Date: 5 Sep 1996 07:31:55 GMT From: sla at umbra.ucolick.org (Steve Allen) Message-Id: <50lvlb$c98 at darkstar.ucsc.edu> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!spool.mu.edu!newspump.sol.net!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!newsfeed.internetmci.com!news.zeitgeist.net!bdt.com!hal.COM!news.ucsc.edu!umbra.ucolick.org!sla References: Subject: Re: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article , Alanna Spehr wrote: >Can somebody tell me what the 52917 is, and how I can change it >to something more useful? Or, is there someplace that would >document things like this? Not having an answer to this question, I pose another: Documenting the semantics and syntax of all FITS keywords would require a community-wide effort involving every site which has written a FITS file. Let us assume that it be possible to gather FITS keyword characteristics (semantics, format, units, defining authority, dates of use, etc.) into a database which be globally updatable and queryable via the WWW. How valuable might such a database be? -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 6 01:23:15 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id BAA31052; Fri, 6 Sep 1996 01:23:15 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id BAA31021; Fri, 6 Sep 1996 01:18:26 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id BAA07945 for ; Fri, 6 Sep 1996 01:17:03 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA09818; Fri, 6 Sep 96 01:17:01 EDT To: fitsbits at fits.cv.nrao.edu Date: 4 Sep 1996 20:06:40 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <50kngg$h72 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.sgi.com!news.msfc.nasa.gov!newsfeed.internetmci.com!in3.uu.net!news2.digex.net!news5.digex.net!haven.umd.edu!hecate.umd.edu!cs.umd.edu!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: Subject: Re: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk alspehr at mhd3.uchicago.edu (Alanna Spehr) writes: >I have fits files that have: >OBS_TIME= 52917 >in their header. (Along with OBS_DATE and DATE, if it matters.) >Can somebody tell me what the 52917 is, and how I can change it >to something more useful? Or, is there someplace that would >document things like this? Just as a guess, the number of seconds into the day? That would work out to 14:41:57. This sort of convention should be explained as a comment, e.g. OBS_TIME= 52917 /Seconds into the day (UTC) Note, by the way that there isn't any ambiguity about an ISO-8601 entry such as DATE_OBS= "1996-09-04T14:41:57.000Z" Bill Thompson From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 9 09:31:48 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA13027; Mon, 9 Sep 1996 09:31:48 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id FAA32373; Fri, 6 Sep 1996 05:19:23 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id FAA00510 for ; Fri, 6 Sep 1996 05:17:58 -0400 (EDT) Received: from rlsaxps.bnsc.rl.ac.uk (ptw at [130.246.32.128]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id FAA07645 for ; Fri, 6 Sep 1996 05:17:55 -0400 (EDT) Received: from localhost (ptw at localhost) by rlsaxps.bnsc.rl.ac.uk (8.7.4/8.7.3) with SMTP id KAA10911 for ; Fri, 6 Sep 1996 10:16:39 +0100 (BST) X-Authentication-Warning: rlsaxps.bnsc.rl.ac.uk: ptw owned process doing -bs Date: Fri, 6 Sep 1996 10:16:38 +0100 (BST) From: Patrick Wallace X-Sender: ptw at rlsaxps.bnsc.rl.ac.uk To: fitsbits at fits.cv.nrao.edu Subject: Re: Question about a fits header Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk On Wed, 4 Sep 1996, Alanna Spehr wrote: > I have fits files that have: > > OBS_TIME= 52917 > > in their header. (Along with OBS_DATE and DATE, if it matters.) > Can somebody tell me what the 52917 is, and how I can change it > to something more useful? My guess is it's a Modified Julian Date (JD-2400000.5). A procedure for turning an MJD into year, month, day is appended. There are other ways of doing it (see the Explanatory Supplement to the Astronomical Almanac). 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-445848 ____________________________________________________________________________ SUBROUTINE sla_DJCL (DJM, IY, IM, ID, FD, J) *+ * - - - - - * D J C L * - - - - - * * Modified Julian Date to Gregorian year, month, day, * and fraction of a day. * * Given: * DJM dp modified Julian Date (JD-2400000.5) * * Returned: * IY int year * IM int month * ID int day * FD dp fraction of day * J int status: * 0 = OK * -1 = unacceptable date (before 4701BC March 1) * * The algorithm is derived from that of Hatcher 1984 * (QJRAS 25, 53-55). * * P.T.Wallace Starlink 23 November 1994 * * Copyright (C) 1995 Rutherford Appleton Laboratory *- IMPLICIT NONE DOUBLE PRECISION DJM INTEGER IY,IM,ID DOUBLE PRECISION FD INTEGER J DOUBLE PRECISION F,D INTEGER JD,N4,ND10 * Check if date is acceptable IF (DJM.LE.-2395522D0.OR.DJM.GE.1D9) THEN J=-1 ELSE J=0 * Separate day and fraction F=MOD(DJM,1D0) IF (F.LT.0D0) F=F+1D0 D=NINT(DJM-F) * Express day in Gregorian calendar JD=NINT(D)+2400001 N4=4*(JD+((6*((4*JD-17918)/146097))/4+1)/2-37) ND10=10*(MOD(N4-237,1461)/4)+5 IY=N4/1461-4712 IM=MOD(ND10/306+2,12)+1 ID=MOD(ND10,306)/10+1 FD=F J=0 END IF END From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 9 09:33:37 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA13041; Mon, 9 Sep 1996 09:33:37 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id UAA01160; Sat, 7 Sep 1996 20:41:51 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id UAA00321 for ; Sat, 7 Sep 1996 20:41:46 -0400 (EDT) Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA01798 for ; Fri, 6 Sep 1996 21:17:50 -0400 (EDT) Received: (from pence at localhost) by tetra.gsfc.nasa.gov (LHEA9504/950407.s1) id PAA00765; Fri, 6 Sep 1996 15:34:21 -0400 Date: Fri, 6 Sep 1996 15:34:21 -0400 From: William Pence Message-Id: <199609061934.PAA00765 at tetra.gsfc.nasa.gov> To: fitsbits at fits.cv.nrao.edu Subject: CFITSIO - full ANSI C version now available Cc: pence at tetra.gsfc.nasa.gov Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Full Release of CFITSIO is Now Available ---------------------------------------- The full release of the CFITSIO software library, written in ANSI C, is now available for general use. The routines in this CFITSIO library provide a portable interface for reading and writing any type of FITS format data file. These C routines are closely modelled after the Fortran subroutines in the original FITSIO library and provide all the same functionality. Any users of the previous beta releases of CFITSIO should upgrade to the current full release. Both the new CFITSIO (ANSI C) and the older FITSIO (Fortran-77) software may be obtained on the WWW from: http://heasarc.gsfc.nasa.gov/fitsio Alternatively, this software may be obtained via anonymous ftp at: legacy.gsfc.nasa.gov in the software/fitsio/c/ or software/fitsio/fortran/ directories. ------------------------------------------------------------------------- William Pence High Energy Astrophysics Science Archive Research Center NASA/GSFC e-mail: pence at tetra.gsfc.nasa.gov phone: (301)286-4599 From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 9 09:49:29 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA13112; Mon, 9 Sep 1996 09:49:29 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id VAA02159; Sat, 7 Sep 1996 21:32:05 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id UAA11096 for ; Sat, 7 Sep 1996 20:49:38 -0400 (EDT) Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id UAA00341 for ; Sat, 7 Sep 1996 20:49:34 -0400 (EDT) Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id VAA01801 for ; Fri, 6 Sep 1996 21:17:52 -0400 (EDT) Received: (from pence at localhost) by tetra.gsfc.nasa.gov (LHEA9504/950407.s1) id LAA01796 for fitsbits at fits.cv.nrao.edu; Fri, 6 Sep 1996 11:14:01 -0400 Date: Fri, 6 Sep 1996 11:14:01 -0400 From: William Pence Message-Id: <199609061514.LAA01796 at tetra.gsfc.nasa.gov> To: fitsbits at fits.cv.nrao.edu Subject: Re: ASCII table tricks Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Would the proponents for allowing ASCII control characters in ASCII tables also want to allow CR and LF characters at the end of each header keyword? It seems like this would also be required if one wants to be able to use standard text editors on FITS files. -Bill Pence From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 9 10:47:27 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA13591; Mon, 9 Sep 1996 10:47:27 -0400 Received: from primate.cv.nrao.edu (egreisen at primate.cv.nrao.edu [192.33.115.67]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with SMTP id KAA13539; Mon, 9 Sep 1996 10:42:49 -0400 Received: by primate.cv.nrao.edu (5.x/S2.3/NRAO-CV/2.4) id AA01312; Mon, 9 Sep 1996 10:42:46 -0400 Date: Mon, 9 Sep 1996 10:42:46 -0400 From: egreisen at nrao.edu (Eric Greisen) Message-Id: <9609091442.AA01312 at primate.cv.nrao.edu> To: fitsbits at primate.cv.nrao.edu Subject: New release of WCS draft Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk This broadcast is to announce a new version of the paper describing the coordinates proposal by Mark Calabretta and myself. The paper is available as wcs.all.ps, wcs.all.ps.Z and wcs.none.ps.Z (only) from the fits ftp/WWW site (fits.cv.nrao.edu) in the fits/documents/wcs directory. There have been a lot of changes in the paper since the last broadcast version of about two (!) years ago. Some intermediate versions of the paper were placed in the fits area, but not broadcast widely. I have attempted to run 'diff' to find out what the changes are, but expect that I have missed some. What I found is listed below: 1. The paper has been converted to A & A format with suitable style changes, re-arranging of long equations, dropping excess figures, etc. 2, The subject of default coordinate types (there is none now), and general longitude and latitude types is addressed. 3. The finding of the native North pole from the reference point (when it is not the North pole itself) required a lengthy generalization and discussion and the introduction of the LATPOLE keyword. 4. AIR projection mathematics corrected. 5. CYL now called CYP. 6. CEA definition of lambda corrected. 7. Conical projections reference pixels now at the central Native latitude and PROJP1 gives the central latitude and PROJP2 gives 1/2 of the difference of the 2 latitudes of the projection. All conical projections required a little change, mostly in Y_0, in the math. 8. COP - add an alternate form of Rtheta. 9. COO - change symbols. 10. BON - simpler formulation. 11. GLS - correct formula for phi. 12. PAR - correct units. 13. QSC - better symbols, corrected formulae 14. TSC - extra form for x_f, y_f 15. Added appendix defining Pixel regularization image. 16. Added references to Calabretta's software package known as wcslib (version 2.0 now in preparation). 17. Correct accuracy of numbers in numeric example. 18. Generalize conics slightly to allow ref latitude < 0. 19. Figures 30 and 31 had the computation of the difference between ZEA and SIN corrected. ZEA is very similar to ARC and STG now. (Thanks to Steve Allen.) 20. The translation between the PC matrix and the old CDELT/CROTA system was corrected. The order of the matrix multiplies matters and was done wrongly in developing those formulae. 21. References to the PROJPn, particularly in Table 5, were incomplete and out of date. 22. A strong recommendation to make the PC matrix positive as well as diagonal was added. The sentences on CDmmmnnn and CDn_m were made into a separate (short) paragraph. 23. The reference to wcslib was brought up to rev 2.3 and the misstatement about public domain was corrected. 24. The increments in the pixel regularization image do not have to integer image pixels, but can be any appropriate value. A statement to clarify this was added. 25. The wording in the abstract re other kinds of coordinates was modified. 26. An appendix by Bill Pence, Arnold Rots, and Lorella Angelini suggesting extensions to the main conventions to cover coordinates in tables has been included. 27. Casual wording regarding "reference pixel" was improved and generally changed to "reference point". This seems like a lot - I guess #15 (and maybe #26) are the biggest changes which should get wide discussion. #2, 3, 7 are significant as well, while #1 was surprisingly easy and mostly cosmetic. Please let us know what you think. Eric Greisen (egreisen at nrao.edu) Mark Calabretta (mcalabre at atnf.csiro.au) From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 9 11:40:04 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA13821; Mon, 9 Sep 1996 11:40:04 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id KAA13620; Mon, 9 Sep 1996 10:57:48 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id KAA02718 for ; Mon, 9 Sep 1996 10:57:44 -0400 (EDT) Received: from silk.gsfc.nasa.gov (silk.gsfc.nasa.gov [128.183.127.210]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id KAA29855 for ; Mon, 9 Sep 1996 10:57:42 -0400 (EDT) Received: by silk.gsfc.nasa.gov; id AA09311; Mon, 9 Sep 1996 10:59:47 -0400 Message-Id: <323430E3.794B at silk.gsfc.nasa.gov> Date: Mon, 09 Sep 1996 10:59:47 -0400 From: "Thomas A. McGlynn" Organization: NASA Goddard Space Flight Center/USRA X-Mailer: Mozilla 3.0b7 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Patrick Wallace Cc: fitsbits at fits.cv.nrao.edu Subject: Re: Question about a fits header References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Patrick Wallace wrote: > > On Wed, 4 Sep 1996, Alanna Spehr wrote: > > > I have fits files that have: > > > > OBS_TIME= 52917 > > > > in their header. (Along with OBS_DATE and DATE, if it matters.) > > Can somebody tell me what the 52917 is, and how I can change it > > to something more useful? > > My guess is it's a Modified Julian Date (JD-2400000.5). A procedure > for turning an MJD into year, month, day is appended. There are > other ways of doing it (see the Explanatory Supplement to the > Astronomical Almanac). > > Patrick Wallace > Alas, MJD 52917 is about 7 years in the future. I think you need to get in touch with whoever wrote the FITS file to find out what it means. Tom McGlynn From owner-fitsbits at tarsier.cv.nrao.edu Tue Sep 10 15:36:37 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id PAA26021; Tue, 10 Sep 1996 15:36:37 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id PAA25091; Tue, 10 Sep 1996 15:07:04 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id PAA14784 for ; Tue, 10 Sep 1996 15:07:00 -0400 (EDT) Received: from STARS.GSFC.NASA.GOV (stars.gsfc.nasa.gov [128.183.172.28]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id PAA20514 for ; Tue, 10 Sep 1996 15:06:58 -0400 (EDT) Date: Tue, 10 Sep 1996 14:33:10 -0400 (EDT) From: RANDY THOMPSON (301) 286-8800 To: FITSBITS at fits.cv.nrao.edu CC: RTHOMPSON at iuedac.gsfc.nasa.gov Message-Id: <960910143310.25600170 at iuedac.gsfc.nasa.gov> Subject: Re: ASCII Table tricks Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk I agree with Bill Pence and Barry Schlesinger in interpreting the current NOST standard as saying only ASCII text characters (i.e hexidecimal 20-7E) should appear in the records of an ASCII Tables extension. However, it seems to me that a Binary Tables extension could be used to store the data described earlier by Steve Allen? Maybe I'm missing something (since I haven't seen this suggested already), but why not store the ASCII text as character strings and define fields of byte data type to contain the byte values of non-printable ASCII characters? If you strip off the headers, the remaining records should be identical to those that could be produced with the ASCII Tables extension. If this isn't suitable, I would think one could still propose a change to the current FITS standard that would (unambiguously) allow non-printable ASCII characters as non-field values. If existing FITS readers are really not impacted, why should such a proposed change not be approved? Of course, the change would still need to go through the established approval process. Alternatively, one could define a new table extension following the requirements for conforming extensions. The new extension could simply follow the existing rules for ASCII Tables but without the ASCII text restrictions. Randy Thompson From owner-fitsbits at tarsier.cv.nrao.edu Tue Sep 10 16:38:39 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id QAA26474; Tue, 10 Sep 1996 16:38:39 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id QAA26436; Tue, 10 Sep 1996 16:36:33 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id QAA15406 for ; Tue, 10 Sep 1996 16:36:29 -0400 (EDT) Received: from silk.gsfc.nasa.gov (silk.gsfc.nasa.gov [128.183.127.210]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA23181 for ; Tue, 10 Sep 1996 16:36:25 -0400 (EDT) Received: by silk.gsfc.nasa.gov; id AA11547; Tue, 10 Sep 1996 16:38:26 -0400 Message-Id: <3235D1C2.6956 at silk.gsfc.nasa.gov> Date: Tue, 10 Sep 1996 16:38:26 -0400 From: "Thomas A. McGlynn" Organization: NASA Goddard Space Flight Center/USRA X-Mailer: Mozilla 3.0b7 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: "RANDY THOMPSON (301) 286-8800" Cc: FITSBITS at fits.cv.nrao.edu Subject: Re: ASCII Table tricks References: <960910143310.25600170 at iuedac.gsfc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk RANDY THOMPSON (301) 286-8800 wrote: >... However, > it seems to me that a Binary Tables extension could be used to store the > data described earlier by Steve Allen? Maybe I'm missing something (since I > haven't seen this suggested already), but why not store the ASCII text as > character strings and define fields of byte data type to contain the byte > values of non-printable ASCII characters? If you strip off the headers, > the remaining records should be identical to those that could be produced > with the ASCII Tables extension. > If this isn't suitable, I would think one could still propose a change to > the current FITS standard that would (unambiguously) allow non-printable ASCII > characters as non-field values. If existing FITS readers are really not > impacted, why should such a proposed change not be approved? Of course, the > change would still need to go through the established approval process. ... > > Randy Thompson I think that adding additional meaningless columns to a binary table does substantial violence to the file since, e.g., it changes the column numbers of the real data. But I really like the idea that ASCII tables be readable as readable as possible. When ASCII tables were introduced they were the only standard way for creating tabular data. But with the advent of binary tables the only rationale I can see for using them is that they are directly readable by humans. I can attest from personal experience that it is very helpful to be able to read the tables -- one trick I use is to adjust the width of my screen to the length of the table. Even if the rows don't start in the beginning it still helps a lot. In writing a STBRYAFWFIDL (Someday-to-be-released, Yet-another-FITS-writer- for-IDL), I had anticipated users wanting to separate and delimit rows and I'm quite disappointed that it is at best questionable FITS to delimit the columns in the most natural way. I think we are choosing between making ASCII tables completely obsolete or leaving them a niche market in the FITS file economy. If it truly is 'illegal' to use \n in a FITS table, I would second Randy's call for an amendment to their definition. Tom McGlynn GSFC. Tom McGlynn From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 13 10:06:44 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA26231; Fri, 13 Sep 1996 10:06:44 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id WAA22399; Thu, 12 Sep 1996 22:50:19 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id WAA09302 for ; Thu, 12 Sep 1996 22:50:14 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA02857; Thu, 12 Sep 96 22:50:11 EDT To: fitsbits at fits.cv.nrao.edu Date: 9 Sep 1996 16:04:47 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <511f6v$il9 at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in3.uu.net!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman References: <199609061514.LAA01796 at tetra.gsfc.nasa.gov> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Bill Pence writes: > Would the proponents for allowing ASCII control characters in > ASCII tables also want to allow CR and LF characters at the > end of each header keyword? I was wondering when someone would mention that. It would be fairly straightforward to arrange to skip over a header and apply some general operation beginning at a byte offset into a file. I'd be interested in hearing specific plans for this, though. Note also that not all editors will choke on a line 2880+ characters long. Of course, reformatting the table data on the fly to include the necessary control characters (and remove them again afterwards) is also possible, but this is a much more expensive and obscure operation. Has anyone simply tried embedding newlines in a table to see what happens with current software (and what the handling advantages are)? Rob -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 13 10:08:59 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA26242; Fri, 13 Sep 1996 10:08:59 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id FAA25425; Fri, 13 Sep 1996 05:10:48 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id FAA11856 for ; Fri, 13 Sep 1996 05:10:41 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA14229; Fri, 13 Sep 96 05:10:36 EDT To: fitsbits at fits.cv.nrao.edu Date: 10 Sep 1996 17:30:07 GMT From: seaman at noao.edu (Rob Seaman) Message-Id: <5148iv$t8v at noao.edu> Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!uwm.edu!math.ohio-state.edu!howland.erols.net!newsfeed.internetmci.com!news.msfc.nasa.gov!bcm.tmc.edu!cs.utexas.edu!ennfs.eas.asu.edu!noao!seaman References: Subject: Re: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Bill Wyatt (wyatt at cfahub.harvard.edu) writes: > Since there are 86,400 seconds in a day, and there was a DATE keyword, > 52917 is surely is the second of the indicated day. But is it UT or local time? This corresponds to 14:41:57 or ~ 2:42 PM if it's local time. One can probably safely assume standard rather than daylight savings time. Note, however, that "52917" can also be interpreted as a legal ISO 8601 time string, representing ~ 5:30 AM, local time (no "Z", so not UT). I don't know what ISO 8601 says about daylight time. At least, as best I can tell it's legal to omit the leading zero for the hours field. The only constraint I see in the web summaries of the standard is that the time cannot be truncated from the left - but only when the combined date/time format is used, otherwise hyphens are used as place keepers for missing fields. The "T" is optional if the usage is clear from the context (the name of the keyword is "OBS_TIME"). Does anybody have an official copy of the ISO 8601 standard that they can bring to the ADASS meeting? We may want to consult it before we adopt it into FITS... Hopefully the standard itself is more clear about issues like omitting leading zeroes than the summaries are. One concern I have about the ISO standards is that it is rather hard to find a copy without buying one yourself. For instance, the University of Arizona library doesn't appear to have a copy. There may not be a copy anywhere in Tucson - or Arizona, for that matter. On the other hand, the FITS standard has been propagated around the world wherever there are copies of the A&A Supplements - or you can just get the documents off the web. The answer to the original question, by the way, is that only the authors of this particular FITS file (or of the software that produced it) will be able to reliably define what "OBS_TIME" means, since this is not a standard FITS keyword. If the authors can't be consulted, then reality checks such as that optical/near IR data (not calibrations) must have been acquired during local nighttime are about all you have to go on. An hour angle or airmass keyword can be converted back into a sidereal time if you have the telescope coordinates (celestial and geographic). Rob Seaman -- seaman at noao.edu, http://iraf.noao.edu/~seaman NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248 PGP: 98 8D 8B 49 74 9A 41 88 3A 43 87 54 51 BF 30 4B From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 13 10:09:44 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA26248; Fri, 13 Sep 1996 10:09:44 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id GAA25599; Fri, 13 Sep 1996 06:13:04 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id GAA12233 for ; Fri, 13 Sep 1996 06:12:55 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA15600; Fri, 13 Sep 96 06:12:51 EDT To: fitsbits at fits.cv.nrao.edu Date: 9 Sep 1996 17:58:08 GMT From: sla at umbra.ucolick.org (Steve Allen) Message-Id: <511lrg$bn5 at darkstar.ucsc.edu> Organization: UCO/Lick Observatory, Santa Cruz Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!taco.cc.ncsu.edu!gatech!newsjunkie.ans.net!newsfeeds.ans.net!news-w.ans.net!newsfeeds.ans.net!news.lava.net!nntp.reed.edu!nntp.teleport.com!news.serv.net!news.alt.net!news1.alt.net!news.u.washington.edu!news.uoregon.edu!news-peer.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!news.zeitgeist.net!bdt.com!hal.COM!news.ucsc.edu!umbra.ucolick.org!sla References: <199609061514.LAA01796 at tetra.gsfc.nasa.gov> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article <199609061514.LAA01796 at tetra.gsfc.nasa.gov>, William Pence wrote: >Would the proponents for allowing ASCII control characters in >ASCII tables also want to allow CR and LF characters at the >end of each header keyword? It seems like this would >also be required if one wants to be able to use standard >text editors on FITS files. Certainly not. I do not pretend that it is possible to make a FITS file comprehensible to an arbitrary text editing application. I do find that the addition of carriage control information between the fields makes the table trivial to view and process by many more applications. My editor has no problem with a FITS header as is. With the addition of separators between the fields the ASCII table records become relatively easy to edit, too. This is obviously not something that should be tried by a naive user with a poor editor, but that is hardly a reason to prohibit the possibility. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla at ucolick.org Voice: +1 408 459 3046 FAX: +1 408 454 9863 WWW: http://www.ucolick.org/~sla PGP public keys: see WWW From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 13 10:12:32 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA26276; Fri, 13 Sep 1996 10:12:32 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id JAA26162; Fri, 13 Sep 1996 09:53:51 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id JAA13776 for ; Fri, 13 Sep 1996 09:53:47 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA24820; Fri, 13 Sep 96 09:53:44 EDT To: fitsbits at fits.cv.nrao.edu Date: Tue, 10 Sep 1996 15:21:07 GMT From: wyatt at cfahub.harvard.edu (Bill Wyatt) Message-Id: Organization: Smithsonian Astrophysical Observatory, Cambridge, MA, USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!aruba.odu.edu!maui.cc.odu.edu!news.larc.nasa.gov!news.msfc.nasa.gov!bcm.tmc.edu!cs.utexas.edu!nntp.primenet.com!cam-news-hub1.bbnplanet.com!das-news2.harvard.edu!oitnews.harvard.edu!cfanews!cfahub!wyatt References: <323430E3.794B at silk.gsfc.nasa.gov> Subject: Re: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Since there are 86,400 seconds in a day, and there was a DATE keyword, 52917 is surely is the second of the indicated day. Thomas A. McGlynn (tam at silk.gsfc.nasa.gov) wrote: : >Patrick Wallace wrote: : >> : >> On Wed, 4 Sep 1996, Alanna Spehr wrote: : >> : >> > I have fits files that have: : >> > : >> > OBS_TIME= 52917 : >> > : >> > in their header. (Along with OBS_DATE and DATE, if it matters.) : >> > Can somebody tell me what the 52917 is, and how I can change it : >> > to something more useful? : >> : >> My guess is it's a Modified Julian Date (JD-2400000.5). A procedure : >> for turning an MJD into year, month, day is appended. There are : >> other ways of doing it (see the Explanatory Supplement to the : >> Astronomical Almanac). : >> : >> Patrick Wallace : >> : >Alas, MJD 52917 is about 7 years in the future. I think : >you need to get in touch with whoever wrote the FITS file : >to find out what it means. : > Tom McGlynn -- Bill Wyatt (wyatt at cfa.harvard.edu) Smithsonian Astrophysical Observatory (Cambridge, MA, USA) From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 13 14:20:08 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id OAA27673; Fri, 13 Sep 1996 14:20:08 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id OAA27567; Fri, 13 Sep 1996 14:01:32 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id OAA15678 for ; Fri, 13 Sep 1996 14:01:28 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA05570; Fri, 13 Sep 96 14:01:24 EDT To: fitsbits at fits.cv.nrao.edu Date: 10 Sep 1996 23:06:08 GMT From: thompson at orpheus.nascom.nasa.gov (William Thompson) Message-Id: <514s90$kt9 at post.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!maui.cc.odu.edu!news.larc.nasa.gov!lll-winken.llnl.gov!uwm.edu!spool.mu.edu!newspump.sol.net!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!lerc.nasa.gov!purdue!haven.umd.edu!news.umbc.edu!cs.umd.edu!newsfeed.gsfc.nasa.gov!orpheus.nascom.nasa.gov!thompson References: <5148iv$t8v at noao.edu> Subject: Re: Question about a fits header Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk seaman at noao.edu (Rob Seaman) writes: >Bill Wyatt (wyatt at cfahub.harvard.edu) writes: (stuff deleted) >Does anybody have an official copy of the ISO 8601 standard that they >can bring to the ADASS meeting? We may want to consult it before we adopt >it into FITS... Hopefully the standard itself is more clear about issues >like omitting leading zeroes than the summaries are. >One concern I have about the ISO standards is that it is rather hard to >find a copy without buying one yourself. For instance, the University >of Arizona library doesn't appear to have a copy. There may not be a >copy anywhere in Tucson - or Arizona, for that matter. On the other >hand, the FITS standard has been propagated around the world wherever >there are copies of the A&A Supplements - or you can just get the >documents off the web. Yes, the ISO-8601 standard costs money, but I believe that the CCSDS recommendation, which is a restricted subset of ISO-8601, is free. I've posted that recommendation in the past. In any case, it's probably better to restrict the ISO-8601 standard to a sane subset, rather than try to implement everything. Bill Thompson From owner-fitsbits at tarsier.cv.nrao.edu Sun Sep 15 12:42:01 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA05979; Sun, 15 Sep 1996 12:42:01 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id SAA29262; Fri, 13 Sep 1996 18:16:31 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id SAA17474 for ; Fri, 13 Sep 1996 18:16:25 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA16833; Fri, 13 Sep 96 18:16:22 EDT To: fitsbits at fits.cv.nrao.edu Date: 10 Sep 1996 09:52:07 GMT From: mark-r at msi.campus-ventures.co.uk (Dr. Mark Robinson) Message-Id: <513do7$hol at yama.mcc.ac.uk> Organization: Manchester Scientific Instruments Ltd. Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in3.uu.net!news.mathworks.com!usenet.eel.ufl.edu!warwick!yama.mcc.ac.uk!msi.campus-ventures.co.uk!mark-r Subject: Linux FITS viewer source available Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Hi. Largely because of the wide variation of Linux systems about these days (and because I can't stand statically-linked binaries) the source code for my primitive FITS viewer is now on our FTP site. A word of warning - it is still very alpha, and pretty basic - really all it does is load and display images, and provide a histogram. Still, feel free to download it. Since I can't remember the path name, either go in through the web at http://msi.campus-ventures.co.uk/ or ftp to ftp://msi.campus-ventures.co.uk/ and have a rummage around. Cheers mark-r -- Manchester Scientific Instruments |I'm a slug and I'm alright Campus Ventures Centre. Uni of M/CR.|That's cos I'm hermaphrodite Oxford Rd. Manchester. M13 9PL, UK |It bothers me not that I have no friends http://msi.campus-ventures.co.uk/ |Cos I can have fun with both my ends. From owner-fitsbits at tarsier.cv.nrao.edu Sun Sep 15 12:44:34 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA06002; Sun, 15 Sep 1996 12:44:34 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id FAA32146; Sat, 14 Sep 1996 05:41:37 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id FAA22102 for ; Sat, 14 Sep 1996 05:41:26 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA07789; Sat, 14 Sep 96 05:41:19 EDT To: fitsbits at fits.cv.nrao.edu Date: Mon, 09 Sep 1996 23:49:05 -0400 From: Archie Warnock Message-Id: <3234E531.7F1621DA at clark.net> Organization: A/WWW Enterprises Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!newsgate.duke.edu!news.mathworks.com!newsfeed.internetmci.com!newsxfer2.itd.umich.edu!howland.erols.net!spool.mu.edu!newshub.tc.umn.edu!mr.net!news.clark.net!usenet References: <199609061514.LAA01796 at tetra.gsfc.nasa.gov> Subject: Re: ASCII table tricks Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk William Pence wrote: > Would the proponents for allowing ASCII control characters in > ASCII tables also want to allow CR and LF characters at the > end of each header keyword? It seems like this would > also be required if one wants to be able to use standard > text editors on FITS files. Not necessarily. It's pretty easy to split off the header from the data and just access the data directly. Now, if someone wanted to propose allowing CR/LF characters in the header, I'd sure think that was a fine idea, too, but it's not related to the idea of placing extra (and undefined) characters in the tables. I always thought it was pretty obvious that one could put those extra characters into the tables. There's no requirement that the table header define every column of the table. -- Archie -- Archie Warnock Internet: warnock at clark.net -- A/WWW Enterprises Phone/FAX: 301-854-2987 -- http://www.clark.net/pub/warnock/warnock.html -- As a matter of fact, I _do_ speak for my employer. From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 16 10:51:55 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA07834; Mon, 16 Sep 1996 10:51:55 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id DAA11928; Mon, 16 Sep 1996 03:25:53 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA10629 for ; Mon, 16 Sep 1996 03:25:49 -0400 (EDT) Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id DAA26391 for ; Mon, 16 Sep 1996 03:25:45 -0400 (EDT) Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3) id JAA14201; Mon, 16 Sep 1996 09:20:26 +0200 (MET DST) Message-Id: <199609160724.JAA12238 at ns2.hq.eso.org> Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3) id JAA12238; Mon, 16 Sep 1996 09:24:05 +0200 (MET DST) To: fitsbits at fits.cv.nrao.edu Subject: Reminder>Poll on the 'DATExxxx' year 2000 issue Date: Mon, 16 Sep 1996 09:24:04 +0200 From: Preben Grosbol Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Dear Friends of FITS, The next millennium is approaching fast which raises the ambiguity issue for the FITS 'DATExxxx' keywords, as Peter Bunclark of RGO noted in his posting "DATE-OBS='31/12/99'" to sci.astro.fits/fitsbits on 1996-06-24. Don Wells, Chair of IAU-FWG, outlined the procedure to identify a solution in his posting of 1996-07-26 and has asked me to conduct it. Two types of solutions were proposed during the discussion in the sci.astro.fits News group, namely: 1) a new data value string definition for the 'DATExxxx' keywords, or 2) a new set of keywords to replace the 'DATExxxx' ones. The main arguments for and against these proposals can be summarized as follows: 1) New format for 'date value string': Pro: The semantic of all 'DATExxxx' keywords is maintained. It is easy for human readers of FITS headers to understand. Con: Direct conflict with definition of format in basic FITS paper. It may result in wrong values or even failure of readers. Readers must be modified to decode the new format correctly. 2) New set of 'date' keywords: Pro: Any format for the 'value string' can be defined. The semantics can be clearly defined e.g. use of time system. Old readers will not fail or give wrong date. Con: Readers must be modified to use the new keyword correctly. Human readers must learn to interpret the new keyword. For either option, all FITS writers which write DATExxxx keywords will need to be changed, and all FITS readers which interpret DATExxxx keywords will need to be changed. Most comments favored the extended ISO 8601 style format for a new date value string, possibly including its time definition. Thus, the main issue at this point is which of the two options is the better rather than the actual new format. The members of the IAU FITS WG were asked to express their opinion on the two options. The main conclusions were: 1) Both options have a chance to be approved by the IAU FITS WG but option 2 only with great difficulty. 2) There is a preference for maintaining the 'DATExxxx' keywords but with an ISO style data value string. 3) There is some preference to allow the date/time ISO format. The main issue is the less precise definition of many 'DATExxxx' keywords (e.g. DATE-OBS), making it meaningless to specify an exact time. As stated above, any solution will require some code changes. Thus, it is important to know the opinion of the general FITS user community before a final proposal is made. I therefore ask you to answer the following questions: a) Which of the two types of solution would you prefer? 1) a new date value string definition for the 'DATExxxx' keywords 2) a new set of keywords to replace the 'DATExxxx' ones b) Do you have any preference for the new 'date value string'? 1) 'CCYY-MM-DD' e.g. '2123-10-21' 2) 'ISO_STYLE CCYY-MM-DD' e.g. 'ISO_STYLE 2123-10-21' 3) a non-ISO format e.g. '21/10/2123' c) Should a full date/time format (e.g. ISO 8601) be allowed? This is an informal questionnaire which is intended to indicate which options will have the higher chance to succeed. The result will be forwarded to the FITS groups and will thereby help them in their decision process. Please send your answers to these three questions to me with copy to Don before 1996-09-18, so that the results of this poll can be discussed at the ADASS'96 meeting. Best regards, Preben Grosbol From owner-fitsbits at tarsier.cv.nrao.edu Mon Sep 16 13:15:32 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA09087; Mon, 16 Sep 1996 13:15:32 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id MAA08776; Mon, 16 Sep 1996 12:44:54 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id MAA14750 for ; Mon, 16 Sep 1996 12:44:49 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA17055; Mon, 16 Sep 96 12:44:47 EDT To: fitsbits at fits.cv.nrao.edu Date: Fri, 13 Sep 1996 12:24:46 +0100 From: Peter Bunclark Message-Id: <3239447E.5632 at ast.cam.ac.uk> Organization: Royal Greenwich Observatory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!aruba.odu.edu!maui.cc.odu.edu!news.larc.nasa.gov!news.msfc.nasa.gov!newsfeed.internetmci.com!news.mathworks.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news References: <9609091442.AA01312 at primate.cv.nrao.edu> Subject: Re: New release of WCS draft Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Eric Greisen wrote: > > This broadcast is to announce a new version of the paper > describing the coordinates proposal by Mark Calabretta and myself. > The paper is available as wcs.all.ps, wcs.all.ps.Z and wcs.none.ps.Z > (only) from the fits ftp/WWW site (fits.cv.nrao.edu) in the > fits/documents/wcs directory. > > I just pulled and printed it - it looks exactly the same as the document that has been there many months - dated 30.10.1995... Pete. From owner-fitsbits at tarsier.cv.nrao.edu Tue Sep 17 17:26:57 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id RAA21601; Tue, 17 Sep 1996 17:26:57 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id QAA20249; Tue, 17 Sep 1996 16:04:51 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id QAA26705 for ; Tue, 17 Sep 1996 16:04:43 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA15431; Tue, 17 Sep 96 16:04:40 EDT To: fitsbits at fits.cv.nrao.edu Date: Sat, 14 Sep 1996 10:45:55 -0600 From: Jeff Bloch Message-Id: Organization: Los Alamos National Laboratory Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!aruba.odu.edu!maui.cc.odu.edu!news.larc.nasa.gov!news.msfc.nasa.gov!newsfeed.internetmci.com!ncar!newshost.lanl.gov!alexis!jbloch References: <9609091442.AA01312 at primate.cv.nrao.edu> <3239447E.5632 at ast.cam.ac.uk> Subject: Re: New release of WCS draft Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk The version I pulled is dated 9.9.1996 and appears to have differences from previous versions. However, there is something that I would like to see expanded. I restate a plea that I made many months ago. I would like to see more EXPLICIT language in the description of the CSC, QSC, and TSC on how to treat the existence or non-existence of the CUBEFACE axis type. As we understand and use Eric's wcslib software package, it is possible to lay out the whole sky in the "lazy T" configuration in a single plane of the FITS image, not use the CUBEFACE axis type keyword, and the reference pixel will be located at the center of face "1". However, at any valid location on the map, a value for "CUBEFACE" is implied. It is also possible, for compatibility with the COBE convention, to store the six planes of the projection as a data cube with the third axis having the type CUBEFACE. This arrangement is sort of implied in the document, but I am afraid that authors of new software implementing these conventions may not fully appreciate the two ways of dealing with these projections from the description. Here is an in-use example header for a map that does not use the CUBEFACE axis type: SIMPLE = T / Written by IDL: 11-Sep-1996 07:27:32.00 BITPIX = 32 / NAXIS = 2 / NAXIS1 = 1440 / NAXIS2 = 1080 / DATE = '11/09/96' / Creation date (DD/MM/YY) of FITS header CTYPE1 = 'RA---QSC' /COORDINATE TYPE CTYPE2 = 'DEC--QSC' /COORDINATE TYPE EQUINOX = 1996.6948 /ALEXIS MAPS ARE IN CURRENT EPOCH CD001001= 1.0000000 /DEGREES/PIXEL CD002001= 0.0000000 /DEGREES/PIXEL CD001002= 0.0000000 /DEGREES/PIXEL CD002002= 1.0000000 /DEGREES/PIXEL CDELT1 = -0.25000000 / CDELT2 = 0.25000000 / CRPIX1 = 1260.50 /REFERENCE PIXEL IN X CRPIX2 = 540.500 /REFERENCE PIXEL IN Y CRVAL1 = 0.0000000 /R.A. (DEGREES) CRVAL2 = 0.0000000 /DEC (DEGREES) LONGPOLE= 180.000 /LONGITUDE OF POLE (DEGREES) I have placed the complete map as a gziped file called "sample_wcs_qsc.fits.gz" at our anonymous ftp site: nis-ftp.lanl.gov in directory "incoming". Jeff On Fri, 13 Sep 1996, Peter Bunclark wrote: > Eric Greisen wrote: > > > > This broadcast is to announce a new version of the paper > > describing the coordinates proposal by Mark Calabretta and myself. > > The paper is available as wcs.all.ps, wcs.all.ps.Z and wcs.none.ps.Z > > (only) from the fits ftp/WWW site (fits.cv.nrao.edu) in the > > fits/documents/wcs directory. > > > > > > I just pulled and printed it - it looks exactly the same as the document that has been there > many months - dated 30.10.1995... > > Pete. > > -------------------------------------------------------------------------- Jeffrey Bloch Office: (505) 665-2568 Astrophysics and Radiation Measurements Group ALEXIS SOC:(505) 665-5975 Los Alamos National Laboratory FAX: (505) 665-4414 Group NIS-2, Mail Stop D436 e-mail: jbloch at lanl.gov Los Alamos, NM 87545 Digital Pager: (505)665-9800 #104-8074 -------------------------------------------------------------------------- From owner-fitsbits at tarsier.cv.nrao.edu Wed Sep 18 10:25:00 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA26180; Wed, 18 Sep 1996 10:25:00 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id JAA25949; Wed, 18 Sep 1996 09:28:35 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id JAA03792 for ; Wed, 18 Sep 1996 09:28:31 -0400 (EDT) Received: from mc3.hq.eso.org (mc3.hq.eso.org [134.171.8.4]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with ESMTP id JAA06931 for ; Wed, 18 Sep 1996 09:28:28 -0400 (EDT) Received: from ns2.hq.eso.org by mc3.hq.eso.org with ESMTP (8.7.5/ eso-5.3) id PAA22263; Wed, 18 Sep 1996 15:22:41 +0200 (MET DST) Message-Id: <199609181326.PAA11082 at ns2.hq.eso.org> Received: from localhost.hq.eso.org by ns2.hq.eso.org with SMTP (8.7.5/ eso-5.3) id PAA11082; Wed, 18 Sep 1996 15:26:47 +0200 (MET DST) To: fitsbits at fits.cv.nrao.edu Subject: Result of DATExxxx poll Date: Wed, 18 Sep 1996 15:26:46 +0200 From: Preben Grosbol Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Dear Friends of FITS, First of all - thank you to all who took time and participated in the poll on the 'DATExxxx year 2000 issue'. I have merged answers from the IAU FITS WG in to the final result which is as follows: a) Which of the two types of solution would you prefer? 1) a new date value string definition for the 'DATExxxx' keywords 2) a new set of keywords to replace the 'DATExxxx' ones Option 1 : 28 Option 2 : 10 b) Do you have any preference for the new 'date value string'? 1) 'CCYY-MM-DD' e.g. '2123-10-21' 2) 'ISO_STYLE CCYY-MM-DD' e.g. 'ISO_STYLE 2123-10-21' 3) a non-ISO format e.g. '21/10/2123' Option 1 : 30 Option 2 : 5 Option 3 : 4 c) Should a full date/time format (e.g. ISO 8601) be allowed? Yes : 28 No : 5 where answers from 41 persons were received, however, not all answered all questions. This suggests that a detailed proposal for a new 'date value string' for DATExxxx keywords should be made based on the extended ISO-8601 format including an optional specification of time. The results will be very valuable for the FITS committees in their work on the proposal and will be discussed during the ADASS '96 meeting next week. Best regards, Preben Grosbol From owner-fitsbits at tarsier.cv.nrao.edu Wed Sep 18 10:26:42 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA26218; Wed, 18 Sep 1996 10:26:42 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id JAA25959; Wed, 18 Sep 1996 09:29:44 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id JAA03812 for ; Wed, 18 Sep 1996 09:29:40 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA17750; Wed, 18 Sep 96 09:29:38 EDT To: fitsbits at fits.cv.nrao.edu Date: Thu, 12 Sep 1996 12:45:16 -0400 From: Peter Teuben Message-Id: <32383E1C.77F4 at astro.umd.edu> Organization: 301-405-1540; U. of Maryland, Astronomy Dept. Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!news-server.ncren.net!concert!rutgers!news.sgi.com!news.sprintlink.net!news-peer.sprintlink.net!newsfeed.internetmci.com!cpk-news-hub1.bbnplanet.com!news.ums.edu!news.umbc.edu!haven.umd.edu!hecate.umd.edu!news Subject: FITS BoF at upcoming ADASS Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Another FITS BoF (Birds of Feathers) will be organized during the annual (6th) ADASS in Charlottesville, VA (Sept 23-25). We welcome your suggestions for the agenda, particularly from those who are not able to attend. A very tentative agende is as follows: * report of the NOST/FITS Support Office * report of the recent NOST panel meeting * report on the recent year-2000 poll * polling the FITS user community about some possible changes to or establish common FITS practices which should be cast in stone in the NOST paper * overview of the sci.astro.fits traffic * discuss proposed MIME codes for FITS files * new and/or changed software available to process FITS files * WCS: a new version is out! * open discussion Don Wells and Peter Teuben. dwells at nrao.edu teuben at astro.umd.edu From owner-fitsbits at tarsier.cv.nrao.edu Fri Sep 20 09:25:30 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA08818; Fri, 20 Sep 1996 09:25:30 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id GAA08200; Fri, 20 Sep 1996 06:21:45 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id GAA22973 for ; Fri, 20 Sep 1996 06:21:35 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA18568; Fri, 20 Sep 96 06:21:14 EDT To: fitsbits at fits.cv.nrao.edu Date: Mon, 16 Sep 1996 00:15:44 -0500 From: Ray Plante Message-Id: <323CE280.41C6 at ncsa.uiuc.edu> Organization: National Center for Supercomputing Applications Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!news.eecs.umich.edu!news.flint.umich.edu!news.gmi.edu!news.sojourn.com!cancer.vividnet.com!hunter.premier.net!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!vixen.cso.uiuc.edu!usenet Subject: FITSWCS: Java implementation of WCSLIB Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk The FITSWCS Java Package, a translation of Mark Calabretta's WCSLIB into Java, is now available for general use. Like WCSLIB, FITSWCS provides the basic transformations prescribed by the FITS WCS draft by Greisen and Calabretta (ftp://fits.cv.nrao.edu/fits/documents/wcs/wcs.all.ps.Z). The package is available through two distributions. It can be obtained as part of the standard WCSLIB distribution (as of V. 2.4) from the following locations: Australia: ftp://ftp.atnf.csiro.au/pub/software/wcslib/ USA (mirror): http://fits.cv.nrao.edu/src/wcs/ It can be also be obtained by itself from ftp://imagelib.ncsa.uiuc.edu/pub/java. The FITSWCS package was put together as part of Project Horizon (a NASA Cooperative Agreement with the University of Illinois) in cooperation with the NCSA Astronomy Digital Image Library. We are currently developing a generalized Java package for browsing multidimensional scientific data in a variety of formats (including FITS and HDF) origninating from the network or local disk. To find out more about this work, refer to the Horizon Package home page: http://imagelib.ncsa.uiuc.edu/imagelib/Horizon From owner-fitsbits at tarsier.cv.nrao.edu Wed Sep 25 23:21:01 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id XAA24830; Wed, 25 Sep 1996 23:21:01 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id WAA23770; Sun, 22 Sep 1996 22:53:26 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id WAA18979 for ; Sun, 22 Sep 1996 22:53:22 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA25609; Sun, 22 Sep 96 22:53:19 EDT To: fitsbits at fits.cv.nrao.edu Date: 20 Sep 1996 17:20:37 GMT From: davis at space.mit.edu (John E. Davis) Message-Id: Organization: Center for Space Research Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!night.primate.wisc.edu!carbon!csn!nntp-xfer-1.csn.net!news.acsu.buffalo.edu!newsstand.cit.cornell.edu!portc01.blue.aol.com!news-res.gsl.net!news.gsl.net!news-peer.gsl.net!news.gsl.net!news.mathworks.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!davis Reply-To: davis at space.mit.edu Subject: A question about integer valued header keywords Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk What is the precision of an integer in the header? I have not seen this question addressed anywhere in the fits documentation. I am concerned because the C Fitsio library defines the function `ffpkyj' which is prototyped int ffpkyj(fitsfile *fptr, char *keyname, long value, char *comm, int *status); The problem with this is that `long' is system dependent: sizeof(long) == 4 on a 32 bit system and sizeof(long) == 8 on a 64 bit system. This means that I could easily create a fits file on a 64 bit system that cannot be correctly parsed on a 32 bit system. -- John E. Davis Center for Space Research/AXAF Science Center 617-258-8119 MIT 37-662c, Cambridge, MA 02139 http://space.mit.edu/~davis From owner-fitsbits at tarsier.cv.nrao.edu Wed Sep 25 23:21:47 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id XAA24842; Wed, 25 Sep 1996 23:21:47 -0400 Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id AAA23972; Mon, 23 Sep 1996 00:24:00 -0400 Received: from crux.rp.CSIRO.AU (crux.rp.CSIRO.AU [130.155.194.32]) by cv3.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id AAA23015 for ; Mon, 23 Sep 1996 00:23:31 -0400 (EDT) Received: from grus.atnf.CSIRO.AU (grus.atnf.CSIRO.AU [130.155.194.37]) by crux.rp.CSIRO.AU (8.6.10/8.6.10) with ESMTP id OAA04943 for ; Mon, 23 Sep 1996 14:23:06 +1000 Received: from grus.atnf.CSIRO.AU (localhost [127.0.0.1]) by grus.atnf.CSIRO.AU (8.6.12/8.6.12) with ESMTP id OAA13049 for ; Mon, 23 Sep 1996 14:23:04 +1000 Message-Id: <199609230423.OAA13049 at grus.atnf.CSIRO.AU> To: fitsbits at nrao.edu Subject: WCSLIB 2.4 Date: Mon, 23 Sep 1996 14:23:03 +1000 From: Mark Calabretta Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk WCSLIB 2.4 is now available. This version was produced mainly in order to bundle in Ray Plante's Java implementation announced earlier on this exploder. However, there were a couple of bug fixes as listed below. Australia: ftp://ftp.atnf.csiro.au/pub/software/wcslib/ USA (mirror): http://fits.cv.nrao.edu/src/wcs/ Mark Calabretta ATNF >>>>> C library >>>>> WCSLIB version 2.4 ------------------ * In sinrev(), cscrev(), qscrev(), and tscrev(), return error 2 if (x,y) do not lie within the perimeter of the projection. In sinrev(), stop the computation of phi for the "synthesis" projection being applied to the pure "orthographic" case. Reported by David Berry (dsb at ast.man.ac.uk). * (Internal change) Renamed variables l <-> m in the quadcube projections to accord with standard usage (and revised WCS draft paper). >>>>> FORTRAN library >>>>> WCSLIB version 2.4 ------------------ * In SINREV, CSCREV, QSCREV, and TSCREV, return error 2 if (X,Y) do not lie within the perimeter of the projection. In SINREV, stop the computation of PHI for the "synthesis" projection being applied to the pure "orthographic" case. Reported by David Berry (dsb at ast.man.ac.uk). * (Internal change) Renamed variables L <-> M in the quadcube projections to accord with standard usage (and revised WCS draft paper). * (Internal change) Stopped PRJ(11) doing double service in any projection. It is now set and tested for a specific magic value rather than simply being non-zero. From owner-fitsbits at tarsier.cv.nrao.edu Thu Sep 26 13:50:40 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id NAA32187; Thu, 26 Sep 1996 13:50:40 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id FAA28650; Thu, 26 Sep 1996 05:51:38 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id FAA21594 for ; Thu, 26 Sep 1996 05:51:29 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA00505; Thu, 26 Sep 96 05:51:25 EDT To: fitsbits at fits.cv.nrao.edu Date: 24 Sep 1996 09:35 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <24SEP199609354981 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!uwm.edu!nntp.primenet.com!news.sgi.com!enews.sgi.com!ames!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger References: Subject: Re: A question about integer valued header keywords Newsgroups: sci.astro.fits Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk In article , davis at space.mit.edu writes... > What is the precision of an integer in the header? I have not seen >this question addressed anywhere in the fits documentation. I am >concerned because the C Fitsio library defines the function `ffpkyj' >which is prototyped > >int ffpkyj(fitsfile *fptr, char *keyname, long value, char *comm, int *status); > >The problem with this is that `long' is system dependent: >... I could easily create a fits file on a 64 bit system that >cannot be correctly parsed on a 32 bit system. >-- An integer keyword value in the header is the ASCII representation of an integer, using hexadecimal characters 30-39. Conversion to an integer type for processing is a matter for software, and details of the process are not specified. To read the FITS file properly, any conversion of integer keyword values in a file to integer form must contain enough bits to express the integers in that file. The use of a C long type to contain the value of a keyword is a FITSIO design decision and not specified by the rules of FITS. Barry Schlesinger FITS Support Office GSFC/ADF From owner-fitsbits at tarsier.cv.nrao.edu Sat Sep 28 11:34:32 1996 Received: (from majdom at localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA21644; Sat, 28 Sep 1996 11:34:32 -0400 Received: from fits.cv.nrao.edu (fits.cv.nrao.edu [192.33.115.8]) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) with ESMTP id KAA21328; Sat, 28 Sep 1996 10:51:55 -0400 Received: from solitaire.cv.nrao.edu (news at solitaire.cv.nrao.edu [192.33.115.79]) by fits.cv.nrao.edu (8.7.5/8.7.1/CV-2.1) with SMTP id KAA13892 for ; Sat, 28 Sep 1996 10:51:51 -0400 (EDT) Received: by solitaire.cv.nrao.edu (4.1/DDN-CV/1.10) id AA09932; Sat, 28 Sep 96 10:51:47 EDT To: fitsbits at fits.cv.nrao.edu Date: 25 Sep 1996 15:49 EDT From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger) Message-Id: <25SEP199615491513 at nssdca.gsfc.nasa.gov> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Path: solitaire.cv.nrao.edu!hearst.acc.Virginia.EDU!uunet!in1.uu.net!news.sgi.com!news-peer.gsl.net!news.gsl.net!usenet.eel.ufl.edu!usenet.cise.ufl.edu!purdue!haven.umd.edu!cs.umd.edu!newsfeed.gsfc.nasa.gov!nssdca.gsfc.nasa.gov!bschlesinger Reply-To: fits at nssdca.gsfc.nasa.gov Subject: Sources of FITS Information Newsgroups: sci.astro.fits,sci.answers,news.answers Sender: owner-fitsbits at tarsier.cv.nrao.edu Precedence: bulk Archive-name: astronomy/fits/info-sources Last-modified: 1996/09/25 -------- Sources of FITS Information Preface This material on sources of Flexible Image Transport System (FITS) information is posted and updated periodically by the FITS Support Office at the NASA Goddard Space Flight Center (GSFC). It discusses where general FITS information, including some answers to frequently asked questions, can be found, and provides sources for detailed information on FITS software and documentation. ------- FITS Support Office The FITS Support Office maintains a library of FITS information accessible from http://ssdoo.gsfc.nasa.gov/astro/fits/fits_home.html or ftp://nssdc.gsfc.nasa.gov/pub/fits/. The material available includes o "Definition of FITS," a codification of FITS for the NASA/Science Office of Standards and Technology (NOST), available in LaTeX, uncompressed PostScript, compressed PostScript and (usually) ASCII text (The ASCII text version may not be available for a short while after the announcement of a new version.) o "A User's Guide to FITS", published by the FITS Support Office, in LaTeX, and compressed and uncompressed PostScript o Revisions to version 1.0 of the "Definition of FITS" covering the specification of units that were incorporated into version 1.1 (text) o A current list of the extension type (structure) names registered with the International Astronomical Union FITS Working Group (IAUFWG) (text) o Rules for physical blocking on various media adopted by the IAUFWG (text) In the same directory but accessible directly via http://ssdoo.gsfc.nasa.gov/astro/fits/basics_info.html is the FITS Basics and Information that used to be regularly posted to sci.astro.fits and sci.data.formats. It continues to be revised to reflect current FITS developments. It contains the following material: o An overview of FITS o A list of FITS documents o A list of software packages that support FITS, including FITS <--> image converters for various platforms o A list of on-line FITS resources o A description of the FITS Support Office The hypertext version provides links to many of the documents, software, and network locations listed. The text version provides information on how to obtain much of this material. There is also a hypertext version of the List of Registered Extensions. Links from the Web page and subdirectories of the ftp directory contain o Software developed by the FITS Support Office. o Error test files: primary HDUs useful for testing the ability of software designed to read FITS files to cope with files that have errors or are non-standard. These files should be downloaded in binary form. Printed copies of the material in the FITS directory can be obtained from the Coordinated Request and User Support Office (CRUSO): (Postal) Coordinated Request and User Support Office Code 633 National Space Science Data Center NASA Goddard Space Flight Center Greenbelt MD 20771 USA (Electronic mail) request at nssdca.gsfc.nasa.gov (Telephone) +1-301-286-6695 8:00 A. M. - 4:30 P.M. U. S. Eastern Time (-0500 from the last Sunday in October through the first Saturday in April; -0400 the remainder of the year) When no one is available, messages can be left on voice mail. (FAX) +1-301-286-1635 ------- National Radio Astronomy Observatory (NRAO) A FITS Archive can be found at URL http://fits.cv.nrao.edu/ or at ftp://fits.cv.nrao.edu/fits, located at NRAO. This machine supports a WAIS server named nrao-fits which has an index of all of the FITS-related text files in the archive; the file nrao-fits.src is available at think.com and at ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src. Some of the more noteworthy materials in this archive are o Drafts of proposed additions to the FITS standard and other drafts that may in the future be formally proposed o Text of any detailed proposals currently being discussed by the FITS committees o A collection of documents on World Coordinate Systems, including the current draft proposal o Conventions specific to particular projects or disciplines o Software for various environments and Usenet postings about code o Sample data and special test files designed to measure the ability of a FITS reader to handle a wide variety of FITS files o Archives of traffic on FITS-related newsgroups and exploders A separate NRAO site, http://www.cv.nrao.edu/~bcotton/fitsview.html, provides information on the FITSview family of software packages for display of FITS images on Microsoft Windows 3.1 and Windows 95, Apple Macintosh, and Unix/X-Windows, with links to the software. It also links to a number of sources of astronomical FITS images. ------- HEASARC The NASA/Goddard High Energy Astrophysics Science Archive Research Center (HEASARC) Web server at http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html and the anonymous ftp access through ftp://heasarc.gsfc.nasa.gov/fits_info/ provide FITS material. HEASARC has developed the FITSIO package of software routines for easily reading and writing FITS files, with FORTRAN and C versions available, portable to a wide variety of machines. There is also the FTOOLS collection of software tools and the VERIFITS FITS conformance verifier. HEASARC software is available directly through http://heasarc.gsfc.nasa.gov/docs/heasarc/tech_res_software.html or ftp://heasarc.gsfc.nasa.gov/fits_info/software/ . The HEASARC server also provides information from the HEASARC FITS Working Group, (HFWG) the internal legislative body on FITS-related matters within the Office of Guest Investigator Programs (OGIP) at NASA/GSFC, at http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_intro.html or at ftp://heasarc.gsfc.nasa.gov/fits_info/ in the directories ofwg_minutes and ofwg_recomm. The HFWG has developed a number of FITS conventions that are more specific than the requirements of the FITS standards. Proposed conventions are publicized to the FITS community as a whole, with the goal of collaborative development of a set of conventions that will be accepted throughout the community as well as within OGIP/HEASARC. ------- Direct questions about this posting to Barry M. Schlesinger Coordinator, FITS Support Office Electronic mail: fits at nssdca.gsfc.nasa.gov Telephone: +1-301-441-4205 The FITS Support Office is operated under the guidance of the NASA/GSFC Astrophysics Data Facility.