Re: TASS Database, a couple proposels to get started

["Mark Pitts" <PITTS@shands.ufl.edu>]

Greetings all,

First a quick update.  I received the CD's Tom sent (Thanks Tom!).  Work will begin this weekend on getting the MR pipeline running.

I agree with Chris that there's no reason we shouldn't start working on defining particulars of the database.  IMHO, this is the most important step in the whole process.  

I'd like to handle the Sourceforge part.  It's going to take a little while for me to get up to speed on programming for this type of application, so I can at least run the Sourceforge site while I'm learning.  If there are no objections I'll start the setup process immediately.

Mark

>>> Chris Albertson <chrisalbertson90278@yahoo.com> 02/07/02 12:55PM >>>
I think we are ready to agree on a basic outline and
start work on table and file designs.  See below

--- aah@nofs.navy.mil wrote:
<SNIP>
>   These are reasons why I continue to push for more information in
> the
> database than just time, position and magnitude.
>   I also still think that the Mark III method of 'seeding' a catalog
> is
> the proper way to go here.  Use the UCAC catalog as your source of
> good
> objects, then just match the known catalog when importing a new list.
> The error that occurred in the Mark III database is that the seed
> catalog
> was just used as an initial guess and the imported starlists
> overwrote
> the position.  You should use UCAC as the absolute truth and leave
> its
> positions alone.  When importing, you can do things like checking the
> percentage of UCAC matches for a given import list; if not high
> enough,
> then there is likely an error in the import list astrometry.
> Arne
> 

For those who don't remember the Mk III database I'll summerize
below.  It worked well but suffered some in some details of
implementation.  We can do better enginerring this time but the
basic algorithm and organization is sound and I doubt we want to
change it.

We had two lists (tables in a DBMS) one was a list of stars,
one row per physical star.  The other list contained all the
observations from all cameras.  This list was much longer as
typically a star would be observed many times.  The first list
was called "catalog" can the second called "observations".

To import new data we first checked each new observation in
a new star list see if there was a matching entry in "catalog"
if so we added the catalog-id and appended the new observation
to the observation table. if there is no matching catalog entry
we made a new entry then proceded as if we had found a match.

"Catalog" contains summary statistics for all observations of
a stars.  These include the mean and one sigma for ra, dec,
magnitude in each color, number of observations plus some
book keeping data like the sum of the squares of ra, dec and
mag. quality flags and so on.

When we started, rather then begin with an empty catalog we
copied about 16 million entries from a list supplied be Arne.
We copied ove the mean magnitudes ra and dec but set the
"number of observations" counters to zero.  This is what Arne
means by "seeding".  We ran the import software and many
catalog matches were found.  We had a rul that the "seeded"
means were not to be changed until
"number of observations" > "about five"  This worked well
and I'd recomend we do it with Mk IV data.

I think we have enough experiance with TASS databases that
wa can start writing SQL "create" commands and passing them
around for review.  We can all write whatever code we want
but must agree on a common core set of tables.

While we are at it, can we agree now on a format for starlists.
"oe file per frame" for sure but then what?  I will
strongly argue for using FITS tables for star lists.  The rule
should be:  Do whatever you like at your location but if you
send a file so someone it will be FITS and will have a defined
minimum data content but may have more

Once we agree on a set of tables and a start list let's
start using CVS.  We'll put it up on Source forge.  I'll
do the setup work if no one else want s to.  However this
is a good opertunity for a computer savey non-programmer to
make a ral contribution -- running the source forge site.

=====
Chris Albertson 
  Home:   310-376-1029  chrisalbertson90278@yahoo.com 
  Cell:   310-990-7550
  Office: 310-336-5189  Christopher.J.Albertson@aero.org 

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com