[Kstars-devel] Improvements to Alt. vs. Time feature

[Akarsh Simha]

Dear colleagues and users,

I've made some improvements to the alt. vs. time feature, most notably
the display of a lunar skyglow in addition to the sunlight; also the
gradients are more faithful to the timings of sun rise/set and
astronomical twilight. The reason for this mail is that I'm leaving
some of the bug-investigation and feature-completion half-finished
before I return to work on this, don't know when (could be tomorrow,
could be next month). The undone work is up for grabs, the easy ones
could be pushed as GCI tasks, otherwise this email serves as a
documentation for myself in the future to fix them. Let me know if you
want to work on them. No major regressions introduced, one minor
regression.

1. Regression: The main alt. vs. time tool no longer shows the current time line
Fix: Just need to supply AVTPlotWidget with the geo location using
AVTPlotWidget::setGeoLocation( const GeoLocation * );
See ObservingList::plot for an example.

2. The main alt. vs. time tool does not inherit the lunar skyglow feature
Fix: Need to glue data from KSAlmanac to AVTPlotWidget. Also need to
make a checkbox on the UI to enable/disable the moon plots as it can
be useful or a hindrance depending on what the user is doing.
The better way might be to do 3 intsead

3. Get AVTPlotWidget to contain and use a KSAlmanac, so we don't have
to set a gazillion variables before it can work. Makes it more
user-friendly. Reduces code-duplication
Fix: Transfer code of the form seen, for example in
ObservingList::plot, into AVTPlotWidget itself. Simplify code like
ObservingList::plot

4. The set time shown (at least for the moon) in the details dialog is
different from in the popup menu, especially around full moon. The
reason is that the popup menu shows the closest rise and set times
(supposedly) to the current time (see SkyObject::riseSetTime), whereas
the detail dialog always wants the set time to be later than the rise
time. For example, in a situation where the moon sets in a few
minutes, but rises tomorrow, the popup menu will show the impending
set time of the moon, whereas the detail dialog will show the set time
for the next day. This must be explained clearly by indicating (+1d)
or something to that effect on the set time whenever applicable. This
change is harder than it sounds because one will need to modify
riseSetTime etc. to return QDateTime rather than QTime etc.

5. Introduce an indelible UTC offset in KStarsDateTime
It should not be possible to convert KStarsDateTime from UTC to LT,
but only represent it in any of the ways... if this can be done, it
reduces possible bugs. A strong form of date time will carry the time
zone metadata with it, so it is factually complete. This would be nice
to have.

6. Moon rise set time Bugs: These (and the next) are probably the hardest.
Find out why that sometimes, the moon rise/set times from KSAlmanac
are incorrect on the first shot, but correct themselves thereafter.
This is seen as a change in the length of the lunar skyglow gradient
in the AVTPlotWidget in the observation planner upon clicking
different objects immediately after updating the date. To reproduce:
Set Dec 25 2015, Austin TX as date/location in observation planner and
hit update. Then click two or three wishlist objects in succession.
Also, some moon rise/set times seem to be incorrect. (Possible
location/date for which this was detected: Rovaniemi, FI; Sep 22 2015)

7. KSAlmanac rise set/time issues. Is addDays(1) necessary?
KSAlmanac seems to produce entirely different rise/set times from the
popup menu / detail dialog. The discrepancy between the latter two is
understandable, but this one really needs investigation. (Noticed
large differences for:  Rovaniemi, FI; Sep 22 2015)

Regards
Akarsh