Replace common star names with those in SSCs repo

[10110111]

The database in stellarium-skycultures repo, common_names.tab, contains more star names, and appears to mostly be a superset of those currently contained in common_star_names.fab, except minor differences in orthography. This PR adds a script and updates the names from that database.

The nuance is that no references are kept, because if I write a number, it will refer to the external sky cultures repo, which seems not very good. Reference numbers are still present in that repo, in common_names.tab, referring to the actual references in common_names_refs.tab.

[alex-w]

The common_names.fab file in stellarium-skycultures contains data from modern skyculture.

So, the first and important question - where we're using common_star_names.fab file?

[gzotti]

I must admit I was not even aware of this file. What is the actual use?

Currently all names seem to have come from Allen, which used to be a well-known standard before IAU cared for star names. Enlarging the list with entries from unknown sources is generally a bad idea IMO. (and I see that some references from the list are no longer available. Taking names from just any private or club homepages is indeed questionable. Books, DOI, other citable publications, yes.)

Is it a fallback list for SCs that come without their own names and where names still should be displayed (is that the purpose of the "fallback_to_international_names" tag? There might be SCs without any proper names on purpose, then setting this to false is good. When set to true, does that mix international and own names, only for finding or for on-screen labeling? (More label options will be introduced as needed and useful...))

Maybe at this point the most useful list to place here is the now-common and official IAU star name list. In this case reference numbers will not be necessary, just a comment in the header (# IAU list from <datestamp>, <URL>), and the occasional update when that list is extended.

[alex-w]

IMHO we should use IAU-approved list of names as a data for common_star_names.fab (see https://exopla.net/star-names/modern-iau-star-names/)

Also I think SC should support at least 2 mode:

• strict - SC use names for celestial objects as it defined in SC
• weak - SC use names as it defined in SC and plus common names for celestial objects (when name is not defined for some object)

Maybe Bayer and Flamsteed designations shouldn't be used for strict mode

[10110111]

What is the actual use?

First use that affects all SCs is for the common_names entries. Such an entry can list a name as an id, like NAME Al Thalimain I, for which the culture-specific names will be given.

Second is, indeed, the default names for SCs with fallback_to_international_names=true.

When set to true, does that mix international and own names, only for finding or for on-screen labeling?

Currently, when this option is set, the common names are added after having added all culture-specific ones.

[gzotti]

OK, then let's use the IAU list here for clarity, no additions, no omissions. And please let's rename the file to iau_star_names.fab for added clarity.

Good idea about strict/weak. Given the importance of Bayer/Flamsteed (BF) names, maybe they should be loaded in an intermediary setting, so that we can have original names but in addition BF labels, maybe even in the screen label.
(Would we still show them in the InfoString? Or do we else only have HIP/Gaia numbers there?)
The BF names, and only those, are in file name.fab. Maybe the file should then also be renamed to bayer_flamsteed.fab to reflect that no other codes are allowed there.

Should this manual selection override the "fallback_to_international_names"? Would it make that tag unnecessary? (I guess not. It just declares "this SC happily uses the international names as its own".)

[gzotti]

Such an entry can list a name as an id, like NAME Al Thalimain I, ...

Nice!

[10110111]

IMHO we should use IAU-approved list of names as a data for common_star_names.fab (see https://exopla.net/star-names/modern-iau-star-names/)

Note that some stars given there don't have a HIP identifier. Does Gaia have an identifier for all known stars? (BTW, why do I not get the XO-5 identifier in the info panel for XO-5?)

[alex-w]

Note that some stars given there don't have a HIP identifier. Does Gaia have an identifier for all known stars?

Yes. @sushoff could you add Gaia DR3 designations for stars?

(BTW, why do I not get the XO-5 identifier in the info panel for XO-5?)

I got other designations through SIMBAD

[10110111]

As for getting all the IAU-defined star names, is there a way to download a table of them? The WGSN website is not only extremely slow, it doesn't seem to provide any API to get the database.

Also, it seems that Modern-IAU SC should then drop all its star names and set fallback to true.

[gzotti]

Does Gaia have an identifier for all known stars?

Shouldn't it have one, by definition of how such number is formed?

Of course, XO-5 and friends are the newly-named exoplanet systems which are culturally irrelevant (apart from "pop culture") but still IAU approved...

Also, it seems that Modern-IAU SC should then drop all its star names and set fallback to true.

Yes, the most perfect example!

[alex-w]

What's current status of this PR?

[gzotti]

In essence, we agreed we should use the official IAU list (also with IAU in its name for added clarity, and a header indicationg its age/date version) and find a way to systematically download the latest current version of the IAU list from whereever WGSN wants to make it available (@sushoff ?) before each release. Then each SC author can decide to use it via fallback inclusion. The modern_IAU SC must definitely include it and we should then delete its private name list. Other modern SCs of "single" classification should not include it when they provide their own.
If names are given to non-HIP and non-Gaia stars (XO-5?), we probably cannot use them. Or does the Exoplanet plugin interact with the cultural star names? (I think @alex-w you update the list yourself periodically?)

It probably also has to be postponed to 25.4, but we should come to a conclusion and solution then.

[sushoff]

IAU WGSN entertains a living document that is continuously updated every few weeks

• IAU Catalog of Star Names

on their website https://exopla.net/

[sushoff]

The list of star names is continuously updated (every few weeks).

The list of exoplanet names (https://exopla.net/star-names/database/exoplanet-name-catalog/ ) has not been updated for long time, as they originate from naming campaigns years ago.

[sushoff]

For the catalogs on the website, I just compiled what I found in WGSN-press releases.

I now saw that you wanted me to include Gaia DR3 identifiers - that had slipped through my fingers yet, sorry. Is it still wanted? If so, I will write me an issue and deal with it ASAP (but certainly not for 25.3)

[gzotti]

For the catalogs on the website, I just compiled what I found in WGSN-press releases.

I now saw that you wanted me to include Gaia DR3 identifiers - that had slipped through my fingers yet, sorry. Is it still wanted? If so, I will write me an issue and deal with it ASAP (but certainly not for 25.3)

The .fab format was actually not prepared for Gaia names, so also the parser will have to be modified to accept non-HIP stars. Maybe we can define some ad-hoc format (which includes year of acceptance, Exo/regular name or some origin meta info?) and just call it .txt.

[alex-w]

The .fab format was actually not prepared for Gaia names, so also the parser will have to be modified to accept non-HIP stars.

The .fab file is a plain text file and formally it accepts Gaia ID's in current format, but yeah - the parser should be upgraded to reading quin64 ID's (from the .fab file can be easily extracting translatable data).

[alex-w]

IAU WGSN entertains a living document that is continuously updated every few weeks

• IAU Catalog of Star Names

on their website https://exopla.net/

The main problem is not availability this list as machine readable data - it can't be obtained via API or scripts to automatization of updating the data in Stellarium.

[sushoff]

agree, that's still a problem and related to my other server-related issues (still looking for an institution to host all data together instead of distributing them to many ... this question is connected to job-related questions, and therefore, I haven't found a solution yet: technically easy - politically not)