[Server-sky] NORAD TLE's (5)

[Tony Rick]

On Tue, Apr 7, 2009 at 9:30 PM, Keith Lofstrom <keithl at kl-ic.com> wrote:

> On Mon, Apr 06, 2009 at 04:41:48PM -0700, Tony Rick wrote:
> >
> > I put some code on the server-sky wiki at
> > ServerSky->OrbitsV01->EarthOrbits->OrbitSoftware->SxP4TestPatch.
> > I have an app that reads 3-line TLEs, feeds them to the orbit
> > extractor, and uses the result to predict the ascending node altitude.
> > I need to beef it up to  include the descending node.  I have been
> > retrieving the all-data sets from Space-Track for about two weeks.
>
> I am looking for something that can help me grind through an /entire
> catalog/ of 3 line elements and return an array of structs, or at
> least one by one, with each struct containing all the useful data
> per TLE.  I will then call something like "next struct" to get the
> next interpreted TLE.  So, among other things, I am looking for a
> robust parser that does not assume that the catalog is 3N lines
> and that all the fields are well behaved.
>
> I expect to ignore most of the entries in the struct, but I need
> enough to define the orbit ellipse (in kilometers, not radii) so
> I can transform it.  I also need the names, so I can decide whether
> they are active or debris or whatnont.  I can't see how to do that
> with the code in the norad directory - perhaps that is merely because
> I don't understand C++ well enough to quickly read it, and because
> there is very little documentation for the methods.
>
> I get the impression that the library is oriented around ground
> observation, not defining orbits in 3d space.
>
> Help me see the error of my ways .  Otherwise, I am tempted to
> do my parsing in Perl, where I know how to take apart a catalog
> easily, delivering a rigid one-line ascii output for a C++ program
> to handle. <http://lists.server-sky.com/mailman/listinfo/server-sky>


The norad library documentation is next to non-existent, as you said.  I
grok
it by reading the class declarations and definitions.  The class defined in
cOrbit.cpp/cOrbit.h exposes methods for retrieving the critical info
(apogee,
perigee, semi-major, semi-minor axes, etc) from a cOrbit instance.  An
instance of a cTle class is initialized with the appropriate lines from the
3-line TLE file.  Parsing is provided somewhere down in the guts.  I didn't
chase that, just tool it on faith that it works.  It is a relatively
straightforward
process to read the 3-line file and create a cOrbit instance for every
3-line entry.

The 3-line data sets are generated twice a day from what I can tell.  The
file names
have a calendar date and 'am' or 'pm'.  I don't know if there is an archive
of these.
The web page says that each file contains entries for every object for which
an
observation has been made in the past thirty days.  There is no guarantee
that every known object is represented in any given files, and some objects
may be represented more than once.

Worse (perhaps) is that the object names are not unique.  Only the object
ID numbers appear to be unique.

The other list of elsets, those named alldata*zip, are in 2-line format, and
contain,
according to the web page, all 2-line elements collected on a given date.  I
haven't
found anything that gives just the ID/name map.  My plan has been to collect
the twice-a-day 3-line files and build a local ID/name table.

Eyes getting heavy. More later.

- tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.server-sky.com/pipermail/server-sky/attachments/20090407/a408c6dc/attachment.html