Celestia 1.7.0 Development Thread

[pirogronian]

Which number or value begins after 0xf0000000?

Yyy, 0xf000001? Sorry, I dont understand your question...

[Lafuente_Astronomy]

Yes, astrodb allows for any numeric id for astronomical object. But for backward compat there are two rules:
1. Id less than 999999 is interpreted as HIP nr.
2. Id between 999999 and 0xf0000000 is interpreted as TYC nr.

Based on the second statement, "Id between 999999 and 0xf0000000 is interpreted as TYC nr." The question is what's beyond 0xf000000000, and if so, is 0xf0000001 an identifier beyond TYC?

[pirogronian]

@Lafuente_Astronomy
But You already asked about that and I already answered:

Really nothing except pure abstract identification of object in external cross-indexes

[Lafuente_Astronomy]

Really nothing except pure abstract identification of object in external cross-indexes

I mean to say, define "Pure Abstract Identification of Object in external cross-indexes"?

Is it like we can type any number or letter value in any order we wish when we designate such objects? Like for example, typing "uihfdhf" can be used as an identifier?

[pirogronian]

Is it like we can type any number or letter value in any order we wish when we designate such objects? Like for example, typing "uihfdhf" can be used as an identifier?

No, it have to be non negative integer. For use it for Gaia catalog, we have to create new cross index with mapping UID <-> Gaia number. But to recognize Gaia catalog names, we have to implement new class in Celestia core code.

[LukeCEL]

Hi! Can I get a brief summary of what the current plan (and status) is with the database restructuring?

Thanks, LukeCEL

[pirogronian]

Can I get a brief summary of what the current plan (and status) is with the database restructuring?

Done
1. Fully implemented dynamic loading and searching of stars and DSOs.
2. Fully implemented dynamic reflection of changes of position and magnitude of stars & DSOs in octree structure.
3. Fully implemented name loading, erasing, searching and completion.
4. Fully implemented cross index loading and modyfing.

WIP
1. Make cross index able to work on ranges instead of 1-1 map.
2. Dynamic unloading of stars and DSOs (TODO parent/children handling).

TODO
1. Loading, searching, modyfing and erasing of bodies, locations and solar systems.
2. Loading, searching, modyfing and erasing of asterism (needed?).

Further plans
1. Enable user to define own catalogs (for example by defining its prefix or whole printf like pattern).
2. Make all objects (except of locations) "orbitable" and "phasable" (like bodies). IE we would be able to have galaxy orbiting around other galaxy within defined period of time, like planets, moons and spacecrafts can.

Currently code seems to work fine and be fully compatibile with master.

[Lafuente_Astronomy]

No, it have to be non negative integer. For use it for Gaia catalog, we have to create new cross index with mapping UID <-> Gaia number. But to recognize Gaia catalog names, we have to implement new class in Celestia core code.

Nice! I'll be waiting on that. Gaia Catalog Numbers should be recognized so that there can be additional starnames to the universal catalog

1. Enable user to define own catalogs (for example by defining its prefix or whole printf like pattern).

Despite that, there'll still be a universal object identifier catalog like the proposed Celestia Catalog right?

[pirogronian]

Despite that, there'll still be a universal object identifier catalog like the proposed Celestia Catalog right?

Of course. User-defined catalog means, for example, we may let user to register Gaia catalog with prefox/name GAIA and name pattern { "GAIA %i", <gaia_nr> }. Then user would be able to define cross index map from Gaia number to UID and tell Celestia to use it while searching Gaia nr for particular UID or vice versa.

Of course this is example only. I don't know yet how Gaia name format looks like...

[Lafuente_Astronomy]

Of course this is example only. I don't know yet how Gaia name format looks like...

If I remember from the time I used Gaia Sky, it seems to be a bunch of numbers. Also, does the catalog also covers other star catalog identifiers, i.e 2MASS, GCVS, GSC, PPM, SAO, etc?

[LukeCEL]

Thanks for the status update. Can I ask how much of these changes are backwards compatible? If possible, I'd like to do as little as possible with my star databases and cross indices. (Preferably nothing at all, since there are countless other stars.dat files out there).

