Fixed a bug first pointed out by Mikhail Zotov in a private communication,
who noticed that precession between B1950 to J2000 as done by KStars does not
coincide with the results given by SIMBAD (http://simbad.u-strasbg.fr/sim-fidl.pl). M. Zotov has not opened yet a bug in bugs.kde.org, so I have no bug
number to refer to in this commit.
The bug comes from the fact that conversion between coordinates in B1950
to J2000 (and viceversa) involves changing from (old) catalog FK4 to FK5,
and a simple precesion, as done by KStars is not enough.
To fix this bug I have used the following reference:
Smith, C. A.; Kaplan, G. H.; Hughes, J. A.; Seidelmann, P. K.; Yallop,
B. D.; Hohenkerk, C. Y.
Astronomical Journal, vol. 97, Jan. 1989, p. 265-279
The conversion between the FK4 catalog and the FK5 catalog requires 4 steps:
- Drop E-Terms in B1950 coordinates. In the past, the mean places of
stars published in the FK4 catalog included the contribution to the
aberration due to the ellipticity of the orbit of the Earth. These terms,
known as E-terms were almost constant, and in the newer FK5 catalog they
are not included.
- Precess from B1950 to 1984, January 1st, at 0h, using the parameters
given by the Astronomische Rechen-Institut.
- Apply the zero-point correction to the right ascensions to correct for the
equinox error of the FK4. This is done for 1984, Jan 1st, at 0h.
- Precess from 1984 Jan 1st at 0h, to J2000 using the new precessional
parameters.
This bug may seem not important since KStars produces a result which is
almost correct, but since the conversion between B1950 and J2000 is done
very frequently among astronomers it needs to be corrected. This bug affects
the precessional module and the galactic/equatorial conversion module. This
fix ONLY applies to the first module, although now it is straightforward to
correct the second module. I will do this later.
Since Stephan Kulow only accepts big bug fixes in the KDE 3.2 deep freeze
period in order to ensure a fast stability of the first relase, I commit
these fixes only to the KDE 3.1.4 branch, even knowing there may be no รง
KDE 3.1.5 release in the future. As soon as the KDE 3.2 branch is opened
for small bug fixes I will port this fix.
Improved determination of the time that an object sets or transits.
If the transit or set time is before the object's rise time, then it is
recomputed for the following day. These times appear in the popup menu,
and in the details dialog. Fix ported from HEAD, and applied to
debian_branch.
The atmospheric refraction at the horizon shifts altitude by
- 34 arcmin = 0.5667 degrees. This value changes if the observer
is above the horizon, or if the weather conditions change.
For the sun we have to add half the angular sie of the body, since
the sunset is the time the upper limb of the sun disappears below
the horizon, and dawn, when the upper part of the limb appears
over the horizon. The angular size of the sun = angular size of the
moon = 31' 59''.
So for the sun the correction is = -34 - 16 = 50 arcmin = -0.8333
This same correction should be applied to the Moon however parallax
is important here. Meeus states that the correction should be
0.7275 P - 34 arcmin, where P is the moon's horizontal parallax.
He proposes a mean value of +0.125 degrees if no great accuracy
is needed.
Changed "if" condition, because I had exchanged the Sun and the stellar
cases and added a bigger comment explaining why we use these values.
Backporting fix to TimeZoneRule::isDSTActive(). There was an improperly
nested compound if statement, which essentially made all Southern
Hemisphere locations report that Daylight Savings Time was always active.
Sorry to miss 3.1.3 :(
backporting fix for two precession-related bugs: (1) always precess focus
coordinates when date changes by a lot and tracking an object; (2) the URL
for requesting a DSS image (slotDSS()/slotDSS2()) must contain the J2000
coordinates, not the current coordinates. Fixed for the case where user
clicked on an object, but not for empty-sky clicks. The problem is that
there is no precessToAnyDate() function in 3_1_BRANCH; it is not
possible to determine J2000 coords from present-day coords without adding
this function.
