[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Seeding TASS Catalog.
- To: email@example.com
- Subject: Seeding TASS Catalog.
- From: Chris Albertson <firstname.lastname@example.org>
- Date: Thu, 22 Jan 1998 14:22:26 -0800
- Old-Return-Path: <email@example.com>
- Organization: Logicon RDA
- Resent-Date: Thu, 22 Jan 1998 17:48:50 -0500
- Resent-From: firstname.lastname@example.org
- Resent-Message-ID: <"jARFJD.A.4aB.9b8x0"@kani.wwa.com>
- Resent-Sender: email@example.com
- Sender: firstname.lastname@example.org
It seems people like the idea of cross identifications but
the problem to be solved is a little different. It turns
out that if we solve the matching problem be using a seeded
catalog then cross IDs will be a useful byproduct but
not the reason for doing it.
Here is the problem to be solved:
Suppose in the sky there are two stars < 15 arc seconds apart.
Let's call then A and B. We can assume in the following example
perfect astrometry. The problem is not due to the MkIII's
Now, there are three ways TASS can see these:
1) Camera 1 sees A only
Camera 2 sees B only
In other words A and B are not seen together in the
same frame. Could be due to filters or other factors.
2) Camera 1 sees both A and B
Camera 2 sees only A
3) Camera 1 sees only A
Camera 2 sees both B then A (by chance B precedes A in the
Later when we attempt to merge the data we get different
results from each case.
1) The database records one star with the number of observations
field = 2.
This is not a bug. It is a wrong result. but the algorithm
is doing the best it can given the data. The two stars are
within the 15arcsec matching tolerance.
2) The database records two stars and notes A seen twice and B once.
This is the correct answer. The reason it works here is the
the merge algorithm will not merge two stars that are within
the same frame no matter how close they are.
3) We do not get the same result as above.
We process camera1/A and create a new catalog entry.
Next we process B and it matches that new entry so we set
Next we process A and create a new catalog entry for it.
Once the catalog contains two entries we are OK from that point
on but prior to the first time the two stars are detected together
in the same frame we will merge data that we should not have.
I'm willing to bet a lot of "variables" will turn out to be
due to this effect.
The "catalog seeding" algorithm I would use is simple. I'd just
copy the ra,dec fields from the (say) GSC into the tass catalog
ra,dec fields and set the "number of observations" to zero. The
merge program I posted would not need any modification and would
continue to use Arne's collate criteria (closest star within 15
The down side to catalog seeding is that the TASS catalog would
contain many entries for stars for which we have no data. In
fact tass catalog entries would have NumObs=0. This is not
such a big problem as I would assume most every doing a catalog
search would specify at least NumObs>1 just to avoid seeing
noise hits and clutter. Those NumObs=0 catalog entries will
also fill up Michael's' new disk a little and slow down searches
by some amount.
Next question. Which catalog to use as a seed. Pick +one+.
We are using Tycho for astrometric calibration so I assume
we want to use a catalog that agrees well with Tycho every
where to at least an arc sec. One other thing, I will need
the data soon, in a week or a few days. So pick an +available+
I'll wait until it seems like a group decision has been made.
email@example.com Voice: 818-351-0089 X127
Logicon RDA, Pasadena California Fax: 818-351-0699