New Celestia unified runtime database

[Lafuente_Astronomy]

Well, it's alright. Feel free to check what pirogronian has done with the new code anytime.

In relation to that, I think in order to vastly expand Celestia's Universal Object Identifier and Catalog, we must get information from all astronomical data and catalogs, as much of it as possible, and as such, make identifiers based on those other catalogs. For example, there's the General Catalog of Variable Stars, which is shown here: http://www.sai.msu.su/gcvs/gcvs/gcvs5/gcvs5.txt, which only focuses on all variable stars in the sky. It is the catalog that puts in star names like RR Lyrae, UY Scuti, VY Canis Majoris, etc. As such, I think the GCVS identifiers, if they are associated with any star in Celestia's other catalogs, should be included in there as well.

Aside from GAIA DR1 and DR2 catalogs, we can also add the 2MASS Catalog in Celestia as well. But all these are just my 2 cents

[pirogronian]

I think in order to vastly expand Celestia's Universal Object Identifier and Catalog, we must get information from all astronomical data and catalogs, as much of it as possible, and as such, make identifiers based on those other catalogs

For now I assumed UID is defined by data author. So Celestia code just read it or generate, if not provided. The rest is matter of cooperation between authors.

[Janus]

Keep each catalogs UID as is, for that catalog.
Within Celestia, those should be just another text field that is indexed.
Put each thing into a catalog made for that call of object, then index it.

I can understand the desire to put all data into a single in memory database.
However, speaking strictly from my own experience, which comes mainly from my troubleshoot repair diagnose work, that is not going to work as well as hoped.
To be efficiently searched, data needs to have structure, regularity.
I do not see how a single database is going to cover asteroids and blackholes, and have regularity.
If this one size fits all is what is going to happen, then I hope I am wrong.


Janus.

[pirogronian]

@Janus
Current implementation isn't better. The main difference is that stars have much less features then bodies and dsos have even less features than stars. I want to make all basic features avaliable for all objects. If need for features of specific class objects will emerge, I will do another, specialized database.

Added after 5 hours 25 minutes:
If anyone is interested, I complitely reimplemented octree with great performance boost (but still lower than with original) and one new bug. See github page for details

[Lafuente_Astronomy]

I will do another, specialized database.

I guess there should be a more specialized database. It could still be either the UID or part of Celestia's UID but it must be very specific enough, because all objects in Astronomy have many classifications and specifications

In short, even a single Celestia object will have lots of identities as a result. So, might as well make a more specialized database

Added after 5 minutes 51 seconds:
https://en.wikipedia.org/wiki/List_of_astronomical_catalogues

This is a list of Astronomical Catalogs used in Astronomy. Though the list looks impressive, with lots of catalogs and their abbreviations, I have a feeling that what I posted here is just a drop in an ocean of catalogs possibly being maintained by all astronomical institutions. Still, this list could be useful for when you want to take a look into some of the catalogs mentioned there and get some ideas for your more specialized database

[Lafuente_Astronomy]

Hello Celestians, especially to the devs

I'm currently making an improvement to my starnames.dat file in my Celestia, by adding those star names that are not included in Celestia but otherwise are named in other sources. I use the IAU's Star names, as well as some names from Stellarium. A few of the names I placed are just for fun only, like naming HIP 1 "First Identified Star Of The Hipparcos Catalog", HIP 217 "First Identified Star Of The Smithsonian Astrophysical Observatory Catalog" and so on. Either way, I'm having fun doing it.

However, the gist of this message is actually in relation to the starnames.dat file itself. In Celestia, it only allows the naming of stars with HIP Identifiers. So, if you can manage to make or improve the database to allow more identifiers, is it possible with you if you can improve the starnames.dat file to allow stars with other identifiers(AKA, no HIP Identifiers) to be named? Because there may be stars without HIP Identifiers that could have been given names or nicknames for the matter, like majority of the stars in the GCVS Catalog, as those stars were not discovered or identified by HIP, rather by other astronomical and stellar catalogs, thus giving them different identifiers and no HIP identifiers, resulting in my inability to give them their proper names, and thus, remaining present in Celestia with their other identifiers.

Let me tell you the reason why I ask for this change or modification: There is a certain neutron star named PSR B1257+12 in Virgo which has been given the name "Lich" by the IAU. Since that neutron star exists in Celestia, I tried to name it by adding its original name into the starnames.dat file, and then gave it the name "Lich". Upon opening my Celestia, clicking PSR B1257+12 does not include the name "Lich", meaning that the starnames.dat file does not allow any other identifier than HIP to be named. And since I'm that kind of person who wants to update my Celestia with star names as much as possible, I feel that all astronomical identifiers can, and must be included in the starnames.dat file so that they can be given names and thus, be properly identified as per the updates of the Astronomical Catalogs.

