Re: [Celestia-developers] Celestia 1.4.0 pre 7

[Chris L. <cl...@ww...>]

> Chris,
>
> today I followed up your critics of my binary orbit files a little more
> in detail
>
>>  I've excluded Fridger's catalogs of visual and spectral binaries
>>  because there are currently too many conflicts with systems defined
>>  in nearstars.stc (including Alpha Centauri.)
>
> ...and from your email somewhat later
>>  While I understand your arguments for 'data purity', I still think
>>  that some hand editing can be a good thing--for example, in your
>>  catalogs the spectral type of Alpha Cen B is listed as '?', even
>>  though it's well known.
>
> I was quite "surprised"...
>
> i) Fact is that /professional/ binary catalogs are mostly subdivided
> into /visual/ and /spectroscopic/ binaries rather than being
> administrated according to distance (like nearstars.stc)!  My vision is
> to eventually include  1000's of binary orbits. Then ONLY the standard
> professional subdivision can prevail...
>
> ii) Fact is that there are only *2 stars* from my *spectbins.stc*
> catalog also appearing in nearstars.st*c*:
>
> alpha Cen A,B  (71683) and
> 70 Oph  A,B     (88601),

Grant sent me this list:
>
> not too much I think for excluding my /whole/ spectbins catalog.
>
> iii) Fact is that your second statement above is simply INCORRECT wrto
> *spectbins.stc*
>
> Have a look at my data for the two overlapping binaries from
> spectbins.stc in CVS below.
>
> You see that in neither of the 2 systems in question ANY input is missing,
> notably NOT the spectral class of the secondary!!
>
> Unlike my data in spectbins.stc and visualbins.stc, many data in nearstars
> are merged together by subjective hand-editing *that was NOT approved by
> the authors of the
> actual orbit measurements*! Being a professional scientist, I cannot
> agree with such a procedure.
> It is not only a question of data purity, it is the fact that the source
> of the included
> individual data remains intrinsically /undocumented/, i.e obscure. We
> know and respect Grant's careful data
> work, but scientific data catalogs must be objective, reproducable
> documents, also if their authors are not
> known "in person" to the user ;-) . As a matter of principle, any
> regrouping of stars from my files into nearstars.stc would be
> problematic, since nearstars.stc is basically UNDOCUMENTABLE. In case of
> all my data files that I release,  including my recent galaxy  data, the
> respective PERL scripts (added to the distribution)   serve the dual
> purpose of extraction  tools  and human readable  1:1 documentations of
> the  generated data.

The problem is that there is that by eliminating any hand editing we would
have to compromise the quality of the data. There is no single source for
all the data used in Celestia. It is by necessity an amalgam of
information from different catalogs. The star database is based on the
HIPPARCOS data set with a set of additions and corrections:

stars.dat - The HIPPARCOS catalog (minus stars with bad parallaxes)
revised.stc - Corrections for known inaccuracies in the HIPPARCOS catalog
extrasolar.stc - Stars not in HIPPARCOS that have planetary companions
nearstars.stc - All known stars within 25ly of Earth
. . . and eventually spectbins.stc and visualbins.stc.

Collectively, these files compose a high quality data set, with many
errors in distances and spectral types eliminated *by hand* after years of
testing by Celestia users. Do you propose removing any of these .stc files
because they've been hand-edited? If so, what exactly is the alternative
that you propose to nearstars.stc? I don't want to use a direct
translation of catalog that has known errors.

> iv) Fact is that unfortunately alpha CEN A,B also appear in
> visualbins.stc, where indeed the
> spectral class of the secondary was not measured.  So all it takes is to
> delete alpha CEN A,B in visualbins.stc...

But isn't this the sort of ad hoc hand-editing that you're very much
against? :)

> We normally don't discard a whole C++ file in the core code of Celestia,
> simply because one method in it  contained a SINGLE, harmless bug! The
> galaxy.cpp file of Celestia-1.4.0pre7 still contains quite a number of
> nasty bugs, for example, that cause galaxy orientation and massive scale
> dimension errors in the display!

My intention is not to exclude visualbins.stc and specbins.stc forever.
But,  in the short term, since there wasn't time to resolve conflicts, I
thought it best to be safe and exclude them. In particular, the problem
with a well-known system like Alpha CEN suggested more work remained to be
done before spectbins.stc and visualbins.stc were ready for inclusion in
Celestia.

Grant sent me the following conflicts:
110893 Kruger 60
30920 Ross 614
88601 70 Oph (2 copies)
82817 Wolf 630
72659 Xi Boo (KSI Boo)
84709 Gliese 667

These can all be resolved with a little effort. 70 Oph B is defined in
both visualbins.stc and spectbins.stc and nearstars.stc, so we end up with
three copies of it in Celestia. That it appears in both visualbins.stc and
spectbins.stc illustrates a shortcoming of your approach I think: which
one do we use? What if there's an accurate spectral type in spectbins.stc
but a better orbit in visualbins.stc? Is it better to use just one
definition or the other in the name of data purity? Or should we combine
them so that Celestia can have the most accurate model of the 70 Oph B
system.

> So I can't help stating that your judgement about discarding my /two/
> submitted binary catalogs
> appeared quite superficial to me. Unlike nearstars.stc, my catalogs
> exhibit  state-of-the-art accuracy, reflect published data and involved
> *a lot of work from my part*!

Let me state again that the exclusion of your catalogs is only temporary.
They will be a very valuable addition to Celestia with a bit more work. I
propose that we adopt a scheme somewhat like the way stars.dat and
revised.stc work--spectbins.stc/visualbins.stc are the base data set, with
the few conflicting definitions in nearstars.stc overriding. Some work on
the data (and I think in Celestia's star catalog code) will be necessary
to ensure that stars are overridden correctly and not duplicated.

--Chris