HDTenEightyP/NetNews huggingface dataset:
From: palmer@sfu.ca (Leigh Palmer)
Subject: Re: Okay, what are the new odds? (was Re: Swift_tuttle's orbit)
Organization: Simon Fraser University
Date: Fri, 13 Nov 1992 20:07:48 GMT

In article <1992Nov12.130524.1@fnalo.fnal.gov> higgins@fnalo.fnal.gov (Bill
Higgins-- Beam Jockey) wants to know what the odds are on being hit by
P/Swift-Tuttle on the next pass through in 2126. I'm pleased to report that I
can answer that question definitively. I have decided to accept bets from
people who wish to back the possibility of a devastating collision in that
year, and I will offer Brian Marsden's 10,000 to one odds, straight up! If you
buy a chit from me now for, say, $100, then I'll pay you $1,000,100 in 2126 if
the comet strikes the Earth.

You may say "That Palmer is a chisler!"

People often say that; *you* may.

"If the comet hits the Earth he won't be around, nor will I."

Well, I want to tell you that is not the case. I plan to invest the $100 in
long term notes, for which I can easily get the 7 percent interest rate I will
need if the comet hits, and I (or my heirs) have to pay off. Otherwise I'll
keep the million bucks! It might buy a nice dinner out for my great
grandchildren by that time. Perhaps they'll even take me along, at age 191. In
case technological intervention averts the disaster then all bets are off; you
get you hundred bucks back.

It is now *officially* the case that the odds on P/Swift-Tuttle hitting Earth
in 2126 are 10,000 to one.

Oh, yes; if you've decided to bet *against* the comet hitting, I'll take that
one, too, at even money. ;-))

Leigh
Newsgroups: sci.astro
From: stone@cwis.unomaha.edu (Travis Stone)
Subject: Re: Kepler's Mom Not Burned...
Keywords: There's Nothing Like a Good Leg of Mom
Organization: University of Nebraska at Omaha
Date: Mon, 9 Nov 1992 18:49:20 GMT



It is absolutely correct that Old Lady Kepler was spared an
appearance at the local Sizzler, due in large to the "hated
mathematicus, Johannes Kepler"; if you want to read more
about it, check out Arthur Koestler's book "The Watershed: A
Biography of Johannes Kepler."

It's a good read.

T.R. Stone
Yoyodyne Propulsion Systems, Inc.
"I'm-a going-a home, Monkey Boy!"
               ---Lord John Whorfin
Newsgroups: sci.astro
From: wa2ise@cbnewsb.cb.att.com (robert.f.casey)
Subject: I can't see stars anymore at night with naked eye
Organization: AT&T
Date: Sat, 14 Nov 1992 03:12:07 GMT