Hence, my request. But it's entirely up to you if you want to do it or not. I'm sure that it can be done, perhaps after making the database more dynamic and allowing more identifiers. But as I said, it's entirely up to you.

P.S it was discovered that Lich has a planetary system, making it a very rare neutron star with a planetary system, as well as the first confirmed discovery of exoplanets.

[pirogronian]

My curent code enables any non-colliding numeric identifier. It just assumes, for backward compatibility, that number less than 100000 is a HIP number. But I believe that original code works in the same way.

[onetwothree]

It's one of reasons why we what to change how catalogues are handled.

For your particular task you can use STC files instead.

[gironde]

What seems to be the role of starnames.dat:

Starnames.dat is a text file that lists the different names of stars to avoid repeating them all, in other extras files.
The main name in this file is the HIP number but one can also include the TYCHO (TYC) stars by using as identifier the inverted TYC number.
Example TYC 4006-980-1 will become ==> 1/00980/4006 ==> 1009804006:
1st group of the number (4 digits) will be the last of the identifier, here 4006
2nd group of the number (5 digits) will be the 2nd of the identifier, here 980 becomes 00980.
the 3rd group of the number (1 digit) will be the 1st of the identifier, here 1
(see viewtopic.php?p=141224#p141224)

Once a star is defined in the starnames.dat file, this star is used in the stc files (astronomical definition) by its main name
in starnames, and the other names of the star will be displayed in Celestia

Take HIP 98767, in starnames we can write:
(def by HIP)
98767: GJ 777 A: HD 190360: 2MASS J20033732 + 2953493: BD + 29 3872: HR 7670: IRAS 20016 + 2945: LHS 3510: SAO 88133: TYC 2153-02883-1: WISE J200337.97 + 295343.4
or (def by TYC)
1028832153: HIP 98767: GJ 777 A: HD 190360: 2MASS J20033732 + 2953493: BD + 29 3872: HR 7670: IRAS 20016 + 2945: LHS 3510: SAO 88133: WISE J200337.97 + 295343.4



Another problem in our Celestia is the extension given to this starnames file.
The .dat extension usually corresponds to a database. There is confusion with other .dat files:
hdxindex, CELINDEX format, HD catalog
saoxindex, CELINDEX format, SAO catalog
stars.dat, CELSTARS format,
starnames.dat, txt format
asterisms.dat, txt format
boundaries.dat, txt format

Can we not standardize the names of the barycenter ?

[onetwothree]

Can we not standardize the names of the barycenter ?

Could you explain what do you mean?

[gironde]

I wanted to respond to Lafuente_Astronomy on the subject of starnames.dat recalling its use.
I took the opportunity to comment on .dat files and on the use of barycenter more and more in the extras about stars and exoplanets. There are no set standards for the name of the barycenters and everyone does what he wants. It's a little anarchy because many of the barycenters take the name HIP of the star A.

I am checking all my addons of stars and exoplanets that I downloaded one day, to chase the duplicates. I break my head with all the barycenters.

The HIP designations were originally given for the stars studied by Hipparcos and not at a barycenter.

[Lafuente_Astronomy]

Well, not sure just how specific this problem is. Perhaps for developers and programmers like you, it's a much bigger problem than it is at face value. But for a simple guy like me, I only saw its incapacity of it allowing names to stars beyond HIP identifiers, or the numbers being assumed as HIP identifiers as a great hindrance to star naming as a whole.

What seems to be the role of starnames.dat:

Starnames.dat is a text file that lists the different names of stars to avoid repeating them all, in other extras files.
The main name in this file is the HIP number but one can also include the TYCHO (TYC) stars by using as identifier the inverted TYC number.
Example TYC 4006-980-1 will become ==> 1/00980/4006 ==> 1009804006:
1st group of the number (4 digits) will be the last of the identifier, here 4006
2nd group of the number (5 digits) will be the 2nd of the identifier, here 980 becomes 00980.
the 3rd group of the number (1 digit) will be the 1st of the identifier, here 1
(see viewtopic.php?p=141224#p141224)

Once a star is defined in the starnames.dat file, this star is used in the stc files (astronomical definition) by its main name
in starnames, and the other names of the star will be displayed in Celestia

Take HIP 98767, in starnames we can write:
(def by HIP)
98767: GJ 777 A: HD 190360: 2MASS J20033732 + 2953493: BD + 29 3872: HR 7670: IRAS 20016 + 2945: LHS 3510: SAO 88133: TYC 2153-02883-1: WISE J200337.97 + 295343.4
or (def by TYC)
1028832153: HIP 98767: GJ 777 A: HD 190360: 2MASS J20033732 + 2953493: BD + 29 3872: HR 7670: IRAS 20016 + 2945: LHS 3510: SAO 88133: WISE J200337.97 + 295343.4

I don't really use Tycho names, as although you gave a great way to add them in starnames.dat, it simply takes more time to type in Tycho numbers, especially if we have to reverse them first. However, expanding the starnames.dat also means allowing more identifiers to be included in the program to be allowed names by the starnames.dat file. Hence, it should not just be HIP or Tycho but all other identifiers, though identifiers with numbers only, like HIP, HD and SAO would probably contradict each other and thus, cause some problems. In fact, the example mentioned in my earlier post, PSR B1257+12(The Celestia version lacked the "B", and according to Wikipedia, the name PSR 1257+12 is now its former name, and its current name has the "B" on it) does not have any identifier that can be allowed to have a name in the starnames.dat file. That means HIP and Tycho, which would hopefully be fixed by improvements to the database in the dev's own time

Still though, as I said earlier, I'm just a simple man. I give you my hopes and wishes that you'll make Celestia even better than before. I know you'll be able to improve all things in time, and as such, I'll support you till the end.

[gironde]

Lafuente_Astronomy,

I agree with you. Including catalogs whose names contain letters or signs will be complicated. The key of each star must remain logical and simple.
It seems simple with HIP or HD but already less obvious with TYC where we tend to err on added 0 or 2MASS, IRAS, WISE …

[Janus]

@gironde

I would recommend that the barycenters get the main identifier.
Then then the components can have A, B, etc appended to indicate them.

Such as the way Sirius is handled right now.
Searching for Sirius lists the barycenter as the main name, with A & B as subcomponents.
This way the name would refer tot he over all structure, with additions to increase precision.

Like if a nearby system were to have planets.

Alpha Centauri:A:3 could be very earth like indeed.
It also makes the parsing code simple, the number of : is the number of layers, doesn't change with the OS, or with localization.
Should make search & match simpler, as well as consistent.
I would also like to see that idea expanded to include dataset/catalog source, such as.

HIP 71683:3
HD 128620:3
SAO 252838:3
Gliese 559:A:3

That way the start name could narrow the data sources.
Whether those sources are separate catalogs being the best catalogs that can be, or a single enormous catalog with numerous indexes to make subsets is independent of the consistency of the search.
It would allow for instance, a catalog or index of nothing nut extra solar planets.
ESP:???:3
With the ??? being either a normal star designation, or a specific extra solar planets list number, perhaps in order of discovery.

The colons also serve another purpose.
The ability to handle catalogs as spreadsheets
This enables either the reading or writing of files from a script.
Which opens the door to runtime alterations of star or other data.

Just some thoughts.


Janus.

[gironde]

Janus,

Using your Sirius example, this could be a solution but not all sites agree.
So Nasa Exoplanets Archive gives GJ 244 A the name of Sirius.
Wikipedia for Sirius speaks of a white star (GJ 244 A is a white star) but in the list of its other names indicates GJ 244 A / B (hence a barycenter).
It is not so simple.

But it's still important because the stars A and B will use the names of the center of gravity in their definition .stc ( OrbitBarycenter "Sirius") to signify that they orbit around this point.

GJ 244 A/B or Sirius A/B or an other thing …

in my starnames.dat

Code: Select all

32349:GJ 244 A:Sirius:2MASS J06450887-1642566 A:9 CMa:BD-16 1591:HD 48915:HR 2491:IRAS 06429-1639:LHS 219:SAO 151881:SD-16 1591:WDS J06451-1643 A:ALF CMa:ADS 5423


file stc

Code: Select all

#-------------------------------------------------
Barycenter "Sirius A/B"
{
   RA 101.287083
   Dec -16.716111
   Distance 8.583
}

Star 32349 # see starnames.dat
{
   OrbitBarycenter "Sirius A/B"

   SpectralType "A1V"
   AppMag -1.43

   EllipticalOrbit
   { # fully specified orientation
      Period         50.09
      SemiMajorAxis   6.73 # mass ratio 1.99:1.03
      Eccentricity   0.5923
      Inclination      97.51
      AscendingNode   161.33
      ArgOfPericenter   4.56
      MeanAnomaly      40.89
   }
}

Star "Sirius B:GJ 244 B:2MASS J06450887-1642566 B:9 CMa B:HD 48915 B"
{
   OrbitBarycenter "Sirius A/B"

   SpectralType "DA2"
   AppMag 8.44

   EllipticalOrbit
   { # fully specified orientation
      Period   50.09
      SemiMajorAxis   13.00 # mass ratio 1.99:1.03
      Eccentricity   0.592
      Inclination      97.51
      AscendingNode   161.33
      ArgOfPericenter   184.56
      MeanAnomaly      40.89
   }
}

#-------------------------------------------------


Alpha Centauri:A:3

Sorry but from there, I did not understand what you explain.

[Janus]

@gironde

My apologies, I try to be clear without being pedantic.
Let me try expanding on that particular example.

Alpha Centauri:A:3

In this case, "Alpha Centauri" can be either a star, or a barycenter.
The index should list it as a barycenter, but do not panic if it does not.
If the second part is a single letter, "A" in this case, then it points to a star orbiting a barycenter, acting as something of a double check.
Allowing the star to be looked up as "Alpha Centauri A" by appending the second part to the first, though one would hope the index was accurate and listed the first as a barycenter, not a star.
Which would then point you to the "A" component of the barycenter.
This would leave open the ability to index stars like "Alpha Centauri A" directly, so the correct "Alpha Centauri:A" could be substituted and the parsing be restarted.
We only need hope that no sub galaxy or cluster objects exist with more than 26 stars orbiting it directly.
The "3" indicates the third planetary body of the "A" component of the "Alpha Centauri" barycenter.

If we had Alpha centauri:3 instead, then the parser would know there is a problem since the first part is a barycenter, and the second a planet.
How to handle that error is a subject for discussion.

When getting to the planetary part, the point of a single letter earlier is shown, for instead of a number like "3", it could be a name, which is more than one letter.
Alpha Centauri:A:Alpha Halleys would refer to comet or asteroid orbiting Alpha Centauri A, which orbits the Alpha Centauri barycenter.
This provides error correction for the parser, for better error feedback to the user.
Whether that feedback is immediate, or in a log, to be determined by discussion.

Alpha Centauri:Alpha Halleys for instance could give an error that comets do not orbit barycenters, only stars.
Which gives rise to the need to cover objects like Oumuamua, which I have no suggestions on at the moment.

I hope I have managed to be less unclear, even if I did make up a planet and a comet to do it.


Janus.

[gironde]

Janus,

Yes, I understand better what you suggested.

We only need hope that no sub galaxy or cluster objects exist with more than 26 stars orbiting it directly.

...

Alpha Centauri:Alpha Halleys for instance could give an error that comets do not orbit barycenters, only stars.
Which gives rise to the need to cover objects like Oumuamua, which I have no suggestions on at the moment.

we must be wary of what we have not yet met in the universe

There is hardly anyone who knows anything like Oumuamua.

[pirogronian]

@Janus

You are proposing path from SSC files extended on stars. I like this idea and actually have thought about it, but under a general idea of "relative name", which have to be append to parent object name to provide full target object name. Currently this idea is not implemented in my branch. Yet

[Lafuente_Astronomy]

Lafuente_Astronomy,

I agree with you. Including catalogs whose names contain letters or signs will be complicated. The key of each star must remain logical and simple.
It seems simple with HIP or HD but already less obvious with TYC where we tend to err on added 0 or 2MASS, IRAS, WISE …

I think the solution to that is to allow bracketing in the starnames.dat file, in which the composition of identifiers can be separated by catalog, and is represented by adding some dash lines, adding some title words, can be both or any other methods of separating certain values from others, and thus keep their respective values separate from another. An example being that HIP 1 can be separate from HD 1 through those bracketing, so that those 2 identifiers won't refer to the same star, as HD 1 is HIP 422. So that we can write 1 under the bracket for HIP to refer to HIP 1 while writing 1 under the bracket for HD would refer to HD 1/HIP 422 instead. It can be like this(This is just an example, not sure if the current starnames.dat file can work with this):

Well, that can be a good idea for the devs to do, to make changes to the code that reads the starnames.dat file to allow the reading of brackets, and thus understand that the values within those different brackets are not the same as the others, and thus, reads them differently

Added after 56 seconds:
Yup, putting brackets in my starnames.dat file is not readable by the current code. My Celestia didn't load properly as a result

[Janus]

A quick glance through tokenizer.cpp indicates the only time '[' or ']' is parsed is during value assignment for arrays.

Multinaming is also cross indexing, this is part of the catalog issues being discussed.


Janus.