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

[James Bowlin]

On Wednesday 21 June 2006 19:18, Jason Harris wrote:
> o, here's my idea.  Add a function 'QList<int> SkyMap::htmCircle( SkyPoint 
> *p, double radius )' which returns the set of HTM region IDs that lie within 
> the bounds of the sky-circle defined by p and radius.  Then we add a function 
> 'void SkyComposite::computeVisibility( QList<int> &visibleIndexes )', which 
> takes this list of HTM IDs and uses them to build the list of objects in each 
> Component which are visible.  The SkyComposite version will just pass on the 
> request to its child Components.  The SkyComponent implementation looks like 
> this:
> 
> void SkyComponent::computeVisibility( QList<int> &visibleIndexes ) {
>     //visibleList() is a QList<SkyObject*> member variable that stores 
>     //the currently-visible objects
>     //objectHash is the QHash storing all objects of this type, indexed 
>     //by the HTM region ID
>  
>     visibleList().clear();
> 
>     foreach( int i, visibleIndexes ) 
>         visibleList() << objectHash[ i ];
> }
> 
> Then, in SkyComponent::update() and SkyComponent::draw() we can simply replace 
> all current instances of objectList() with visibleList(), and remove the 
> current visibility-checking code.
> 
> Is this feasible?

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 *>

My current proposal is to keep the composite classes (perhaps rename them)
and move this code and data into the composite classes.

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 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.  As I said in my reply to Thomas, I see
no reason to add extra complexity just to replace two lines of code with
one line of code.

I do feel we are rapidly converging to a solution.


-- 
Peace, James