I haven't seen any stars at all for the past several months at night.
I'm in a badly light polluted area (New Jersey, 20 miles west of NYC),
but I used to be able to see 1st and 2nd magnitude stars.  Now, nothing.
I still can see the Moon and the Sun, but that's it.  I don't think
the light pollution got much worse.  Maybe a volcano (Mt Pinatibu(sp)
threw enough junk into the upper atmosphere to make the light pollution
look worse?  Also noticed that the sky around the last full Moon looked
more lit up than usual, and looked a bit blue at night.
From: j.jahn@abbs.hanse.de (Jost Jahn)
Newsgroups: sci.astro
Subject: Sunspots at 08.11.1992.
Reply-To: j.jahn@abbs.hanse.de
Date: 08 Nov 92 13:23:00 MET
Distribution: sci
Organization: ABBS AstroMail, D-W 2121 Dahlenburg / Germany
X-Version: ZerUU V6.45c

Sunspots at 08.11.1992., 0 h UT.

No.    Pos.  Cl.  Ar.  Mag. SF  F  M  X
---------------------------------------
7325 17S 78W Hsx   40   a
7326 07S 88W Hsx   50   a
7330 08S 10W Dki  460   bg   1
7332 23S 68W Dao  120   b
7334 13N 47E Dao  220   b
7335 17S 50E Dao  380   b    2


No optical or x-ray flares yesterday observed.


 
--
------------------------------------------------------------------------------
ABBS AstroMail, the first and most popular German astronomical bulletin board
------------------------- for amateur astronomers ----------------------------
    + 49 5851 7896 / V.21, V.22, V.22bis, V.32, V.42, V.42bis and MNP5
    ------------------------------------------------------------------


Newsgroups: sci.astro
From: stone@cwis.unomaha.edu (Travis Stone)
Subject: Good Book for Orbit Determination...
Keywords: Not Too Shabby
Organization: University of Nebraska at Omaha
Date: Mon, 9 Nov 1992 18:41:50 GMT




To one and all:

A fairly good book on orbit determination is

"Methods of Orbit Determination" by Pedro Escobal,
New York, J. Wiley[1965].

Has lots of examples, lots of exercises, and answers to some
in the back.

T.R. Stone
Yoyodyne Propulsion Systems, Inc.
Lord John Whorfin, President
John Big-Boote~, Ex-V.P.
John O'Connor, C.E.O.
John Small Berries, Chief of Security
Newsgroups: sci.astro.fits
From: dbriggs@zia.aoc.nrao.edu (Daniel Briggs)
Subject: Re: World Coordinate Systems
Organization: National Radio Astronomy Observatory, Socorro NM
Date: Wed, 11 Nov 92 11:38:55 GMT

In article <9211101358.AA01257@primate.cv.nrao.edu>
  egreisen@primate.CV.NRAO.EDU (Eric Greisen) writes:
>The method that has been used since day 1 in FITS is to specify 3 axes with
>only 1 pixel on the third axis.

Yes, but in some situations this has proved an unfortunate choice.  I've
never been happy with the practice of stuffing additional information about
the image into 1 pixel pseudo-axes.  In the case of a spectral instrument,
one might plausibly make the argument that the fundamental data is really
an M x N x 1 cube, but to stuff things like Fourier transform axis
conjugation information in as pseudo-axes is really deplorable.  To make
things more concrete, suppose that I have a set of matrix routines in my
favorite imaging package, and that I'd like it to operate on the arbitrary
contents of a FITS image.  In such a case, it really does make a difference
whether there are 1 or 2 "real" dimensions.  Is it a one dimensional image
that should be treated as a vector, (but with some number of pseudo axes
following it), or is it a two dimensional image that merely happens to have
one pixel in the second dimension?  As it stands now, there is really no
way to tell, without building in a list of recognized axis types.  I've
always felt that in an ideal world NAXIS would represent the true
dimensionality of the data, not simply the number of entries in the
coordinate arrays.  Or perhaps the other way around, and we could have an
RNAXIS keyword to hold the real number of axes.  It's not a major problem,
and I'm not seriously suggesting the above as a fix, but in a few cases I
have had to make some real kludges to get around this problem.

-- 
| Daniel Briggs  (dbriggs@nrao.edu)                      |  USPA B-14993
| New Mexico Tech / National Radio Astronomy Observatory |      DoD #387
| P.O. Box O / Socorro, NM 87801   (505) 835-7391        | 
Support the League for Programming Freedom   (info from lpf@uunet.uu.net)
Newsgroups: sci.astro.fits
From: dwells@fits.cv.nrao.edu (Don Wells)
Subject: World Coordinate System proposal
Organization: nrao
Distribution: sci
Date: Fri, 6 Nov 1992 00:00:43 GMT

A special session was held on FITS WCS [World Coordinate System]
issues yesterday at the ADASS-92 meeting in Boston. The session was
well attended, and it was clear that there is considerable interest in
defining and implementing interoperable WCS implementations.  Bob
Hanisch distributed copies of a paper which he and I prepared in
February 1988. This paper documented the conclusions reached during a
WCS workshop held in Charlottesville in January 1988; it should be the
starting point for a new round of discussions of WCS issues. Anyone
who was not in the WCS session yesterday and who wants a copy of the
paper will find it in the anonymous-FTP server fits.cv.nrao.edu
[192.33.115.8] in directory /FITS/Documents:

     101705 Nov  5 10:12 FITS_wcs88.ps
      21856 Nov  5 10:07 FITS_wcs88.tex
--

Donald C. Wells             Associate Scientist        dwells@nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N 
Newsgroups: sci.astro.fits
From: egreisen@primate.CV.NRAO.EDU (Eric Greisen)
Subject: World Coordinates Proposal
Organization: National Radio Astronomy Observatory
Date: Sat, 7 Nov 1992 21:47:56 GMT

The current tempest over this question illustrates why the initial design of
FITS deliberately remained silent on coordinates questions.  It is my hope
that I can codify and clarify the coordinates that have been in wide use in the
FITS community and produce a proposal.  In the mean time, I feel I am forced
to address this question:

Steve Allen writes

>>The question boils down to another question:  Are FITS images representing
>>binned data or sampled data?  How do you tell?

Robert Hanisch replies:

> This issue was discussed during the meeting in Boston, and it was agreed
> that the proposal has to be revised to indicate the conventions being
> used.  The consensus was that for FITS, pixel (1,1) is the pixel in the lower
> left-hand corner of an image and that for the purpose of the WCS, this
> pixel represents data from 0.5 to 1.5 in pixel coordinates.  This clarification
> will be added to the proposal.

Let me add my agreement.  There is only one unique location in an N-dimensional
voxel, its center in each of the N dimensions.  This has always been the intent
of CRPIXmmm in the FITS design.  I do not understand how that decides one way or
the other whether the data are sampled or binned - that is a separate question
with an instrument-dependent answer.

I disagree that FITS pixel (1,1) represents the "lower left-hand" of anything.
(1,1) is the first pixel value in a Fortran-array sense.  Where it is placed
in a display depends on many things such as the sign of the coordinate
increments and the like.  If you send AIPS an image with a negative increment
on the declination axis, it will display the image with (1,1) at the upper
left corner, for example.

Steve Allen writes

> This is significantly different from the common practice in computer graphics
> (CG) where the first pixel in an array is the pixel with
> the integer tag 0 which has floating point boundaries 0.0 and 1.0
> (edges of pixel are integral).

Mostly computer graphics ignores pixels and plots the whole universe - or its
current instanciation - from 0.0 to 1.0.  You are then defining coordinates
to be at the upper side of the pixel since FITS does define the first pixel
to be pixel number 1.  Is that any more unique than the lower side?  Only the
center is unique.  The coordinates given in CRVALnnn are at the center of pixel
CRPIXnnn.  Of course - things like this may explain some of the complaints
about VLA positions and discrepancies between positions from various
observatories.

Eric W. Greisen
egreisen@nrao.edu
From: sla@umbra.UCSC.EDU (Steve Allen)
Newsgroups: sci.astro.fits
Subject: Re: World Coordinate System proposal
Summary: document this very clearly
Keywords: pixel boundaries, common practice
Date: 6 Nov 92 23:30:21 GMT
Organization: UCO/Lick Observatory
NNTP-Posting-Host: umbra.ucsc.edu

In article <1992Nov6.221211.9536@stsci.edu> hanisch@stsci.edu writes:
>In article 1deo6pINNlj9@darkstar.UCSC.EDU, sla@umbra.UCSC.EDU (Steve Allen) writes:
>>
>>The question boils down to another question:  Are FITS images representing
>>binned data or sampled data?  How do you tell?
>
>This issue was discussed during the meeting in Boston, and it was agreed
>that the proposal has to be revised to indicate the conventions being
>used.  The consensus was that for FITS, pixel (1,1) is the pixel in the lower
>left-hand corner of an image and that for the purpose of the WCS, this
>pixel represents data from 0.5 to 1.5 in pixel coordinates.  This clarification
>will be added to the proposal.

It will be very important to add this clarification.

From my experience I infer that the astronomical community has
pretty much established that the first pixel in an array is the pixel with
the integer tag 1 which has floating point boundaries 0.5 and 1.5
(middle of pixel is integral).

This is significantly different from the common practice in computer graphics
(CG) where the first pixel in an array is the pixel with
the integer tag 0 which has floating point boundaries 0.0 and 1.0
(edges of pixel are integral).

If the astronomical community will be variant in this way it will be
essential to clearly document the definition of a pixel.  There will
undoubtedly be some astronomical programmers who cling to the more widely
used CG definitions of pixels, and interoperation of their software with
other software will be difficult if these underlying assumptions are not
made explicit in the documentation.
_______________________________________________________________________________
Steve Allen          | That was the equation!         |   sla@lick.ucsc.edu
UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me.
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Newsgroups: sci.astro.fits
Subject: Re: World Coordinate Systems
Date: 10 Nov 92 17:31:00 GMT
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1

In article <9211101358.AA01257@primate.cv.nrao.edu>, egreisen@primate.CV.NRAO.EDU (Eric Greisen) writes...

	(stuff deleted)

>Again, this is intended to be a convention for celestial coordinates primarily,
>although it suggests a convention that one might wish to use in other areas.
>AIPS will handle any string in CTYPEn, but if that string is not of a recognizable
>type then AIPS will assume that the axis is linear in the coordinate, plot it as
>such, and label it with the value of the CTYPEn string.  It seems to me that this
>is a reasonable compromise ...

Sounds quite reasonable to me too, and addresses my concerns in this area.

Eric Greisen also writes ...

>I applaud the first usage (partly) and deplore the second.  The whole reason for
>having very general and defined keywords was to attempt to convey information
>between sites (and over time) without having to have special codes for every
>2-party connections.  The first usage allows a general program to make some sense
>of the information provides, the second usage simply gets dumped to history files
>and ignored.  The "(partly)" above is from my guess that you could in fact provide
>us with useful celestial coordinate information instead and thereby allow scientists
>to compare your imagery with those generated by other instruments.

Could you clarify what you mean by "first" and "second".  I'm unsure about what
you're getting at here.

In terms of "useful celestial coordinate" information, our plan is to provide
the data in raw units, and in the coordinate system the data was actually taken
in.  The data needed to convert this into useful coordinates and scientific
units will also be included, but not applied.  Our feeling is that the
calibration is a fluid thing, and that our understanding will change over time.
The calibration information stored in the file will probably only represent a
first quess.  We will distribute the calibration data separately, which can be
more easily updated.

Eric Greisen goes on to say ...

>This usage is quite old actually.  It was first described in writing by me in
>April 1983 and has been used on the 1000's of VLA images ever since.  It was picked
>up and used by many other sites over the years and the draft proposal you have
>read was dated in 1988.  I am engaged as we speak in converting the old papers to
>LaTeX so that they can be re-released in a modern form.  I intend also to review
>the proposal and flesh it out with better details. ...

By "new", I mean that it is not discussed within the confines of the FITS
standard document.  I'm surprised that you decided to add new functionality
within a pre-existing structure.  Future enhancements to the standard should
avoid this trap.

Bill Thompson
Newsgroups: sci.astro.fits
From: jjb@beta.lanl.gov (Jeffrey J Bloch)
Subject:  World Coordinate Systems standard for All-sky data
Organization: Los Alamos National Laboratory
Date: Sun, 8 Nov 1992 14:11:49 GMT

Newsgroups: sci.fits.astro
Subject: World Coordinate Systems standard for All-sky data
Summary: 
Followup-To: 
Distribution: world
Organization: Los Alamos National Laboratory
Keywords: 

At the ADASS BOF session on World Coordinate Systems, I volunteered to
gather input for Bob Hanisch on the problem of dealing with all-sky data
in the WCS context, namely things such as Hammer-Aitoff maps, Quad Cube
maps, Equal Area Polar (Lambert) maps. For those of us dealing with
generating and distributing all-sky data of moderate resolution and having
existing packages treat these data properly is a real problem. ROSAT, COBE,
GRO, EUVE, and in our case ALEXIS, will all be generating maps covering large
sections of the sky with moderate resolution and demanding some type of
equal area projections. The diffuse X-ray all sky maps from ROSAT will
be generated in equal area polar projections according to Steve Snowden
at MPE. The COBE folks seem to be going with Quad Cube maps. For the
EUV maps generated with the ALEXIS experiment, we are experimenting also
with Quad Cube, and EUVE is using Quad Cube. Neither Lambert or Quad cube
is in the current WCS stanard, and the hooks for dealing with these types
of data may not be there either, or may need some re-interpretation when
dealing with maps of these types. I will be pulsing the people I know on
these projects about their preferences and try to put a proposal for dealing
with these all-sky maps onto this newsgroup in the comming weeks. Please
send me any of your own thoughts on the subject as well.

						Cheers,
						Jeff Bloch
						Astrophysics and Radiation
							Measurement Group
						Los Alamos National Laboratory
						(505)665-2568
						SPAN: ESSDP2::103283
						Internet: 103283@sstdp2.lanl.gov
						      or: jbloch@alexis.lanl.gov

Newsgroups: sci.astro.fits
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Subject: World Coordinates
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
Date: Mon, 9 Nov 1992 22:29:00 GMT

After having read the world coordinates proposal, I am still unclear as to how
the developers would describe this very simple problem:

	Given: A slit spectrograph with a single pointing position.  The
	dimensions of the data are two: one spatial coordinate and one
	spectral coordinate.  However, to describe the pointing, two
	spatial coordinates are needed, as well as the orientation of
	the slit, and the spectral dispersion and central wavelength.
	In other words, the data has only two dimensions, but it takes
	three dimensions to properly describe it.

Secondly, it appears that this convention is only relevant to skymapped
data--which I admit applies to most astronomical data.  However, it's hard to
see the relevance to solar images, for example.

Bill Thompson
Newsgroups: sci.astro.fits
From: hanisch@stsci.edu (Bob Hanisch, ST ScI)
Subject: Re: World Coordinates
Reply-To: hanisch@stsci.edu
Organization: Space Telescope Science Institute, Baltimore MD
Date: Tue, 10 Nov 1992 14:47:36 GMT

In article 9NOV199218295135@stars.gsfc.nasa.gov, thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040) writes:
>After having read the world coordinates proposal, I am still unclear as to how
>the developers would describe this very simple problem:
>
>	Given: A slit spectrograph with a single pointing position.  The
>	dimensions of the data are two: one spatial coordinate and one
>	spectral coordinate.  However, to describe the pointing, two
>	spatial coordinates are needed, as well as the orientation of
>	the slit, and the spectral dispersion and central wavelength.
>	In other words, the data has only two dimensions, but it takes
>	three dimensions to properly describe it.
>
>Secondly, it appears that this convention is only relevant to skymapped
>data--which I admit applies to most astronomical data.  However, it's hard to
>see the relevance to solar images, for example.
>
>Bill Thompson

