[Kstars-devel] Binary star data loading accomplished in Branch!

[James Bowlin]

On Tue June 3 2008, Akarsh Simha wrote:
> > > + Storing a pointer to the spectral type string in
> > > SkyObject::SpType, instead of the string itself.
> >
> > This is a very minor point but I don't understand why you did this.
> > Wouldn't it be better (faster, smaller) to store the string itself
> > instead of a pointer?
>
> That was required so that we don't segfault when we do a memcpy(). I
> only have a vague idea of how this saved us from segfaulting. I
> notice that QString stores the data as a pointer to the data, so we
> might be overwriting the same thing, but I don't know why it
> segfaulted.

Yes, A QString could be a problem.  When you said "string" I though you
meant char[size].  Those QStrings are a big PITA.  Ideally, we could 
store the SpType as a char[size] in the StarObject and then do any 
internationalization or translation when we are actually outputting the
data to the screen (assuming this is a very infrequent event).

If the dms'es are stored in the SkyPoint as *values* then there should 
be no problem.  It is only when there are pointers (or references) in 
the data structure that we run into a problem.  If they are stored by
value then we might need a SkyPoint::init() routine to makes sure they
get properly re-initialized when we load in new RA and Dec values. 

As you said, these fields in SkyObject, could all be problematic:

    QStringList ImageList, ImageTitle;
    QStringList InfoList, InfoTitle;
    QString userLog;

I agree with you that SkyObject::name, ::name2 and ::longName would be
better (for our purposes) as pointers.  Then all the unnamed stars would
have pointers to the same set of names and named stars would have their
own pointers.

The other QString and QStringList members of SkyObject are more of a 
problem.  If all of these fields will be required for unnamed stars 
then we will have to take evasive action.  

IMO, the best solution (for the long term) would be to create an AuxInfo
structure that contains those fields and in the star (or SkyObject) just
have a pointer to AuxInfo that is normally NULL.  Then when any of those
fields are needed a new AuxInfo object is created and the pointer is 
filled in appropriately.  Unfortunately, even this will break when we 
swap out a star and then later swap it back in.

This means we need to find out which of these fields are required for 
the unnamed stars that will be loaded dynamically.  If any of these 
fields will be needed then we need to know what is supposed to happen 
to them when we swap stars in and out.  If the information in these 
fields needs to be retained, we need to have a unique ID for every star 
and store the AuxInfo in a hash keyed off of this unique ID.  This
is assuming that relative few stars will need to have any of those 
fields filled in.  If this is our own ID, we don't have to store it
in the StarData structure.  We can use a combination of the trixel 
number and the position of a star in the list to make a unique ID.
For example, the highest 10 bits could be the trixel and the remaining
22 bits could be based on the order within each trixel.  This would
allow over 1 million stars per trixel which should be ample for now.

We will need input from Jason before moving forward here.

> > I don't think adding the HD number will help solve this problem,
> > but I think it is a good idea to have the HD number in the starname
> > file anyway for other reasons (error detection).
>
> Will a HD number not help, because it cannot be searched easily in
> the starnames.dat file?

I think having a unique ID for every named star would solve the 
initialization problems but there are other problems that will only get 
solved by keeping the named stars in a separate data structure.  

> One solution is to put a UID in the name data file, as I mentioned
> earlier, and quickly look that up. The HD number, as I infer from
> this source,
> http://www.willbell.com/software/hypersky/hd.htm
> goes upto a maximum of about 360000. We could use the remaining bits
> to hold a UID for named stars. The lower 19 ~ 20 bits could be
> provided for the HD numbers and the upper 11 ~ 12 bits for the UID
> for named stars. How does this work?
>
> That way, we can duplicate star entries and still be able to look up
> star names randomly, by fseeking to a position that we can compute
> based on the sequentially assigned UIDs.

I agree with you in theory that we could have named stars amongst the
stars that get dynamically loaded if we keyed off of a unique ID.  But
if we were to do that then don't want to do an fseek for each named 
star.  Instead we should store the (very small) list of non-global 
names in a simple QHash keyed off of the ID number.

But the problem is that this doesn't necessarily solve all of our 
problems with named stars.  I think there might be other lingering 
problems that keeping the named stars in a separate list will avoid.

IMO keeping the named stars in a separate list will be simpler, easier
to implement (all the code already exists, you just have to write the 
StarBlock code which you will have to write anyway) and less likely to
interact badly with the rest of KStars.  But I'm not going to insist 
that you do it my way.

There is probably more work you can do for now, but we really need to 
find out ASAP from Jason what he wants to do with the QString and 
QStringList SkyObject fields in the dynamically loaded unnamed stars.  

There might be other possibilities but three options I see now are:

   1) Just ignore them because will we never use them.

   2) Use them temporarily but let them be erased if stars are swapped
      out.

   3) Use them and remember the stored values even if stars get swapped
      out.

Even if we can't immediately implement what Jason wants, we want to know
what it is that he wants so we can incorporate the hooks into our 
design.

I wonder if we might want to create an UnnamedStar class that subclasses
directly from SkyPoint and bypasses SkyObject.

-- 
Peace, James