[Kstars-devel] Ideas for Adding a Spatial Index to KStars

[Jason Harris]

Hello,

James Bowlin wrote:
> Jason, I had already proposed a similar, but to my eyes, simpler solution
> here: http://lists.kde.org/?l=kstars-devel&m=115084753318093&w=2
> 
> Here is the code again:
> 
>     QList<int> indices = skyIndex->getView();
>     foreach ( int index, indices ) {
>         foreach ( StarObject *curStar, region[index] ) {
>             ...
>         }
>     }
> 
> Here "region" is a static member in the StarObject class that is an array
> of QList<StarObject *>
> 
No, it doesn't belong in StarObject.  StarObject encapsulates an 
individual star.  StarComponent is the ensemble of all stars.  So the 
"region" data member doesn't have to be static, because there's only one 
StarComponent object.

> I like your idea of using a QHash at least for sparse objects.  It might
> also be really good for objects that move from one region to another.
> 
I think we should use one container class for all Components, at least 
at first.

> I think your proposal will work, but I do think it brings in an unneeded
> level of complexity.  I think the code I had previously posted is better
> because it is simpler and faster.  
Ok, I see that we don't need a visibleList() member in each Component, 
because your double-loop method above makes it unnecessary (see revised 
pseudocode in my previous mail).  Other than that, our code suggestions 
are very similar.  What you call "region[]", I called "objectHash[]" 
(which is more indicative of what the thing actually is, IMO).

The other difference is, whereas I passed a QList<int> reference as an 
argument to provide the list of visible HTM indices, you call 
"skyIndex->getView()"  What do you think about naming this function 
something more descriptive, like visibleIndexes() or viewIndexes()?
Anyway, I still think it's a good idea to pass the list of indexes as an 
argument to the draw function; that way the Components don't have to 
know about SkyIndex.

> I do feel we are rapidly converging to a solution.
> 
Yes, me too.  Maybe we should work up some class declarations so we can 
really see what we're talking about.  For example, what functions and 
data will the SkyIndex class contain?  I can't help wondering whether we 
can just add some data and functions to SkyMap instead of having another 
class.  SkyMap is already a very large and complex class, though.  Maybe 
what I really mean is that the SkyIndex object should be a member of SkyMap.

Anyway, past my bedtime again :)

Jason