[fitsbits] Start of the FITS-IDI Convention Comment Period
William Pence
the FITS Interferometry Data Interchange (FITS-IDI) Convention for the
interchange of data recorded by interferometric telescopes, particularly
at radio frequencies and very long baselines. This is the 16th in a
growing series of conventions submitted to the Registry which is
maintained by the IAU FITS Working Group.
Detailed information about this convention and a sample FITS file that
uses it are available for public review and comment from the FITS
registry web page at
http://fits.gsfc.nasa.gov/fits_registry.html
Comments about this convention may be posted here on the FITSBITS mail
exploder or the mirrored sci.astro.fits newsgroup. Minor typographical
issues may be sent directly to the authors of the convention.
Bill Pence
(on behalf of the IAU FITS Working Group)
--
____________________________________________________________________
Dr. William Pence pe...@milkyway.gsfc.nasa.gov
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)
Harro Verkouter
Hi all,
After reading through the document I'd like to make a few comments.
Some of those apply to the implementation of the/a reader, nonetheless
they seem to indicate incompatibility between documentation and
practical use-cases. This is written from the perspective of the EVN
FITS-IDI data-export software, which has been implemented exactly
following the Flatters(1999) document [and thereby finding
discrepancies between documentation and implementation].
* I have noticed that in most cases the order in which the keywords
are written (also the non-mandatory FITS keywords) may have to be
identical as in the documentation or else your FITS-IDI file may be
rejected. I do not know if this situation has changed over the last
few years, I did not experiment with writing keywords "out-of-order"
since finding out that it most likely 'breaks' your FITS-IDI file.
* The "SORT" optional keyword to the UV_TABLE header (p.15) does not
seem to get honoured. Our FITS-writer writes the hard-coded value
"TB" (Time-Baseline) since that is the order in which the data is
forcibly written, nonetheless it is never recognized by the reader,
making the user have to run uvsort (or wossname of the task) to make
the data recognized as being sorted in TB order. It may well be that
this behaviour is triggered by our FITS-writer doing something else
wrong however it is not documented - making it quite unfixable yet.
* I'm glad to see the POLARX/Y situation being somewhat resolved. I
beg to differ, however, from the statement in the document "The units
were changed from the meters specified by the earlier documents, but
seldom used in actual implementations.". Especially since it is
exactly this early misdocumentation (documentation says "meters", s/w
interprets them as "arcseconds") that has caused many of our users
headaches (EVN data).
Cheers,
harro verkouter
> _______________________________________________
> fitsbits mailing list
> fits...@listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
Eric Greisen
I think all of these comments apply to the implementation of the AIPS
task FITLD rather than to the IDI convention itself. I hope that I have
fixed the earlier versions of FITLD so that the columns may now occur in
any order. I just tested it and the SORT values are honored - but note
that 'T*' is changed by FITLD to 'TB' or to '**' if unsorted data are
found. Leonia Kogan has studied the POLARX/Y question and determined
that the software can, for data within the last 30 years, tell which
units were used. AIPS has been corrected to make that test and enforce
the new (and usual) convention.
A question was raised outside this forum about adding PULSAR BIN as an
optional UV data axis. I have not added that to the document since its
support would force much labor on my part for aips and other software
people as well. Until there are users who promise to use it, I am
inclined to stay away from that addition.
Cheers,
Eric Greisen