view release on metacpan or  search on metacpan

lib/Astro/Coord/ECI.pm  view on Meta::CPAN

Right Ascension is input to and output from this module in radians.

In astronomical literature it is usual to report right ascension
in hours, minutes, and seconds, with 60 seconds in a minute, 60
minutes in an hour, and 24 hours in a circle.

=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
specific), this is technically wrong in most cases, since leap seconds
are not taken into account. But in the case of the bodies modeled by
the Astro::Coord::ECI::TLE object, the epoch is very recent (within a
week or so), so the error introduced is small. It is larger for
astronomical calculations, where the epoch is typically J2000.0, but the
angular motions involved are smaller, so it all evens out. I hope.

Compare and contrast L</Dynamical time>. This explanation leans heavily
on C<http://star-www.rl.ac.uk/star/docs/sun67.htx/node224.html>.
Unfortunately that link has gone the way of the dodo, and I have been
unable to find an adequate replacement.

=head2 XYZ coordinates

See L</Earth-Centered, Earth-fixed (ECEF) coordinates>.

=head1 ACKNOWLEDGMENTS

The author wishes to acknowledge and thank the following individuals and
organizations.

Kazimierz Borkowski, whose "Accurate Algorithms to Transform
Geocentric to Geodetic Coordinates", at
L<http://www.astro.uni.torun.pl/~kb/Papers/geod/Geod-BG.htm>,
was used for transforming geocentric to geodetic coordinates.

Dominik Brodowski (L<https://www.uni-saarland.de/lehrstuhl/brodowski/team/prof-dr-dominik-brodowski-llm-upenn.html>), whose SGP C-lib
(available at L<https://www.brodo.de/space/sgp/>) provided a
reference implementation that I could easily run, and pick
apart to help get B<Astro::Coord::ECI::TLE> working. Dominik based
his work on Dr. Kelso's Pascal implementation.

Felix R. Hoots and Ronald L. Roehric, the authors of "SPACETRACK
REPORT NO. 3 - Models for Propagation of NORAD Element Sets,"
which provided the basis for the Astro::Coord::ECI::TLE module.

T. S. Kelso, who compiled this report and made it available at
L<http://celestrak.org/>, whose "Computers and Satellites" columns
in "Satellite Times" magazine were invaluable to an understanding
and implementation of satellite tracking software, whose support,
encouragement, patience, and willingness to provide answers on arcane
topics were a Godsend, who kindly granted permission to use his
azimuth/elevation algorithm, and whose Pascal implementation of the
NORAD tracking algorithms indirectly provided a reference
implementation for me to use during development.

John A. Magliacane, whose open-source C<Predict> program, available at
L<https://www.qsl.net/kd2bd/predict.html>, gave me a much-needed leg up
on the velocity calculations in the C<azel()> method.

Jean Meeus, whose book "Astronomical Algorithms" (second edition)
formed the basis for this module and the B<Astro::Coord::ECI::Sun>,
B<Astro::Coord::ECI::Moon>, and B<Astro::Coord::ECI::Star> modules,
and without whom it is impossible to get far in computational
astronomy. Any algorithm not explicitly credited above is probably
due to him.

Dr. Meeus' publisher, Willmann-Bell Inc, which kindly and patiently
answered my intellectual-property questions. Willmann-Bell ceased to be
a separate entity in 2021, but their publications, including Dr. Meeus'
book, are still available through Sky and Telescope&apos;s Willmann-Bell
imprint at L<https://shopatsky.com/collections/willmann-bell>.

Goran Gasparovic of MIT, who asked for (and supplied information for)
the ability to display results in apparent equatorial coordinates,
rather than azimuth and elevation.

Dr. Kevin Cornelius of Ouachita Baptist University, whose handout
"Relationships Among Unit Vectors" for his Mathematical Physics class
(PHYS 4053) provided a much surer and more expeditious way to handling
velocity conversion from spherical to Cartesian (and vice versa) than my
own ancient and rickety matrix math.

=head1 SUPPORT

Functionality involving velocities is B<untested>, and is quite likely
to be wrong.

Support is by the author. Please file bug reports at
L<https://github.com/trwyant/perl-Astro-Coord-ECI/issues> or in
electronic mail to the author.

=head1 SEE ALSO

The C<Astro> package by Chris Phillips. This contains three
function-based modules: L<Astro::Coord|Astro::Coord>, which provides
various astronomical coordinate conversions, plus the calculation of
various ephemeris variables; L<Astro::Time|Astro::Time> contains time
and unit conversions, and L<Astro::Misc|Astro::Misc> contains various
calculations unrelated to position and time.

The B<Astro-Coords> package by Tim Jenness. This contains various modules
to do astronomical calculations, and includes coordinate conversion and