Re: [TASS] photometric vs. non-photometric

[Alan McCallum <almac@ICONNECT.NET.AU>]

Hello all.

I am trying to understand the TASS database, so I may rehash the thoughts of
others here. Sorry.

Am I right in assuming:
Initially there are two tables similar to the outline below. The index table
is seeded with catalog (Tassm16) positions. When an initial match of
observation to catalog is found, a new TASS ID is assigned to both tables,
thus allowing a join between the two tables (one to many) on the TASS id#.
The database now has one linked star in both tables:

INDEX TABLE
Catalog ID ??
TASS ID   (one)
Catalog RA
Catalog Dec
...

OBSERVATIONS TABLE
TASS ID (many)
Obs RA
Obs Dec
...

Then when the second object within the merge radius of our first star is
found, a mean (including the original catalog position?) was taken, and  the
following was the situation::
INDEX TABLE
Catalog ID ??
TASS ID   (one)
Mean RA
Mean Dec
...

OBSERVATIONS TABLE
TASS ID (many)
Obs RA
Obs Dec
...

Firstly. What happens to objects that are not matched to a seed value?
Dumped forever? I don't think this point has been spelled out.

Secondly. A variation on the above method (I think this is what Arne & Jure
have both implied recently), is to leave the catalog positions in the index
table untouched (as in the first example), and simply populate the
observation table under a particular TASS id# if it falls within the
inclusion radius. And then only use the index table positions to refer to
the star. This only gives an _apparently_ steady position, ie the catalog
position. The observations dance around anyway. Would there be less spurious
pairs? I am not sure. But I think there would be a small gain in accuracy.
(There would have been a very definite gain in database usefulness &
efficiency if the seed Catalog ID was retained in the index table along with
the positions. If the Catalog ID _has_ been retained in an index table, it
is still possible to do a one to one join to another instance of a table
loaded with Tassm16 to recall the relationship between the seed positions
and the current positions.)

In general, it is not advisable to store calculated results in database
tables. If there is another ID (or combination of fields) in the Obs table
that links each observation back to an original image, and a camera has a
bad hair day, or even develops a serious systematic error, it is easier to
pull the bad observations if no calculated fields are involved. Otherwise
each mean, for instance, must be be recalculated. OK. Storing calculated
values can and is done. But it is still not advisable. It is an extra step
that can be overlooked, _particularly_ ten years later. It is also less
obvious when calculated values are means, because the values are in the same
units. Also truly necessary calculated result tables, such as Tenxcat, could
be corrected using less steps.

In passing, it seems obvious to me that a TASS ID should be generated and
used, if only internally. To run matches table-to-table using floating point
values, would likely create more recognition problems than we already have.

On 9 Sep 99 Arne suggested "retain the seed coordinates for future matching,
but have two additional columns of TASS RA & Dec for comparision". In which
table? The index table? A follow-on question then is: which Tass position
gets stored in the index table? The latest mean?

Is a complete TASS database schema published somewhere? I would be
interested. As I understand it, TN56 does not describe all aspects of the
database table arrangements; it only seems to describe Tenxcat. Does
Postgres have a documentation feature that allows quick publication of the
main DB schema?


Alan.


Stupendous Man wrote:

<snip>

>   I know that the TASS database contains many "spurious pairs",
> sets of stars which are really instances of the same celestial object,
> but which appear as separate entities in the database.  I believe
> that some of the objects Andrew mentioned, which appear only a few
> times in the midst of a field with stars detected many times,
> may be members of such spurious pairs.
>
>   Open question to the TASS mailing list: given a stream of data,
> night after night, of stellar positions with some estimated
> uncertainty "sigma" arcseconds, how should we identify detections
> as instances of the same physical object?  Perhaps we should wait
> until N nights have been collected and then merge all at once,
> rather than merging 1 night at a time in a gradual process?
>
>                                               Michael Richmond

--
Alan McCallum   (almac@iconnect.net.au)

Drumborg Victoria AUSTRALIA (38.0551S, 141.5868E)
http://orion.iconnect.net.au/~almac/index.html