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

[James Bowlin]

Jason,

I realize you are very busy with other things right now.  I really
appreciate you giving me feedback on my ideas so quickly.  Thanks.


On Tuesday 20 June 2006 01:15, Jason Harris wrote:
> I agree, no point in doing that.  We could also make them private  
> members and use the "friend" keyword to specify classes that are  
> allowed to access these members.

> Actually, I'm pretty sure you can avoid this by putting forward class  
> declarations in the headers, and putting the #includes in the source- 
> code files.  This may require that the QLists contain pointer types,  
> IIRC.

Friends and forward references: sweet!


> Why do you want a list of actual StarObjects?

I just wanted to present it as an option for the stars that might reduce
memory usage by storing the objects directly instead of pointers to the
objects.  It sounds like this might cause some complications so I suggest
we just do it all with pointers for now which sounds easier.

> > This would change to something like:
> >
> >     StarObject *o = new StarObject( ... );
> >     o->EquatorialToHorizontal( data()->lst(), data()->geo()->lat() );
> >     SkyRegion *region = skyIndex->indexPoint( o->ra(), o->dec() );
> >     region->append( o );
> >
> I'm kind of missing why we are keeping the SkyComposite hierarchy  
> here.  Your SkyRegions have a simple, flat scheme for storing the  
> objects in its own type-specific lists.  So there would seem to be no  
> point in having the SkyMapComposite at all.  An alternative would be  
> for each SkyRegion to have its *own* SkyMapComposite.  Basically, use  
> the existing hierarchical object-storing scheme instead of your  
> simple flat storage scheme.  I don't see the need to keep both, but  
> it's late so maybe I'm missing it :)

I think there may be up to three separate issues here.

First, I think the index/region model should start life side-by-side with
the component/composite model so we can move components over to the index
one at a time.  Also, if we get tired or we decide the index/region model
does not fit well for some existing components we can just leave them as
they are for good.
 
The second issue is the idea of whether would should use QLists of objects
or composites inside the SkyRegion.  I think we should try it with QLists
(or other lists if they are more appropriate).  I don't think the composites
would add any value in the index/region model, they would just be another
wrapper around the QLists.  The functions that are currently in the
composites to read the data files could be moved to static class functions
inside what are now the component classes themselves.  If the need arises,
we can always use composites in the SkyRegion instead of lists, and we can
mix and match, some objects can have lists in the SkyRegion and some can
have composites.  But at the end of the day, I think the lists will suit
our needs the best which is why I want to try starting out with them.

This brings up the third issue:  will the index/region model replace the
component/composite model (at least for the objects in the index)? IMO,
the answer is yes, things drawn with the index/region model will no longer
need their ...Composite class.  If everything goes into the index then the
SkyMapComposite structure can eventually go away, but I am in no rush to do
this.  If things that are moved into the index lose their ...Composite class
then the "Component" suffix on their class names is no longer needed.

So I think we should rename classes as they are moved into the index model.
Most of the time just dropping the "Component" suffix will suffice.  For the
stars, we would be just left with a "Star" class, which I think is unclear.
But in that case, I think the drawing code for stars should be moved back
into the StarObject class.  This feels good to me.

I really like having all of the drawing classes (except the stars) in their
own subdirectory.  But whether this should be the existing skycomponent/
directory or some other directory, I just don't know.  I would tend to start
out in the existing subdirectory and then move over to a new directory when
a good name came to me.  On the other hand, we do need to stick the SkyIndex
and SkyRegion files somewhere.  Maybe you have an idea of where we should
put things.

BTW: I re-measured the timing for indexing points in a level-4 and level-5
HTM, they were both able to do over 150k points per second so I think we
should start with just creating the indices on the fly when we load the data.
If it significantly slows down the start up of the program, I'm confident
I'll figure out how to speed it up since starting up KStars is part of my
development cycle.


-- 
Peace, James