<br><br><div class="gmail_quote">On Tue, Apr 7, 2009 at 9:30 PM, Keith Lofstrom <span dir="ltr"><<a href="mailto:keithl@kl-ic.com">keithl@kl-ic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Apr 06, 2009 at 04:41:48PM -0700, Tony Rick wrote:<br>
><br>
> I put some code on the server-sky wiki at<br>
> ServerSky->OrbitsV01->EarthOrbits->OrbitSoftware->SxP4TestPatch.<br>
> I have an app that reads 3-line TLEs, feeds them to the orbit<br>
> extractor, and uses the result to predict the ascending node altitude.<br>
> I need to beef it up to include the descending node. I have been<br>
> retrieving the all-data sets from Space-Track for about two weeks.<br>
<br>
I am looking for something that can help me grind through an /entire<br>
catalog/ of 3 line elements and return an array of structs, or at<br>
least one by one, with each struct containing all the useful data<br>
per TLE. I will then call something like "next struct" to get the<br>
next interpreted TLE. So, among other things, I am looking for a<br>
robust parser that does not assume that the catalog is 3N lines<br>
and that all the fields are well behaved.<br>
<br>
I expect to ignore most of the entries in the struct, but I need<br>
enough to define the orbit ellipse (in kilometers, not radii) so<br>
I can transform it. I also need the names, so I can decide whether<br>
they are active or debris or whatnont. I can't see how to do that<br>
with the code in the norad directory - perhaps that is merely because<br>
I don't understand C++ well enough to quickly read it, and because<br>
there is very little documentation for the methods.<br>
<br>
I get the impression that the library is oriented around ground<br>
observation, not defining orbits in 3d space.<br>
<br>
Help me see the error of my ways . Otherwise, I am tempted to<br>
do my parsing in Perl, where I know how to take apart a catalog<br>
easily, delivering a rigid one-line ascii output for a C++ program<br>
to handle.<font color="#888888"><a href="http://lists.server-sky.com/mailman/listinfo/server-sky" target="_blank"></a></font></blockquote><div><br>The norad library documentation is next to non-existent, as you said. I grok<br>
it by reading the class declarations and definitions. The class defined in<br>cOrbit.cpp/cOrbit.h exposes methods for retrieving the critical info (apogee,<br>perigee, semi-major, semi-minor axes, etc) from a cOrbit instance. An <br>
instance of a cTle class is initialized with the appropriate lines from the<br>3-line TLE file. Parsing is provided somewhere down in the guts. I didn't<br>chase that, just tool it on faith that it works. It is a relatively straightforward<br>
process to read the 3-line file and create a cOrbit instance for every 3-line entry.<br><br>The 3-line data sets are generated twice a day from what I can tell. The file names<br>have a calendar date and 'am' or 'pm'. I don't know if there is an archive of these.<br>
The web page says that each file contains entries for every object for which an<br>observation has been made in the past thirty days. There is no guarantee<br>that every known object is represented in any given files, and some objects<br>
may be represented more than once.<br><br>Worse (perhaps) is that the object names are not unique. Only the object<br>ID numbers appear to be unique.<br><br>The other list of elsets, those named alldata*zip, are in 2-line format, and contain,<br>
according to the web page, all 2-line elements collected on a given date. I haven't<br>found anything that gives just the ID/name map. My plan has been to collect<br>the twice-a-day 3-line files and build a local ID/name table.<br>
<br>Eyes getting heavy. More later.<br><br>- tony<br></div></div><br>