Open polmes opened 1 year ago
Note: in order to correlate SATCAT data with the satellite constellations of interest for the app, I suggest matching OBJECT_NAME
/ SATNAME
with the following regex's:
^STARLINK-\d+$
^ONEWEB-\d{4}$
^(SKYSAT C?\d+)|(FLOCK \d[A-Z]?( |-)\d+)$
^LEMUR \d [A-Z0-9-]+$
^SPACEBEE(NZ)?-\d+$
^IRIDIUM \d+$
^GLOBALSTAR [A-Z]+\d+$
The goal of this issue is to capture all desired features/development for a new feature in the app that would allow you to see the historical evolution/trends of a constellation as it grows over time with new launches, etc.
Desired Features
To start, I think we should focus on showing how many satellites have been launched for a given constellation, displaying their status (see below), as well as some information on their orbit:
Orbit Evolution
The place to start should be aggregating from public sources (see below) where each satellite from a constellation is and has been in the past. The goal here would be to see how different satellites have been ascending or reentering over time.
I can think of a few ways to represent this information:
Satellite Status
I have identified the following possible options that we should be able to extract from publicly available information:
Would be cool to display this information as a chart with time on the x-axis and then different lines/bars indicating the growth of each satellite category.
Eventually, this could become even more powerful if we had access to the "maneuverable" status for satellites that are supposed to be maneuverable. I know this information is available on CDMs (obviously), but it actually comes from organizations updating their satellite status through Space-Track.org's API. Unfortunately, at the moment, the
satellite
class from their API does not appear to provide information to the general public.Data Sources
Now, in terms of (reliable) sources of public data for the above information, here's my take:
Space-Track
Space-Track.org, of course, always provides the most information through their API. However, due to their rate limits, querying for historical TLEs for objects in real time (that is, doing it at the app level instead of storing the data on a separate database first) is... well, not great. The account will get block real fast.
If we still wanted to retrieve their data, my suggestion would be to set up a separate process that queries the historical GP information from their
gp_history
API) class, which provides access to all TLEs generated for a given object. Then, we would need to store that information in either a database or even in static JSON files. Storing all of that information is a lot, but could be greatly reduced if we just kept the bare minimum data for plotting. The process would only need to run about once a day to update what we consider to be the "current" catalog for the app.However, for other information—as long as we can properly cache the results of the queries—using the API directly should be fine. This includes the following information:
satcat
class to retrieve a list of all cataloged objects, along with their launch date and decay date (set toNULL
for objects that have not yet reentered). Only thing missing here will be objects that have not yet been cataloged (i.e., from recent launches).satellite
class.CelesTrak
CelesTrak.org provides plots for some/most(?) objects we are interested in with historical mean orbital elements from TLEs. Even though there is no API comparable to what Space-Track.org offers, it should be fairly easy to get that information from the site.
As it stands, whenever you load plots, the site makes a request to:
where
<sat_id>
is the 5-digit "NORAD" CAT ID from the US SATCAT that identifies the object.The site generated by the server-side PHP code includes the
plotData
JavaScript variable that provides a string with all the data used for plotting. See here for an example.Having said that, making thousands of requests to their site to retrieve information for all satellites from a constellation may not make T.S. Kelso happy and could result in the app being blacklisted in some way.
Additionally, since there is no formal API, the format returned by the site is subject to change at any time. Additionally, whenever you request information for an object that has no information, CelesTrak will still return a valid response, but in this case,
plotData = ""
.Others
ESA's DISCOS database (typically used to get information on the size of arbitrary objects, particularly payloads) also appears to have information on launch and reentry for different objects. They do not appear to have historical trends, but could be used instead of Space-Track.org for SATCAT data.
They do provide an API that should be easy to integrate as well. However, I have not verified that they have a catalog that is as complete as Space-Track.org's.