Edited to attempt greater clarity.
When I was looking at doing that, what I came up with is first having an internal index number that has nothing to do with any external DB at all.
What I mean is to have a separate DB for each catalog {HIP, HD, Gaia, whatever else}.
Then have a core DB which is primarily an index into the others.
Since the same star can occur in one or more catalogs, or perhaps not, structure the primary database for that.
Celestia core DB star Entry:
{
Celestia Index:
Celestia Type:
Celestia Name:
Active Data:
Load Data:
Load Name:
Hip Number:
Hip Data:
HD Number:
HD Data:
Tycho Number:
Tycho Data:
Gaia Number:
Gaia Data:
}
The core database would do nothing except provide a uniform interface to stellar data.
This would allow for independent catalogs to be loaded, whether they overlapped or not.
A default load would have to be designed of course, but that would still leave options for adjusting data use later.
Which could be something as simple as an index like CEL_DFLT and a series of catalog entries based on an enum, at least to start with.
Code: Select all
enum
{
HIP = 1;
Tycho = 2,
Draper = 3,
Gaia = 4
}
The display/render routine would get coordinates from here.
For index = 1 to CoreDbSize do Render(DB[index].ActiveData.pos);
Allowing star catalogs to be switched on command by simply changing ActiveData & ActiveName from Hip to Tycho to HD to Gaia.
Starting over would be as simple as copying LoadData & LoadName to Active from Load.
The same basic idea could be applied to other things, such as Asteroids, Comets, Asterisms, and whatever else.
The ability to switch out zodiac symbols could be very useful, It would be great for me because I have asterisms files showing stellar routes I Use for visualization of journeys already, and switching them out would be useful.
It would also open the ability to create them on the fly from scripts, which I would like a lot.
Imagine being able to record movements during a lecture that the students can then play back and explore for themselves.
All numbers, except universalcoord, stored on disc, and held in memory to be uint64_t or double, both of which use 8-bytes.
Even if working in float{single}, allocate double storage.
Strings to be kept in bytes alignments if feasible.
This simplifies reading data from disc, and stabilizes memory layout as well.
It also aids in the long term conversion to 64-bit by allowing memory alignment on 16 byte boundaries.
That should help porting to Android or other portable OS where predictability is required.
With predictable in memory structures, it open the possibility for the display subsystem to scan for coordinate data directly.
Text searches can then be simplified.
Turn greeking on if an individual wants it, while leaving in memory strings as ascii.
On a search, convert greeking back to plain text to make search simpler.
Janus.
EDIT: Attempted to add clarity I lacked before.
All I can do is hope I succeeded.
, are going to implement new Celestia runtime database, which could easly handle various astronomical catalogs with various types of objects (starsm, DSOs or planet bodies). As many new catalogs have enormous amount of data, we want to enable modularization of Celestia database and so we are fased with problem, how to do it properly and convenient for data/addons contributors.
