Where to get the files : Note that I'm now storing TLEs on this GitHub repository. This should make the documenting of updates a little more precise than it has hitherto been.
What these TLEs are: These are orbital elements, in the TLE format, for several high-orbiting artsats that have been tracked by asteroid observers. These objects usually have periods of two or more days, and/or have high eccentricities such that, at apogee, they move about as slowly as a fast-moving near-earth asteroid would. In most cases, TLEs are unavailable elsewhere; Space-Track.org, the US Government organization that supplies most publicly-available artificial satellite elements, either doesn't track or doesn't publish elements for many high-flyers. I don't think there is a "national security" angle here. I think it's just that their main task is tracking objects in lower orbits. Also, I gather they rely heavily on radar. Radar is jaw-droppingly good for low-earth orbits, but loses effectiveness with distance more rapidly than visual tracking (inverse fourth power versus inverse square).
You can click here to see the source data used to compute these TLEs, residuals, and some analysis of these objects.
You can click here for details on the TLE format, and where to get TLEs for other objects.
How these TLEs were computed: For each object, I determined an orbit from optical astrometry, using my Find_Orb orbit determination software. I then generated a numerically-integrated ephemeris of state vectors from that orbit, usually at a close step size of 0.1 day.
Finally, I used a program I wrote, vec2tle, that could find and least-squares-fit TLEs to that ephemeris. Usually, this was done in one-day increments: read ten state vectors from the ephemeris, then determine the TLE that fits those ten positions. As a result, when I write out the TLE, I can also tell you what the worst error of those ten positions was. This is repeated for all lines of the ephemeris.
All of this is publicly available, except for vec2tle. I'll probably get around to posting that eventually. Right now, it's pretty tricky code to use, and even more difficult to figure out what I was doing (determining the TLE that fits a given state vector, or set of state vectors, is mildly straightforward for low-orbiting objects, but gets increasingly difficult for high-altitude and/or high-eccentricity objects.)
Important safety tip! Note that some of these element files contain the lines
# SGP4 only: these TLEs are _not_ fitted to SDP4, even for # deep-space TLEs. These may not work with your software.
The problem is that the SDP4 model has lots of nice trickery for handling 24-hour and 12-hour orbits accurately. But it wasn't really intended for multi-day orbits, especially higher-eccentricity ones and objects beyond the Moon (WT1190F and XL8D89E, for example). In some cases, I simply couldn't find an SDP4 element set that would fit a particular object over a particular time span, or the fit would only be to within thousands of kilometers.
In such cases, I would (sometimes) fit SGP4 elements instead, and set the ephemeris type byte to '2', meaning SGP4. This does result in accurate ephemerides for any object in an elliptical orbit around the earth (no escape orbits, which is why there are no TLEs here for Gaia or similar objects.)
The problem is that every TLE I've ever seen uses ephemeris type 0, i.e., "use SDP4 for any object with an orbital period greater than 225 minutes". (The ephemeris type flag is apparently intended for internal processing use.) A lot of code expects this and will ignore the ephemeris type. So if you see the above warning, be advised: those TLEs may, or may not, work with your software. (They do, of course, work with all of the software and services provided on this Web site.)