Re: FITS tables, "airmass", and redundant data

[hjohnson@pluto.njcc.com (Herbert R Johnson)]

Jure Skvarc suggested in his summary that a value for AIRMASS be
determined and reported in some fashion. While I have no credentials
as a professional astronomer, I do have experience as an amateur who
observes in less-than-photometric skies - the same skies that many
TASS cameras will be observing through. The effects of airmass with
azimuth angle, as Richmond reported upon by the numbers, are a simplified
model presuming a uniform, stable sky and atmosphere. Whereas actual
skies are turbulent and have warm and cold fronts, etc. etc. Consequently,
the only value that a TASS camera can report reliably is the "actual" angle
of the camera, the asimuth angle. The extent to which this value can
be used to compute an air mass correction can be determined by those
who reduce the data.

Further considerations of this sort
suggest to me that reporting (slightly different) angles for each camera
may not be necessary, if the relative angle between the camera is modest.
I simply don't recall the mount's features at this time, or (worse)
if the cameras can be reoriented upon the mount. If they are reasonably
parallel (a judgement call) then one azimuth value can be used for
BOTH cameras. If not, then perhaps a value for an arbitrary point can
be reported that would be adequate for most positions of the mount.
(Tom or Arne can best respond to this point.) It would otherwise be
a bit of a calculation to know where EACH camera is pointed, given
the mount position of the RA and DEC encoders and some 3-d model of
the cameras on the mount. (In the end, Chris and other controller software
developers would implement this, so it's their call.)
 
As has been pointed out, if one knows time and geographic position,
and the field of view, then one can make an arbitrarily exact calculation
of azimuth. Given that, a reported value for the mount's azimuth
would still be a "reality check" for such calculations. Or, possibly,
the value would suggest that the location reported for the camera is wrong,
or the time reported is wrong. This leads me to my second point.


A second consideration in discussion, as reported by Jure, seems to me
to be the issue of REDUNDANCY. There is some suggestion that if a datum
is redundantly reported, that datum should NOT be reported. I would take
the opposite view. If you have a cross-check datum for other data, LEAVE
IT IN. As Mark III use revealed, any number of things can go wrong during
observations. Typically the computer's clock is wrong. I can imagine a
camera could use the wrong data files and report the wrong location.
And so on. Redundant data can at least IDENTIFY an error exists, if
not provide a DIAGNOSTIC as to the source of error. Also, I think
there is a false sense of "economy" in removing redundant data. With
8 MB per image, and presumably the order of 100KB of starlists per image,
tens of bytes of "extra" header is a non-issue. While economy is important
in each record of the starlists - no sense in reporting the same time
for every star - it is less important in the FITS header which occurs
once per file.

Herb Johnson


Herbert R. Johnson              http://pluto.njcc.com/~hjohnson
hjohnson@pluto.njcc.com         voice 609-771-1503, New Jersey USA
             amateur astronomer and astro-tour guide
           S-100 computer parts, manuals as "Dr. S-100"
    reseller of 68K Macs & accessories for your computing pleasure