Abstract

Refined Algorithm for the Identification in Star Catalogs

W. Zimmermann

Der Algorithmus zur Identifikation von Sternen in Sternkatalogen wurde verbessert. Anlass war eine längere Fehlerliste vom XZ94E, die mir Mitsuro Soma Ende 1997 zugeschickt hat.
Im Vortrag werden die einzelnen Schritte beschrieben, die pro Katalog durchgeführt werden müssen, sowie die Veränderungen gegenüber dem alten Verfahren.
Mit dem neuen Verfahren ergibt sich eine erheblich bessere Trefferrate bei weniger manuellen Nacharbeiten.

Given is a database with stars and their cross-references and a new star catalog as ASCII file. The task is to identify the stars in the ASCII file and find the correct entries in the database.

Until August 1994 stars were identified by their designations only. The general idea was, if a catalog references a star by an SAO number for example, that this is correct. It was correct except for a handful of problem cases. But it was full of problems for DM numbers.

Since the end of 1994 a new method has been used. Only coordinates are compared independent of existing references to other star catalogs. General idea since that time: All designations are wrong (sorry professionals, it is a very unpolite generalization).

It worked well, but it was refined at the beginning of 1999. In 1997 Mitsuro Soma sent me a list of XZ identification which I should check again. I checked it with the new algorithm - and in nearly all cases he was right. Some problem cases still remain, and in some cases I can now give some good reason, why I think that my identification is better.

Short description of the identification process:

Step 1: CATXHIT1

This program takes input star by input star and gives an answer to the question "which one CAN it be". Input is the ASCII file, the database, a maximum angular distance for the possible candidates, and the coordinate system in which the comparison shall be done.
Output is another ASCII file with a list of 5 possible candidates per star with a weight for each candidate.
Change: the old version computed separate weights for a window in R.A. and declination, the new version computes the correct angular distance and a single weight from this distance.

Step 2: CATXHIT2

This program takes all input stars in the specified angular distance and gives an answer to the question "which one fits best".
Input is the output file from CATXHIT1, the database, and the angular distance.
Output is another ASCII file again with a list of 5 possible candidates per star with a weight for each candidate, but only with the highest weights.
Change: The old version stopped checking of all candidates in the given window too early. The problem was: how many records of the ASCII file must be buffered that all stars in the given angular distance and their candidates can be checked.

Step 3: CATXSELH

"Give me the best candidate for each star".
Input is the output file from CATXHIT2.
Output is a file with pairs "catalog describing cross-reference - cross-reference for the best candidate"

Step 4: CATXUPD

"Add the identification to the database".
Input is the file with pairs from CATXSELH.
Output is an updated database - and an ASCII file with those stars where the update failed.

Step 5: no program, manual work

Check the list with failing stars. If required, remove identifications.

Step 6: CATXSELF

"Let us complete the job".
Fine, if all pairs from CATXSELH were processed and put into the database, but this is not the normal way.
Input is the output file from CATXHIT1 (1, not 2!).
Remove all stars which were loaded into the database.
Remove all candidates which were referenced in the output file from CATXSELH (they cannot be candidates any longer).
Output is another ASCII file with less stars and less candidates.

Next steps:

Repeat the sequence CATXHIT2, CATXSELH, CATXUPD until the list of pairs is empty.
Result: part of the catalog is identified, some stars not. Add them with CATXLOD.

And were are the problems?

• The angular distance for CATXHIT1
  The older the catalog, the harder the determination of the angular distance is. Normally 12 arcseconds are good, for B1950 catalogs 24 arcseconds are better, for DM catalogs (1855!) 120 arcsecond are required (puh), but some B1950 catalogs with very bad coordinates (Gliese Nearby Stars, General Catalog of Variable Stars...) need 240 and more arcseconds.
  A small angular distance reduces the number of candidates, a large distance "guarantees" the maximum of 5 candidates, i.e. more work for CATXHIT2.
• Buffering in CATXHIT2
  The larger the angular distance, the larger the number of ASCII records to be stored and checked.
• Step 5 "manual work"
  Typical situation: error message from CATXUPD "conflicting cross-references" and a line in the file with stars which were skipped. The reason is that the candidate was used by another input star, because it was earlier in the ASCII file. And now the question: was it better? You can see, how it works. CATXHIT2 could not resolve this conflict and allows an update. CATXUPD detects the conflict and rejects the update.
  In the past I could only have a very sceptical look at the columns of numbers, but now I have a program to plot me the path of the input star and it's candidates over a long time span. This is an additional help.

Final result:

Good problem cases remain problem cases, but the number is actually reduced by the above method.

Wolfgang Zimmermann, International Occultation Timing Association - European Section
Address: Dreihornstr. 3a, 30659 Hannover, Germany
E-Mail: zimmermann@kph.de Telephone: +49 511 6498029

[HOME XVIII ESOP Homepage]

(c) 1998-2000 Schwäbische Sternwarte e.V. Stuttgart - All rights reserved
Bei Problemen: webmaster@sternwarte.de