[Kstars-devel] branches/kstars/summer/kdeedu/kstars/kstars

James Bowlin bowlin at mindspring.com
Wed Jun 25 08:56:51 CEST 2008


On Tue June 24 2008, Akarsh Simha wrote:
> + Adding a field in the data section of both star data files to store
>   the limiting magnitude of the catalog.

We might also want the mesh level and the maximum (dynamic) stars per 
trixel in the header.  Putting the mesh level in the header will allow
us to have different mesh levels for different star catalogs.  including 
the MSpT will allow us to limit the total number of dynamic StarBlocks 
to:

    6 * ceiling( MSpT / stars_per_block) 

From this we can figure out the proper star density setting.  For 
example, if the brightest dynamic star is mag m_0, and we have agreed 
to not make more than N_blocks StarBlocks then we know that the maglim
can't be greater than m_0 when there are more than N_blocks trixel
visible.

Imagine removing the 100 brightest dynamic stars from each trixel.  Let
m_1 be the magnitude of the brightest of the remaining stars.  Then we
know that the maglim must be less than m_1 was long as there are 
N_blocks / 2 or more trixels visible. 

We can continue in this fashion, defining m_2 as the magnitude of the
brightest star after the 200 brightest (dynamic) stars have been removed
from each trixel.  This will give us another contraint on the maglim
depending on the number of visible trixels.

But maybe this is getting too complicated and we should instead just
put a simple limit on the star density.  Still, the reasoning above
could help us come up with a formula relating the star density setting
to the maximum number of StarBlocks needed.

One fly in the ointment is the fact that there is a significant variance
in trixel sizes so the worst case number of visible trixels for a given
aperture size is significantly different from the average number of
visible trixels for the same aperture.

These difficulties make me think that we might (someday) want to use
a indexing scheme other than HTM.  One interesting candidate is the
Q3C which is supposed to be faster than HTM:

http://www.sai.msu.su/~megera/wiki/SkyPixelization
http://lnfm1.sai.msu.ru/~math/docs/adass_proceedings2005.pdf

Although I suggest we stick with the HTM for now.

-- 
Peace, James



More information about the Kstars-devel mailing list