stars.txt

[hank]

Obviously, a cross index needs the HR = Bright Star numbers and these necessarily invoke the corresponding catalog, i.e. the Yale Bright stars...

But this is just for historical completeness. It's mainly the HIP, Tycho and HD catalogues who are these days taken as references.

Fridger,

The Bayer designations for these stars haven't changed since the work of Argelander (Heis?) in the nineteenth century.

- Hank

[t00fri]

Obviously, a cross index needs the HR = Bright Star numbers and these necessarily invoke the corresponding catalog, i.e. the Yale Bright stars...

But this is just for historical completeness. It's mainly the HIP, Tycho and HD catalogues who are these days taken as references.

Fridger,

The Bayer designations for these stars haven't changed since the work of Argelander (Heis?) in the nineteenth century.

- Hank

I don't know what you want to say with this remark.

If you look into SIMBAD you see that MU1 & MU2 Boo are meanwhile running under a multitude of names. The question is which one is the most popular or "official" one these days. That's all. Certainly the Bayer-Flamsteed ones are not entirely forgotten. This is not to be disputed.

Bye Fridger

[Cham]

Thanks Fridger,

I just noticed something odd : look in the visual STC file. The first entry is HIP 2237. The component A has the 2237 assignation, while the barycenter doesn't. Is this consistent ?

[t00fri]

Thanks Fridger,

I just noticed something odd : look in the visual STC file. The first entry is HIP 2237. The component A has the 2237 assignation, while the barycenter doesn't. Is this consistent ?

That was always my assumption. The baycenter never carried the HIP number. However the question is rather whether I should add the HIP number also to the B component. I thought that it's good enough to associate it with the A component throughout.

That will have to be decided by Chris L., since he coded the stuff. Perhaps Selden also knows, too, since he usually knows everything

Bye Fridger

[Cham]

The only small problem I have with this assignation is to use the script : the script is then marking the star with the assignation (component A), instead of the barycenter itself, so it doesn't feel very consistent with the rest.

Would it be better to remove that number assignation to all the stars in the visual STC file ? Personally, I think it's better to give the barycenter itself the HIP number assignation, instead of one of the components.

[hank]

The Bayer designations for these stars haven't changed since the work of Argelander (Heis?) in the nineteenth century.

I don't know what you want to say with this remark.

If you look into SIMBAD you see that MU1 & MU2 Boo are meanwhile running under a multitude of names. The question is which one is the most popular or "official" one these days. That's all. Certainly the Bayer-Flamsteed ones are not entirely forgotten. This is not to be disputed.

I don't think there is an "official" standard for the Bayer nomenclature, although I believe the Bright Star Catalog is a widely used source. It is certainly a "professional level" star catalog (BS/HR designations are officially accepted by the IAU), and is undoubtedly "up-to-date" as far as the (nineteenth-century) Bayer nomenclature for these stars is concerned. That's what I was trying to say.

But I really raised the issue because of the apparent inconsistency with Celestia's current usage. I think we definitely don't want the dot to appear in the UTF-8 name display, although for compatibility with SIMBAD it might be useful to allow it in the selection type-in.

- Hank

[selden]

Thanks Fridger,

I just noticed something odd : look in the visual STC file. The first entry is HIP 2237. The component A has the 2237 assignation, while the barycenter doesn't. Is this consistent ?

That was always my assumption. The baycenter never carried the HIP number. However the question is rather whether I should add the HIP number also to the B component. I thought that it's good enough to associate it with the A component throughout.

That will have to be decided by Chris L., since he coded the stuff. Perhaps Selden also knows, too, since he usually knows everything

Bye Fridger

I wish!

