<br><br><div class="gmail_quote">On Tue, Apr 7, 2009 at 9:30 PM, Keith Lofstrom <span dir="ltr">&lt;<a href="mailto:keithl@kl-ic.com">keithl@kl-ic.com</a>&gt;</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>
&gt;<br>
&gt; I put some code on the server-sky wiki at<br>
&gt; ServerSky-&gt;OrbitsV01-&gt;EarthOrbits-&gt;OrbitSoftware-&gt;SxP4TestPatch.<br>
&gt; I have an app that reads 3-line TLEs, feeds them to the orbit<br>
&gt; extractor, and uses the result to predict the ascending node altitude.<br>
&gt; I need to beef it up to  include the descending node.  I have been<br>
&gt; 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 &quot;next struct&quot; 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&#39;t see how to do that<br>
with the code in the norad directory - perhaps that is merely because<br>
I don&#39;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&#39;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 &#39;am&#39; or &#39;pm&#39;.  I don&#39;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&#39;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>