[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kstars-devel
Subject:    Re: [Kstars-devel] Ideas for Adding a Spatial Index to KStars
From:       Thomas Kabelmann <thomas.kabelmann () gmx ! de>
Date:       2006-06-20 21:19:13
Message-ID: 200606202319.14355.thomas.kabelmann () gmx ! de
[Download RAW message or body]

Hi James,

first of all I let me say, that I don't know much about your idea, due to lack 
of time, so perhaps I'm wrong. But it's a good idea of speeding up kstars.

As far as I understand, you want to put all objects of 1 region into 1 
SkyRegion. So we have a lot of SkyRegions with a lot of lists. The SkyIndex 
class is used to determine the right region.

I dislike the idea of breaking the current composite/component modell and I 
dislike the idea of having all data in 1 centralized class for maintainance 
and complexity reasons.

My idea would be, to combine the SkyIndex and the SkyRegion classes. So it 
could look like this:

class SkyRegion
{
	public:
		// add a point to the right region
		addPoint(SkyPoint *p);
		// return the list for the region
		QList<..> getRegionList(double ra, double dec);
		...
	private:
		// List of regions
		QList <Objects> regions;
}

The list of "Objects" is abstract. We could subclass from SkyRegion for the 
right type (StarObject, etc).

So every component could use an own SkyRegion object which just handles the 
objects of the component. There is a slight overhead, as every component has 
to determine the region, but I think it's worth. Perhaps the index can be 
delegated through the components, so there is no overhead anymore.

What do you think?

Regards,
Thomas
_______________________________________________
Kstars-devel mailing list
Kstars-devel@kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
[prev in list] [next in list] [prev in thread] [next in thread]