On Fri Nov 14 14:05:04 2008, griscom@suitable.com wrote:
Show quoted text> At 1:52 PM -0500 11/14/08, Tom Wyant via RT wrote:
> ><URL:
http://rt.cpan.org/Ticket/Display.html?id=40899 >
> >
> >On Fri Nov 14 08:00:44 2008, griscom@suitable.com wrote:
> > > Beyond that, it would have helped me if there was more overview
> >> information, giving context to exactly what the process should be.
> >> Yes, you provide a whole Satpass application that uses the packages,
> >> but frankly for us non-Perl-gurus it's really difficult to trace how
> >> a Perl program works. More simple demonstrations would also have
> >> helped.
> >>
> >
> >I'm not sure exactly how to respond here. If I expand the SYNOPSIS too
> >much it becomes the DETAILS.
>
> I found it difficult to understand the overall work flow for the
> system. Just what is the "data" that is returned by the
> Astro::SpaceTrack package? What is returned by
> Astro::Coord::ECI::TLE->parse()? Why would I want to aggregate it?
> When do I need to specify login info to the Astro::SpaceTrack
> package? Where does Astro::SpaceTrack->retrieve() get its info?
>
> I think I was missing the forest for the trees. Until I got your demo
> code working I really had no clue as to how it would all function.
> After that, I just started stepping through the code and watching the
> values.
>
> FYI, my access route to all this was search.cpan.org.
Thanks. It's the old bootstrap problem, plus the problem that trivial
examples may not be helpful, and significant examples may not be trivial.
I could certainly go into each of the questions you ask, but if I were
to go into them in the comments in the sample, maybe you would not be
able to see the code for the comments. I have seen SYNOPSIS sections
with brief comments and extended notes after the code. How does this
strike you?
Maybe I should go into the questions now, and we can figure out where
the answers go later.
Show quoted text> Just what is the "data" that is returned by the
> Astro::SpaceTrack package?
The Astro::Coord::ECI::TLE package implements a model (several models,
actually) of a satellite in orbit around the Earth. This is not simply a
Keplerian ellipse, because of a number of factors such as oblateness of
the Earth, atmospheric drag (believe it or not!) and orbital resonance
(for 12- and 24-hour orbits anyway), and possibly more.
The net result is that the model needs data on which to work, and the
job of the Astro::SpaceTrack package is to retrieve this data from any
of a number of possible sources. The standard representation of the data
for a given satellite is either two or three lines of text which owe
their format to the days of 80-column punched cards. This format is
called "TLE" for "Two Line Element". The three-line variant is sometimes
called "NASA TLE", though you could simply take the "T" to mean "three"
in this case. See
http://celestrak.com/NORAD/documentation/tle-fmt.asp
if you want the gory details of the format.
NORAD (among others) generates this data by observing all the satellites
and other stuff (spent boosters, astronauts' lost gloves, and so on),
and running a big regression program for each to generate TLE data that,
when plugged back into the model, best predicts the observed locations
of the satellite. This data is characterized by an "epoch", which is the
"as-of" date of the data.
The data has (as you discovered) a limited shelf life. How limited
depends on the specifics of the individual satellite. Typically it's
weeks or even months either side of the epoch (though of course
prediction quality suffers). For a space shuttle on its first coasting
arc, though, it's a day or so.
What I think happens in the specific case of the first coasting arc of
the Space Shuttle is that if you run that orbit back in time, you
essentially have to run an unusually high atmospheric drag backwards as
well, and after a couple days the model thinks the shuttle came in on an
escape orbit, which the model can't deal with. The cryptic error message
reflects the fact that at the next step in the calculations the model is
going to attempt to take the square root of a negative number.
Show quoted text> What is returned by
> Astro::Coord::ECI::TLE->parse()?
This is the code that takes the TLE data (returned by Astro::SpaceTrack)
and makes it into Astro::Coord::ECI::TLE objects (or
Astro::Coord::ECI::TLE::Iridium objects, if that's what the data you fed
it actually represents).
Show quoted text> Why would I want to aggregate it?
Well, one answer is because the code "just growed".
Most sources of satellite orbit data typically provide a single set of
data per satellite. The NASA Human Spaceflight web pages at
http://spaceflight.nasa.gov/realdata/elements/ provide multiple sets for
the same object.
As originally written, the code that used this data simply scraped the
web page and picked the "best" element to return. "Best" was defined as
"most recent epoch before the current time, or the earliest epoch if the
current time was before any of the posted date. This caused the same
kind of error you encountered, only at that point the error message was
even more cryptic.
Once I understood how and why the code was failing, I had to figure out
what to do about it. The solution I came up with was a container object
(Astro::Coord::ECI::TLE::Set) that would hold any number of individual
Astro::Coord::ECI::TLE objects that represent the same satellite at
different points in time. The container would expose all the methods of
the contained objects, and dispatch any method calls to the "best" one,
with "best" being defined pretty much the way it was in the previous
paragraph. Any method that set the time, of course, had to be overridden
to also select the "best" object.
The net result is that Astro::SpaceTrack give you a couple dozen lines
of text representing one or two orbiting bodies. The
Astro::Coord::ECI::TLE->parse() method turns these into a dozen or so
Astro::Coord::ECI::TLE objects representing one or two orbiting bodies.
And finally Astro::Coord::ECI::TLE::Set->aggregate() generates one or
two Astro::Coord::ECI::TLE::Set objects, each containing the
Astro::Coord::ECI::TLE objects for exactly one satellite. When you call
pass() on the ::Set object, it uses whichever is the "best" object for
whatever time it's working on.
If you call 'set(backdate => 0)', it (among other things) tells the
pass() method not to do any calculations for times earlier than the
earliest data epoch it has access to.
Show quoted text> When do I need to specify login info to the Astro::SpaceTrack
> package?
When I document this, the answer will probably be something on the order
of "See the Astro::SpaceTrack documentation", though a quick look says
that first I'll need to make sure that this is actually documented
there. Briefly, one of the sources of data is the Space Track web site
at
http://www.space-track.org/
The predecessor of this site provided data to anyone who surfed over to
it. But in the wake of 9/11/2001, a law was passed saying that you had
to register to get the data, and at that point it looked like it was
going to be illegal to redistribute it. One of the major redistributors
was Dr. Kelso of Celestrak, at
http://celestrak.com/. He revamped his
web site (which offers TLE data for several groups of satellites of
interest) so that all he provided was the object ID of satellites in the
group. You found (say) all the Iridium satellites by consulting his web
site, then hit SpaceTrack to get the data on them.
What eventually happened was that it became possible to register to be a
redistributor of the data (thanks in part to Dr. Kelso's lobbying).
The Astro::SpaceTrack module has had to track all these shenannigans, so
it has become a bit complicated. The current situation is that you must
provide a SpaceTrack username and password if you:
* Fetch your data directly from SpaceTrack (i.e. use the
Astro::SpaceTrack methods that are documented to do this), or
* Fetch your data from Celestrak (i.e. use the methods documented to do
this, which I think means the celestrak() method), _AND_ you have the
'direct' attribute set false. In this case, Astro::SpaceTrack gets the
object ID numbers from Celestrak, and then hits SpaceTrack for the data.
If 'direct' is true, it fetches all data from Celestrak, if possible
(and it typically is, since Dr. Kelso is registered as a redistributor).
Show quoted text> Where does Astro::SpaceTrack->retrieve() get its info?
This is one of the methods that gets TLE data directly from Space Track,
and hence needs a username and password.
Show quoted text> >Well, maybe I shouldn't have made the crack about the doctor. My
> >apologies. It was late when I responded, and it appears I was a bit
punchy.
Show quoted text>
> Anything I receive you (including cracks) beyond this code is more
> than I can expect. There's not a lot I can contribute to your code,
> except for expressing confusion in as clear a manner as possible in
> order to show you how others are trying to use your package.
>
Expressing confusion in a clear manner is a rare talent. I recall a tech
writer who was a typical "dumb user" with a twist that made her
invaluable. When she got herself balled up in the system, she could tell
you afterward what she did to get balled up, and why she did it. There
were a number of code changes based on her ways to get tangled in the
system.
Tom Wyant
