[Kstars-devel] Google SoC

Jan Kotek opencoeli at gmail.com
Tue Mar 25 23:51:52 CET 2008


Hi guys,
1) SQL is slower then binary data for starcharting (tested)
2) What about online data retrieve?
3) Most catalogs (GSC, USNOA) have its own indexing method with C
implementations. So please just add support for standart catalog
distributions. Do not reimplement it.
4) Star motions are irelevant for most of people. 99.9% cross
identifications are made in this century. Maybe you can just use wider
field for selecting data?

Regards,
Jan Kotek
www.kotek.net/opencoeli

On 3/25/08, James Bowlin <bowlin at mindspring.com> wrote:
> I agree with both of you that the magnitude limit is a more serious
>  problem.  But I disagree with the person who said we only need to
>  index the stars once per release.  I wish this were the case but it
>  is simply not true if we want to look far into the past or into the
>  future.  If KStars was only used to see the sky as it is right now then
>  I would agree that no re-indexing would be required.  But if we want to
>  ignore re-indexing then I think we should simply limit the time frames
>  we allow the user to select instead of showing them an incorrect view
>  and merely changing the date label.  I think people who are looking far
>  into the past or the future are often interested in seeing proper
>  motions.  It would be a bug if some high PM stars simply vanished due
>  to having the wrong index.
>
>  I also think we are in agreement that we need a scheme that works
>  well for the vast majority of stars and then we should tack on the
>  PM re-indexing as a correction.  But I think it is important to
>  keep the PM problem in mind when developing the underlying scheme
>  because we don't want to paint ourselves into a corner that would
>  require us to redo the entire scheme just to add the PM correction.
>
>  I think the next step to take is to get our hands on the actual star
>  data and shove it into a database such as MySQL.  My understanding
>  is that if we go down to 12th magnitude we will have between one million
>  and two million stars to deal with.  We current have about 125,000.
>
>  Below are some numbers for our current implementation.  Without having
>  the actual new star data I would guess that all of the star counts
>  below will need to be multiplied by 10x or 20x to get estimates of how
>  these numbers would change with the expanded catalog.
>
>
>  Our current re-indexing safety margin is 25 arcminutes which is slightly
>  less than half a degree.
>
>  fastest star we have has a pm of 7058 milliarcseconds/year
>
>    125 stars have pm > 840 milliarcseconds / year
>   1252 stars have pm > 304 milliarcseconds / year
>
>  The re-index interval for each group (in centuries) is:
>
>    25 * 60 * 10 / pm_max
>
>  Where pm_max is the highest pm in the group.
>
>      125 stars get re-indexed every   212 years.
>     1127 stars get re-indexed every 1,785 years.
>   125,000 stars get re-indexed every 5,000 years.
>
>
>  Uncommenting line 103 in highpmstarlist.cpp will report (on stdout)
>  how many stars actually changed index when the re-indexing occurs.
>  When I jumped forward 2,000 years, KStars said:
>
>   Re-indexed 22 stars at interval  212.5
>   Re-indexed 39 stars at interval 1788.6
>
>  If these results are typical then on average only 30 stars need to
>  be re-indexed every 1,000 years.  This will bump up to 300 or 600
>  with the expanded catalog.  If we divide the sky into 512 sections
>  then each section will average about one re-indexed star every 1,000
>  years which means the idea I mentioned previously of having separate
>  pre-computed lists of re-indexed stars seems very doable.
>
>  One possible (but probably not optimal) implementation would be to
>  add a binary flag for each star saying whether it should be displayed
>  or not and then let the small subset of stars that might need to be
>  re-indexed exist in multiple sections but they would have the display
>  flag set to true in only one section at a time.  Then when the time
>  changes, we would check a master list and simply flip the bits of only
>  the stars that are in memory that need to be re-indexed.  One benefit
>  of this scheme is it would allow us to reduce the re-indexing safety
>  margin down to zero but we would still need safety margins for other
>  factors.  If we store the stars in roughly fixed sized blocks of 500 or
>  so stars per block then we should be able to keep a list of block ids
>  and pointers so we can quickly find any star by its block id and its
>  offset into the block.  Swapping stars in from disk in blocks should
>  also drastically increase the efficiency when the user pans and zooms.
>
>
>  PS: I just realized Brian wants to go down to 16th magnitude.  I don't
>  know how many stars this means, I'd guess an addition factor of 10x or
>  20x.  It could be that we would want to organize the star data in three
>  (or more?) levels.  The top level might be a single file going down to
>  mag 6 or so.   Then the next level could be 512 files going down to mag
>  12.  The final level would go down to mag 16 and have 2048 or 8192
>  files.  Perhaps, users would be able to select at install time the
>  maximum magnitude they would ever want to see so we don't increase
>  their disk footprint unnecessarily.  Or perhaps the 16th magnitude data
>  could be available as a separate package.
>
>
>
>  --
>  Peace, James
>
> _______________________________________________
>  Kstars-devel mailing list
>  Kstars-devel at kde.org
>  https://mail.kde.org/mailman/listinfo/kstars-devel
>


More information about the Kstars-devel mailing list