My bias would be to include the HIP designation as one of the names specified for each of the components (that is, included in the quoted string), but suffixed by an appropriate designation unique to that particular component of the system. That seems to be what is being done now for binaries, although not for the stars in nearstars.dat. (The HIP designations don't seem to be included in any of the name strings in that file, only the numbers are used.)

However, at the moment my preference would be for a space to be specified in those names, placed between "HIP" and the number. That's the convention used on Simbad: a space between the abbreviation used for the name of the catalog and the designation used in the catalog for that object. This also would make the format be more nearly equivalent to specifying only a HIP number in an STC catalog -- so that one can type "hip<space>number" in the [return]<name>[return] selection command to select those stars.

One problem with specifying HIP catalog identifiers in the quoted name strings is that including any HIP identifiers in the name strings causes confusion for many people. Since the HIP identifiers which are specified in quoted names appear when "tab completion" is used, people often expect all HIP numbers to appear when "tab completion" is used. HIP numeric values actually do not appear when "tab completion" is used, so people mistakenly think that those "missing" stars are not selectable.

A separate issue is that my (perhaps mistaken) understanding is that the HIP number when used by itself, not inside the quotes, is an index into Celestia's stars database. Whatever STC catalog entry it's associated with is supposed to replace the corresponding entry that was originally provided in stars.dat. I think that it would be nice if this (unquoted) HIP number could be associated with whichever star it originally was intended to designate in the Hipparcos catalog, if that can be determined. I suspect that's almost impossible in most cases, especially when spectrographic binaries are concerned, so associating the HIP catalog number with the A component seems reasonable to me.

[hank]

OK I checked the starnames.dat file. Indeed that's the names that Celestia uses (MU2, BET2, BET1,...), which are not conform, however, with the encouraged SIMBAD identifiers.

However, I found out that SIMBAD does accept MU2 Boo etc. Hence we should continue with that previous notation.

I see that Selden's Celestia WikiBook description of the STC file format specifies that the 3-character abbreviations for the Greek letters with trailing dots for MU, NU and PI (and KSI for xi) should be used. But evidently this usage has not been applied consistently in Celestia (e.g. in starnames.dat). I don't know what the implications of the discrepancy might be.

- Hank

[chris]

OK I checked the starnames.dat file. Indeed that's the names that Celestia uses (MU2, BET2, BET1,...), which are not conform, however, with the encouraged SIMBAD identifiers.

However, I found out that SIMBAD does accept MU2 Boo etc. Hence we should continue with that previous notation.

I see that Selden's Celestia WikiBook description of the STC file format specifies that the 3-character abbreviations for the Greek letters with trailing dots for MU, NU and PI (and KSI for xi) should be used. But evidently this usage has not been applied consistently in Celestia (e.g. in starnames.dat). I don't know what the implications of the discrepancy might be.

- Hank

This information is not consistent with the Celestia code, which uses MU, NU, and PI without trailing dots, and XI instead of KSI. If there's an official IAU statement on Bayer designations, I suppose we should follow it. Otherwise, I'm inclined to just leave things as they are, since Fridger reported that SIMBAD accepts both forms. One thing that would be nice is if Celestia recognized the full Greek letter names as equivalent to the short forms. Right now, naively attempting to select Alpha Centauri will not work; you need to enter 'alf centauri' (or one of the several common names).

--Chris

[t00fri]

Here are my recommendations in form of a list with decreasing importance:

• Celestia conventions should be part of a professionally adopted AND popular (SIMBAD) designation scheme. Or Celestia should at least accept such a scheme on its input command line.
  
• Celestia conventions should be directly accepted by SIMBAD which these days serves as a universal reference database.
  
• In the long run, the standardized 2-letter + trailing dot ASCII forms for 2 letter Greek letters (MU, PI, ...) and KSI ... should be accepted /interpreted correctly by the Celestia command line!
  
  The reason is that professional astronomers are used to these forms and would naturally try them also as Celestia input forms. This is not very much additional coding work.
  
• In the long run, the Celestia command line should accept ALL input forms using different amounts of space, -,.. between the letter keywords and the numerals, e.g.
  HIP12345, HIP 12345, HIP-12345, or M31, M 31, M-31, just as Google does.

Here are some further tests on the SIMBAD input line:

• MU Boo => accepted, leads to ADS 9026, second listed identifyer: MU. Boo (trailing dot). This means MU Boo is NOT considered as a correct designation (merely as an input alias!).
  => cf. my previous dispute with Hank...
  
• XI CrB => accepted, leads to KSI Crb, many other listed official identifyers, BUT NOT XI CrB!
  
  => that's why I previously used KSI etc instead of XI in my binary orbit database.
  
• MU1 Boo => accepted, leads to NSV 7063, many other listed official identifiers, like MU.01 Boo, 51 Boo A, BUT NOT MU1 Boo, which thus is NOT taken as a correct official designation.
  
  => see my discussion on name choices with Hank that lasted far too long.

Bye Fridger

[t00fri]

Here are some further investigations on pecularities of the Celestia input command line wrto binaries:

Displayed form: <input> --> <output on canvas>

• Single Star with proper name:
  XI CrB --> xi CrB / 19 CrB / HIP 80181 / HD 147677 / SAO 65254
• Single star with only HIP designation
  HIP 14778 --> HIP 14778 / HD 19723 / SAO 111028
  -----------------------------------------------------------------------
• Binary star with proper name
  13 Cet --> 13 Cet (Barycenter selected!)
  13 Cet A --> 13 Cet A / HIP 2762 / HD 3196 / SAO 128839 (selected)
  13 Cet B --> 13 Cet B (selected)
  
  MU1 Boo --> mu^1 Boo (Barycenter selected)
  MU1 Boo A --> mu^1 Boo A / HIP 75411 / HD 137391 / SAO 64686 (selected)
  MU1 Boo B --> mu^1 Boo B (selected)
  ------------------ BUT ----------------------------------------------
• Binary with HIP designation only
  
  HIP 2237 --> HIP 2237 A / HIP 2237 / HD 2475 / SAO 166296 (HIP 2237 A selected! )
  HIP 2237 A --> HIP 2237 A / HIP 2237 / HD 2475 / SAO 166296 (selected)
  HIP 2237 B --> HIP 2237 B (selected)

-------------------------------------
Apparently there is an ANOMALY for binaries that only have a HIP designation! The barycenter is not available to go to or for selection!
--------------------------------------

Moreover...

• If HIP number added in front of barycenter
  (Cham's preference)
  
  => only the HIP star displayed, orbits don't work!
  A, B components are not offered in the list!
  
• If HIP number is the same for the A and B components,
  it MUST only appear ONCE in front of the A component
  for things to work properly
  (=> that's what my visualbins.stc and spectbins.stc respect)
  
• If HIP number is different for A and B components,
  they MUST appear in front of A AND B componets.
  (=> cf. e.g. Grant's nearstars.stc)

Before I finalize and commit my visualbins.stc and spectbins.stc database, we should once for all agree whether we want these pecularities. If NOT, the code should first be changed!

Bye Fridger

NB: Please, also take note of my previous post!

[hank]

On the long run, the Celestia command line should accept ALL input forms using different amounts of space, -,.. between the letter keywords and the numerals, e.g.
HIP12345, HIP 12345, HIP-12345, or M31, M 31, M-31, just as Google does.

I think that in the long run it would be nice if Celestia were as flexible as possible in name input, both for type-in line (and Lua script) selection and for data files. The SIMBAD conventions should be included but not exclusive. Internally the various forms should be treated as referring to the same object in all contexts. For display, UTF-8 with actual Greek characters and superscripts should be used. But for now (1.5.0), the data files could be modified as a work-around.

- Hank

[t00fri]

In general there are three different areas where this discussion about name designations becomes relevant, partly in different ways:

• Actual names under which the stars, galaxies,.. are stored
• Input parsing properties on the Celestia commandline
• Output appearance on the Celestia canvas

Let me emphasize that I am also unhappy, if I am forced to store non-standard names in our data files, because Celestia's code is not properly coded to accept a widespread, standard naming scheme.

But for now (1.5.0), the data files could be modified as a work-around.

We can save our time writing lots of posts here, if in the end we take recourse to an improper workaround as so often.

Bye Fridger

[hank]

Let me emphasize that I am also unhappy, if I am forced to store non-standard names in our data files, because Celestia's code is not properly coded to accept a widespread, standard naming scheme.
...
We can save our time writing lots of posts here, if in the end we take recourse to an improper workaround as so often.

I understand and appreciate your concerns, Fridger. I'm just afraid that if we delay the next release until Celestia is perfect, there will never be a next release. "The better is the enemy of the good."

- Hank

[t00fri]

Let me emphasize that I am also unhappy, if I am forced to store non-standard names in our data files, because Celestia's code is not properly coded to accept a widespread, standard naming scheme.
...
We can save our time writing lots of posts here, if in the end we take recourse to an improper workaround as so often.

I understand and appreciate your concerns, Fridger. I'm just afraid that if we delay the next release until Celestia is perfect, there will never be a next release. "The better is the enemy of the good."

- Hank

Well it can't be that bad, otherwise Chris L. wouldn't have vanished for three months without organizing ANY "workarounds" whatsoever

OK, if Chris L. wants the binary files and the rest as is, he can have them. Then I'll be free to turn to other things. Anyhow that ongoing "small talk" about naming conventions just takes time and effects nothing until we really get together and DO something systematic. So I would prefer to continue such discussions mainly with people who have some background in that matter.

Such worn-off phrases

"The better is the enemy of the good."

don't get us anywhere at this point. This is a thread about doing real work, not citing proverbs...


Bye Fridger

[hank]

OK, if Chris L. wants the binary files and the rest as is, he can have them. Then I'll be free to turn to other things. Anyhow that ongoing "small talk" about naming conventions just takes time and effects nothing until we really get together and DO something systematic. So I would prefer to continue such discussions mainly with people who have some background in that matter.

Fridger, you are free to do as you please. You have no obligation whatsoever to read or repond to posts by persons whose ideas and opinions you do not respect.

My original response to Cham was:

There are still lots of problems with the binaries (mostly duplicates), that I've indicated elsewhere... Can't the binaries be corrected and updated on CVS ?

How would this be done? Who would do it?

I intended this precisely to make the point that raising the issue again in the forum just takes time and effects nothing unless we get together and figure out what needs to be done and who will do it.

- Hank

[Cham]

I think the source of problems with the naming scheme is how Celestia has been coded :

Currently, Celestia is using the HIP numbers as the internal way of identifying the various stars. To me, this is a source of problems. IMO, it would be better to use an independant internal numbering scheme, and use the HIP numbers in the name definition only (that is enclosed between " ", in the STC files).

I suggest that the code be changed (with backward compatibility in mind) so that the arbitrary internal numbers become completely independant from the HIP numbers, and the HIP are only introduced via the names enclosed in " ". That way, we could use ANY number in front of the name, in any STC file, and the HIP is defined IN the name itself only. We could then select a star using its real name in the command line (as we should anyway), and NEVER see the internal number used by Celestia, in the upper-left corner.

Chris, is that possible ?

EDIT : There may be some problems with stars without a name. I already have some addons made a long time ago by Rassilon, who defined lots of fictious stars in some globular clusters (M4, M22, for example). How the name should be indicated in the upper-left corner, in these cases, if some stars doesn't have a name declared in the STC file ? The only way I can see is to show the actual internal number used by Celestia (if no name have been declared), with a clear sign that there are no real name declared in the STC file, something like this (in the upper-left corner) :

Code: Select all

Star 1212399 (no name).

This even has an advantage : the user could then know that this star is a fake one !

[t00fri]

My original response to Cham was:

There are still lots of problems with the binaries (mostly duplicates), that I've indicated elsewhere... Can't the binaries be corrected and updated on CVS ?

How would this be done? Who would do it?

I intended this precisely to make the point that raising the issue again in the forum just takes time and effects nothing unless we get together and figure out what needs to be done and who will do it.

- Hank

But this is really NOT your business. Let those people take care of it who know about these things. Either contribute actively to solving the problem or just relax...

When asking that question, you were not even aware who had done all that work about the binary orbits

Bye Fridger

[t00fri]

Martin,

I think the source of problems with the naming scheme is how Celestia has been coded :

Currently, Celestia is using the HIP numbers as the internal way of identifying the various stars. To me, this is a source of problems.

This is hard to avoid. The HIP numbers or at best the PGC numbers are used throughout as "running index numbers" across different catalogs. Otherwise it becomes practically impossible to keep track when merging information from numerous different catalogs. The number of different names of DSO's is so rich that there MUST be a universally accepted running number that each catalog specifies for cross identification.

Chris, is that possible ?

As you know, almost everything is possible. The question is only whether it is also worthwhile

Bye Fridger

[Cham]

Well then, the problem is to avoid the ones you have indicated in a previous message, and that I've indicated too :

In a given binary, how can we select the barycenter itself from the command line, if it has the same HIP name as one of the components, as stored in Celestia's internal number ? This is also causing some selection problems with scripts.

If the barycenter can't have an HIP number in front of its name (in the STC file), is it a good solution to simply remove the HIP number in front of the star names, since Celestia can identify the stars from their declared names anyay ?

EDIT : Hmm, it doesn't work, apparently. I just made a test with HIP 2237. Removing the number in front of its name put a new star at the binary center, with the same name as the barycenter itself !