[Kstars-devel] AuxData and QStrings in unnamed star objects

[Khudyakov Alexey]

On Sunday 07 of June 2009 01:06:41 James Bowlin wrote:
> I suggest using an existing index such as the Henry Draper (HD) index.
> If we have stars that are not in the index then we could use our own
> made-up negative numbers for those stars (for example) in that same
> field.  The benefit of this scheme is that the one data field would
> serve two purposes. It would be used to index the AuxInfo hash and it
> would also provide the HD index (for stars that have it).
>
> The downside of this scheme is that it would increase the size of the
> star data file and thus slightly increase the time it takes to load
> stars.  The only other thing I can think of is to hash on the J2000
> RA and Dec of each star (assuming no two stars have the same RA and
> Dec within the precision we currently store them in).
>
There are two variants of hash. Hand made numbers and combination of some 
parameters. Both have advantages and disadvantages

1. Hand made index. 
Pro: 
  * Simple.
  * No accidental collisions.
Cons:
  * Exrtra data to load and to store in memory
  * Addition of extra catalogs could be problematic. New UIDs must generated 
and absence of collisions for different stars must be ensured and same stars 
should get same UIDs and so on.

2. Hash made up from RA, dec and magnitude. Adding magnitude lessen collision 
chance. 
Pro:
  * No extra data needed.
  * It's possible to save memory by recalculating hash each time it's 
requested and not storing it. This is speed/memory tradeoff of course.
Cons:
  * Collisions are possible.
  * Problem with different catalogs is easied a little bit but still present.

Whole question with different catalogs is complicated and couldn't be solved 
easily. 

About size of hash. I think 32-bit is not enough. Some bits (say 4) should be 
reserved to indicate that object is star. This left only 268e+6 UIDs for 
stars. And AFAIR some catalogs already passed 1e+9 mark. So hash should be 64-
bits. It's enough for anything I believe. 



On Friday 05 of June 2009 15:19:54 Akarsh Simha wrote:
> But I have always wanted to have a UUID for every object in
> KStars. This might be hard stuff, but it would be nice if every object
> carried a few bytes of its own UUID. Maybe it's not required - except
> for unnamed stars - where it will be rather useful to have a UID, or
> even a legitimate catalog number attached.
>
If we want to separate AuxInfo from SkyObject it's not a good thing to do. It 
rather mandatory.