[Kstars-devel] Index Out-of-Range error in HighPMStarList::reindex

[James Bowlin]

Wow.  This is all very interesting.

One minor point: I don't quite understand how the binary files could 
have had a different indexing convention from KStars and yet still 
work.  Wouldn't the sky be mostly devoid of stars when the screen was 
zoomed way in?

I don't object to using trixel ID's in the database, especially if
they will provide the benefits you list.  But please keep in mind that
we are going to want to start using different mesh levels once we get 
the larger catalogs which should be any day now.  As long as there is
an easy way to generate the binary files on different mesh levels then
I don't care if it looks less readable.  ISTM that reducing code weight 
would tend to make the code, at least, more readable.

If the compatibility problem with in the database is really only due to
the alphabetical order of "N" versus "S" then there are a couple 
of "quick fix" solutions.  One solution is to simply change those 
strings replacing "N" with "T" (for top) and replacing "S" with "B" 
(for bottom).  Another quick fix is to add another field that indicates 
which hemisphere a trixel is in and then add an index on that
hemisphere field combined with the trixel name field which can be used 
to force the trixels in the southern hemisphere to come before the 
trixels in the northern hemisphere.  But please don't feel obligated
to implement these ideas just because I mentioned them.  I think you
are now closer to code and the problems than I am.

It sounds like you have a clear grasp of the situation.  As long
as we can generate files for different mesh levels, I don't want
to micromange the internals of how you accomplish that.

On the other hand if you want to take this as an opportunity to stop
and rethink our indexing conventions, that would be fine with me too
and I would be glad to participate in that discussion.

I really appreciate you asking me but in this case I think the decision 
should be up to you.


-- 
Peace, James

On Thu July 10 2008, Akarsh Simha wrote:
> Was something that I had overlooked. The key to this problem was that
> the convention for numbering trixels within KStars differs from that
> on the binary files.
>
> So we are actually working with 3 conventions for trixel Ids - one
> within HTMesh, one within KStars and one within the binary files! I
> want to reduce this to two, by making the binary files follow the
> convention used within KStars. The thing preventing this is the MySQL
> database sorting. Since we store trixels by name in the database, and
> since "N" comes before "S" in the English alphabet, "N0000" will be
> the first trixel on the file, but this is actually trixel #256 within
> KStars!
>
> The quick and easy solution to this is to use trixel Ids in the
> database - this reduces a whole lot of code weight etc, but that
> would spoil the readability.
>
> I think I should go ahead and do this. But I want James' consent on
> this, because it might lower the readability of the database
> entries. Maybe we could instead add an additional column in the
> database to store the Trixel IDs (the KStars convention :D) and use
> that as the sorting key.