The title of the draft probably should have been more restrictive, i.e.,
"Representation of Sky Projection Coordinate Systems Within FITS" or something
like that.  At the WCS meeting in Charlottesville in 1988 we decided to tackle
this problem first, and that was again agreed upon at the Boston meeting last
week.  The example cited above is actually not so simple, since things are
rarely this straightforward.  The dispersion axis is usually not perpendicular
to the spatial axis, and indeed is usually curved.  The dispersion relation 
itself is frequently nonlinear.  The simple case described above CAN be
handled within FITS, and is supported within a number of systems (e.g., radio 
data cubes are really the same thing -- the dispersion axis is usually the 
third axis, but this need not be the case).

At the Boston meeting there were volunteers to work on adding solar and
planetary coordinate systems to the draft.  If you are interested in
participating in this effort, please contact Winnifred Williams at NOAO
(wwilliams@noao.edu), who agreed to coordinate this work.
---
Robert J. Hanisch                       Tel. (410)338-4910   Fax. (410)338-5090
Space Telescope Science Institute       NSI: hanisch@stsci.edu [130.167.1.2]
3700 San Martin Drive                   DECNet: STSCIC::HANISCH [6549::] 
Baltimore, MD  21218  USA               Bitnet: hanisch@stsci
From: mcdowell@head-cfa.harvard.edu (Jonathan McDowell)
Newsgroups: sci.astro.fits
Subject: Re: World Coordinate System proposal
Date: 10 Nov 92 14:22:07 GMT
Organization: Smithsonian Astrophysical Observatory, Cambridge, MA,  USA

