[Kstars-devel] Dealing with Proper Motion in extended catalogs

[James Bowlin]

All of our current plans for extending our catalog involve having the 
fainter stars organized on disk first by spatial position (HTM index)
and second by brightness.  This will allow us to only load into memory 
the fainter stars that are on-screen or close to being on-screen.

If we want to be able to display the sky far forward and far backward
in time (1,000's of years) then we need to deal with the fact that the
HTM index of some stars will change with time.  If nothing is done to 
compensate for this effect then some high PM stars will very, very
occasionally just disappear.

A star that has a proper motion of 160 milliarcseconds/year will
move about 25 arcminutes in 10,000 years.  25 arcminutes is our current
re-indexing safety margin.  If we limit the times we display to
+/- 10,000 years of J2000 then at most only 3.4% of the stars in our 
current catalog would need to be re-indexed (using our current level-3 
mesh).  But most of those 3.4% wouldn't need to be re-indexed because
the size of the trixels in our level-3 mesh is roughly 10 degrees.

I've done a few more tests to try to measure how many stars from our
current (125,000 star) catalog would need to be re-indexed and it
appears that we would need about 1,200 re-indexes in a 20,000 year span.
This is slightly more than my previous estimate.

I propose that we put an arbitrary +/- 10,000 year limit on how far 
forward and backward in time KStars will go.  Every star will draw an 
imaginary line in the celestial sphere over the course of those
20,000 years due to its proper motion.  The last 25 arcminutes of each 
end of the lines should be cut off to account for the safety margin.
This means we only have to deal with 3.4% of our catalog.  We already 
have the tools available to create a list of all the trixels that such 
a line crosses.  When we create the files of stars ordered by position 
and then brightness, I propose that we include high PM stars in 
multiple lists so that if any trixel crossed by the 20,000 year line is 
visible, we are sure the star will be displayed.

If my above estimate is accurate then this will increase the size of
the data files by 1% and also increase the time to draw the stars by 1%.
The beautiful thing is that if we are willing to accept this 1% 
redundancy then no other work is required.  Problem solved!  I think it
would take longer to check for repeats than it would to simply draw 
them.

If, for some reason, it becomes unacceptable to draw a few stars more 
than once, then we can add a drawID flag to every star to ensure that 
each star only gets drawn once just like we are already doing for 
extended objects such as constellation lines and section of the Milky 
Way.

If we are willing to impose a +/- 10,000 year limit on the times KStars
will render the sky for (and if my estimate is accurate) then there 
exists a trivial solution for the proper motion problem that costs us
roughly 1% extra storage space and 1% extra drawing time.

Note that the penalty will increase for finer meshes by roughly a factor 
of two for each mesh level. Although the 25 arcminute safety margin will 
continue to reduce the number of re-indexes required.  We may want to 
use a level-5 mesh for a catalog that goes down to mag 16.  In this 
case we might want to reduce the maximum time span to compensate, for 
example only allowing times up to +/- 2,000 years, which should keep
the penalty under 1%.  I suspect that people who are more interested
in fainter stars are less concerned about the sky far in the past and
future.

Any thoughts?  Is a +/- 10,000 year time limit acceptable?


-- 
Peace, James