[Kstars-devel] Minor patches and a few clarifications

[Jason Harris]

Hi Akarsh,

> As far as I know, the MPC files include only the "observable" comets at any
> given time and are updated frequently. (That's what the website claims) So
> I believe that dropping the data for the remaining comets should not have
> any impact on the usability of KStars, because those comets are probably
> too faint for any sort of observation. Everytime a comet brightens up or is
> newly discovered, they update the elements.
> I've used the MPC elements frequently (under a desktop planetarium for
> Windows) and haven't had any trouble.

> However, if we wish to retain the capability of calculating positions of
> "not-observable", I think it should be possible to write a script to add the
> 'H' and 'G' parameters from IAU-MPC to the JPL catalog and keep both
> updated frequently, so that we don't display all the available comets in the
> sky!

> Your comments on this?

My objection to only including what is currently "observable" is that
we shouldn't assume the user just wants to view the sky for days near
the present day.  For example, what if I wanted to see the apparition
of Halley's comet in the 1970s?  Or what if I wanted to accelerate
time and focus on a particular comet to see when its next apparition
will be?

Adding G and H parameters will only work if the IAU MPC provides them
for all of the comets.  If we had their data for all of the comets,
then we could just use that file directly, rather than trying to
cobble the MPC and JPL data together.

> Can there be a better solution to this, that places the label just
> outside the object boundary? Or will that cause unnecessary overhead?

It seems unnecessary to me.  The current label placement sees okay
(except for Jupiter's moons, which is on my TODO, but I won't object
if someone beats me to it :)


On 1/30/08, Akarsh Simha <akarshsimha at gmail.com> wrote:
> Hi Jason,
>
> > I've intentionally oversaturate the colors to make them more obvious.
> > You can turn down the saturation easily in the Colors tab of the
> > Configuration window.  I think for the default we should leave the
> > saturated colors, but I'm open for further discussion on this.  Maybe
> > we could add another color scheme that attempts to be more realistic
> > than Moonless Night?
>
> Hmm... I think that adding a colour scheme is a good idea.
> I didn't know you could turn down the saturation. (Yet to explore fully!)
>
> > Yes, we can certainly switch to the MPC elements as published here:
> > http://www.cfa.harvard.edu/iau/Ephemerides/Comets/SoftwareComets.html
> >
> > However, the MPC files only include about 200 comets, whereas we now
> > have about 1200.  Do you know of a more extensive list of orbital
> > elements from MPC?
>
> As far as I know, the MPC files include only the "observable" comets at any
> given time and are updated frequently. (That's what the website claims) So I
> believe that dropping the data for the remaining comets should not have any
> impact on the usability of KStars, because those comets are probably too
> faint for any sort of observation. Everytime a comet brightens up or is
> newly discovered, they update the elements.
> I've used the MPC elements frequently (under a desktop planetarium for
> Windows) and haven't had any trouble.
>
> However, if we wish to retain the capability of calculating positions of
> "not-observable", I think it should be possible to write a script to add the
> 'H' and 'G' parameters from IAU-MPC to the JPL catalog and keep both updated
> frequently, so that we don't display all the available comets in the sky!
>
> Your comments on this?
>
> > No problem, I will apply the patch as soon as I can.  I just checked
> > the Steinicke NGC/IC catalog, which can be downloaded with the Get New
> > Stuff tool.  It correctly identifies NGC 1975 as a nebula, but also
> > misidentifies NGC 1977 as a cluster.  What should we do about this?  I
> > am a bit reluctant to modify Mr. Steinicke's catalog.  Maybe I can
> > just let him know that we are correcting this object't type.
>
> That should be fine.
>
> > Great, I'll apply this one as well.
>
> Thanks for that.
> Can there be a better solution to this, that places the label just outside
> the object boundary? Or will that cause unnecessary overhead?
>
> > Thanks for your contributions, I'm really excited to see so much
> > activity around KStars these past weeks :)
>
> My pleasure to contribute. :-)
> KStars is my primary software for any amateur observations nowadays, so I'd
> love to see it free of all bugs!
>
> Regards
> Akarsh.
>