From article <1dev6dINNnkp@darkstar.UCSC.EDU>, by sla@umbra.UCSC.EDU (Steve Allen):
> 

[... Does the center of pixel (1,1) have the coordinates (1.0,1.0) or (1.5,1.5)???]

> If the astronomical community will be variant in this way it will be
> essential to clearly document the definition of a pixel.  There will
> undoubtedly be some astronomical programmers who cling to the more widely
> used CG definitions of pixels, and interoperation of their software with
> other software will be difficult if these underlying assumptions are not
> made explicit in the documentation.
> _______________________________________________________________________________
> Steve Allen          | That was the equation!         |   sla@lick.ucsc.edu
> UCO/Lick Observatory | Existence!...Survival must     | If the UC were opining,
> Santa Cruz, CA 95064 | cancel out programming! -- Ruk | it wouldn't tell me.


I agree that clear documentation is crucial. Here at SAO we have always
used the "CG" definition (center of bottom corner pixel is at "0.5");
IRAF uses  mostly "1.0" but not always; and historically FITS has left
it up to the user to include a comment card to document how the
coordinate system used by CRPIX is mapped on to the data array. We've
run into awful trouble in the past by getting confused about this. I'm
happy with the "1.0" choice, but we need to make it as explicit as
possible. Make the distinction between the number of a pixel (an integer
n-tuple) and the coordinates of its center (a real n-tuple) explicit,
even if the choice of convention makes them numerically equal. 

I hope the standard will use lots of small and simple words and some
examples (like: "The first data item in the array section is considered
to be the pixel whose number is (1,1,1,...1). The number of the next
pixel is (1,1,1,...,2). The  coordinate value corresponding to the
center of the pixel numbered (1,1,...1) is (1.0,1.0,...,1.0)."


 .-----------------------------------------------------------------------------.
 |  Jonathan McDowell                 |  phone : (617) 495-7176                |
 |  Harvard-Smithsonian Center for    |                                        |
 |   Astrophysics                     |                                        |
 |  60 Garden St, MS4                 |                                        |
 |  Cambridge MA 02138                |  inter : mcdowell@urania.harvard.edu   |
 |  USA                               |  inter : mcdowell@cfa.harvard.edu      |
 '-----------------------------------------------------------------------------'