I don't know yet how Gaia name format looks like...

There's a brief description of the Gaia identifiers here. They have a slightly more in-depth description here, but I don't know if it's applicable to Gaia DR2 as well as Gaia DR1.

Either way, the numerical identifiers are slightly different for both DR1 and DR2, and will be for the next releases.

[pirogronian]

Can I ask how much of these changes are backwards compatible?

Yes, You can Backward compatibility is one of main goals. So, no changes should be need in any file. Currently all original data files seems to be parsed and loaded without errors.

[Lafuente_Astronomy]

Either way, the numerical identifiers are slightly different for both DR1 and DR2, and will be for the next releases.

So, that means there'll be 2 different identifiers for objects in Gaia, and since there'll be 4 data releases, they may have an overall of 4 different identities, that is unless the ESO decides to make a complete and final Gaia Catalog based on the data of the 4 releases combined plus some other stuff?

[Sirius_Alpha]

A further consideration is that some stars are in Gaia DR1 and not in Gaia DR2, and some are in Gaia DR2 but not Gaia DR1.
I'm wondering if we should rely on the 2MASS catalogue for an internal ID and simply get our data from Gaia. At least 2MASS is consistent. For example, KOI-1029 has a DR2 but not a DR1 number. Though perhaps SIMBAD is incomplete. Though there are stars that have 2MASS ID's but have no Gaia DR #, and may not get one.

[Lafuente_Astronomy]

A further consideration is that some stars are in Gaia DR1 and not in Gaia DR2, and some are in Gaia DR2 but not Gaia DR1.
I'm wondering if we should rely on the 2MASS catalogue for an internal ID and simply get our data from Gaia. At least 2MASS is consistent. For example, KOI-1029 has a DR2 but not a DR1 number. Though perhaps SIMBAD is incomplete. Though there are stars that have 2MASS ID's but have no Gaia DR #, and may not get one.

Perhaps so. But is 2MASS itself a more complete catalog?

[Sirius_Alpha]

No. It has ~430 million sources, according to it's entry on VizieR (link). That's about a third of the Gaia catalogue. But it should overlap well with a reduced catalogue of stars, right? Unless we're intending on including a billion stars (which I would love), I'm not sure the matter of completeness is what counts here.

[Lafuente_Astronomy]

Unless we're intending on including a billion stars (which I would love)

I love that too. And I think they might put them all in there because for Authenticity's sake

[Janus]

Assuming for a moment someone puts a gigastar catalog for celestia together.
Then I hope that someone makes the database load in distance order so a spherical map can be maintained.
This would enable the user to limit how many stars are loaded by setting things like max memory to be used.


Janus.

[Lafuente_Astronomy]

Assuming for a moment someone puts a gigastar catalog for celestia together.
Then I hope that someone makes the database load in distance order so a spherical map can be maintained.
This would enable the user to limit how many stars are loaded by setting things like max memory to be used.


Janus.

Well, said topic is dealt here: viewtopic.php?f=4&t=19521. We may be going for modularization. But your idea is good as well. Hopefully the devs can work their way around that

Added after 6 hours 18 minutes:

This would enable the user to limit how many stars are loaded by setting things like max memory to be used.

As for that, probably certain code must be established first in Celestia. There's already a basic working code for that if I remember, in which objects will become boxes when the user gets far away from it, but it does not remove them fully, which is what the code should ideally do.

Added after 13 minutes 17 seconds:
viewtopic.php?f=15&t=18638
The post in question, though it changes the object to a box if it's close. Figures that if the code is improved in that, it could truly enable and disable objects depending on the distance, and thus be a feature in Celestia that can be changed in the settings by the user. It could be called "Limit Star Viewing Distance"

[pirogronian]

I hope that someone makes the database load in distance order so a spherical map can be maintained.
This would enable the user to limit how many stars are loaded by setting things like max memory to be used.

Something like this is a primary reason I started working on Celestia at all When finished, my branch astrodb should be able to unload objects on demand, what have to be a step towards automatic loading/unloading.

Of course (un)loading objects based on visibility would require new data format. In Gaiasky user can define own static octree on disk.