Astro-satpass
view release on metacpan or search on metacpan
lib/Astro/Coord/ECI.pm view on Meta::CPAN
C<https://www.nctm.org/tmf/library/drmath/view/51879.html>, which
attributes it to the Geographic Information Systems FAQ,
L<http://www.faqs.org/faqs/geography/infosystems-faq/>, which in turn
attributes it to R. W. Sinnott, "Virtues of the Haversine," Sky and
Telescope, volume 68, number 2, 1984, page 159.
Unfortunately, as of early 2021 the National Council of Teachers of
Mathematics restricted the Dr. Math content to their members, but an
annotated and expanded version of the article on haversines is available
at
L<https://www.themathdoctors.org/distances-on-earth-2-the-haversine-formula/>.
If you want the original article, you can feed the URL
C<http://mathforum.org/library/drmath/view/51879.html> to the Wayback
Machine.
Prior to version 0.011_03 the law of cosines was used, but this produced
errors on extremely small angles. The haversine law was selected based
on Jean Meeus, "Astronomical Algorithms", 2nd edition, chapter 17
"Angular Separation".
This method ignores the C<station> attribute.
lib/Astro/Coord/ECI.pm view on Meta::CPAN
# We exclude anything with an elevation <= 2 degrees below our
# effective horizon; this is presumed to be not visible, since the
# maximum deflection is about 35 minutes of arc. This is not
# portable to (e.g.) Venus.
if ( $elevation > $horizon - TWO_DEGREES ) {
# Thorsteinn Saemundsson's algorithm for refraction, as reported
# in Meeus, page 106, equation 16.4, and adjusted per the
# suggestion in Meeus' following paragraph. Thorsteinn's
# formula is in terms of angles in degrees and produces
# a correction in minutes of arc. Meeus reports the original
# publication as Sky and Telescope, volume 72 page 70, July 1986.
# In deference to Thorsteinn I will point out:
# * The Icelanders do not use family names. The "Saemundsson"
# simply means his father's name was Saemund.
# * I have transcribed the names into 7-bit characters.
# "Thorsteinn" actually does not begin with "Th" but with
# the letter "Thorn." Similarly, the "ae" in "Saemund" is
# supposed to be a ligature (i.e. squished into one letter).
lib/Astro/Coord/ECI.pm view on Meta::CPAN
my $M = mod2pi( deg2rad( ( ( -.0001537 ) * $T + 35999.05029 )
* $T + 357.52911 ) ); # Meeus (25.3)
my $e = ( -0.0000001267 * $T - 0.000042037 ) * $T
+ 0.016708634; # Meeus (25.4)
my $E = $y * sin( 2 * $L0 ) - 2 * $e * sin( $M ) +
4 * $e * $y * sin( $M ) * cos( 2 * $L0 ) -
$y * $y * .5 * sin( 4 * $L0 ) -
1.25 * $e * $e * sin( 2 * $M ); # Meeus (28.3)
return $E * SECSPERDAY / TWOPI; # The formula gives radians.
}
=item $coord->equatorial ($rightasc, $declin, $range, $time);
This method sets the L</Equatorial> coordinates represented by the
object (relative to the center of the Earth) in terms of
L</Right Ascension> and L</Declination> in radians, and the range to the
object in kilometers, time being universal time. The object itself is
returned.
lib/Astro/Coord/ECI.pm view on Meta::CPAN
(Barycentric Dynamical Time), which is defined in terms of the
barycentre (a.k.a "center of mass") of the solar system. The two differ
by the relativistic effects of the motions of the bodies in the Solar
system, and are generally less than 2 milliseconds different. So unless
you are doing high-precision work they can be considered identical, as
Jean Meeus does in "Astronomical Algorithms".
For practical purposes, TT = TAI + 32.184 seconds. If I ever get the
gumption to do a re-implementation (or alternate implementation) of time
in terms of the DateTime object, this will be the definition of
dynamical time. Until then, though, formula 10.2 on page 78 of Jean
Meeus' "Astronomical Algorithms" second edition, Chapter 10 (Dynamical
Time and Universal Time) is used.
Compare and contrast this to L</Universal time>. This explanation leans
heavily on C<http://star-www.rl.ac.uk/star/docs/sun67.htx/node226.html>,
which contains a more fulsome but eminently readable explanation.
Unfortunately that link has gone the way of the dodo, and I have been
unable to find an adequate replacement.
=head2 Earth-Centered, Earth-fixed (ECEF) coordinates
lib/Astro/Coord/ECI.pm view on Meta::CPAN
=head2 Universal time
This term can refer to a number of scales, but the two of interest are
UTC (Coordinated Universal Time) and UT1 (Universal Time 1, I presume).
The latter is in effect mean solar time at Greenwich, though its
technical definition differs in detail from GMT (Greenwich Mean Time).
The former is a clock-based time, whose second is the SI second (defined
in terms of atomic clocks), but which is kept within 0.9 seconds of UT1
by the introduction of leap seconds. These are introduced (typically at
midyear or year end) by prior agreement among the various timekeeping
bodies based on observation; there is no formula for computing when a
leap second will be needed, because of irregularities in the Earth's
rotation.
Jean Meeus' "Astronomical Algorithms", second edition, deals with the
relationship between Universal time and L</Dynamical time> in Chapter 10
(pages 77ff). His definition of "Universal time" seems to refer to UT1,
though he does not use the term.
This software considers Universal time to be equivalent to Perl time.
Since we are interested in durations (time since a given epoch, to be
lib/Astro/Coord/ECI/Moon.pm view on Meta::CPAN
Although there's no reason this method can't be called directly, it
exists to take advantage of the hook in the B<Astro::Coord::ECI>
object, to allow the position of the Moon to be computed when the
object's time is set.
The computation comes from Jean Meeus' "Astronomical Algorithms", 2nd
Edition, Chapter 47, pages 337ff. Meeus gives the accuracy as 10
seconds of arc in latitude, and 4 seconds of arc in longitude. He
credits the algorithm to M. Chalpront-Touze and J. Chalpront, "The
Lunar Ephemeris ELP 2000" from I<Astronomy and Astrophysics> volume
124, pp 50-62 (1983), but the formulae for the mean arguments to
J. Chalpront, M. Chalpront-Touze, and G. Francou, I<Introduction dans
ELP 2000-82B de nouvelles valeurs des parametres orbitaux de la Lune
et du barycentre Terre-Lune>, Paris, January 1998.
=cut
sub time_set {
my $self = shift;
my $time = $self->dynamical;
lib/Astro/Coord/ECI/TLE.pm view on Meta::CPAN
} # End local symbol block
=item $mag = $tle->magnitude( $station );
This method returns the magnitude of the body as seen from the given
station. If no C<$station> is specified, the object's C<'station'>
attribute is used. If that is not set, and exception is thrown.
This is calculated from the C<'intrinsic_magnitude'> attribute, the
distance from the station to the satellite, and the fraction of the
satellite illuminated. The formula is from Mike McCants.
We return C<undef> if the C<'intrinsic_magnitude'> or C<'illum'>
attributes are C<undef>, or if the illuminating body is below the
horizon as seen from the satellite.
After this method returns the time set in the station attribute should
be considered undefined. In fact, it will be set to the same time as the
invocant if a defined magnitude was returned. But if C<undef> was
returned, the station's time may not have been changed.
note <<EOD;
The following test is from the example in the IDL Astronomy User's
Library source for posang().
EOD
TODO: {
# local $TODO = 'position_angle() is a work-in-progress';
note <<EOD;
This is one of the few of Meeus' formulae where he does not provide a
worked example. I am unable to duplicate the IDL Astronomy User's
Library posang() sample results, but neither is PyAstronomy's
positionAngle(), which claims to derive from the IDL implementation.
http://www.backyard-astro.com/deepsky/top100/07.html gives the position
angle from Mizar to Alcor as 72 degrees. PyAstronomy calculates 71 and a
bit using their SIMBAD positions as of July 21 2019, so I am testing
against that number.
EOD
u_cmp_eql( position_angle => [
( run in 0.793 second using v1.01-cache-2.11-cpan-3cd7ad12f66 )