This group at JPL is the canonical source for solar system ephemeris, including planets and small bodies. The underlying models are numerically integrated equations of motion that I’m sure include all kinds of corrections, especially for bodies of great interest — such as Mars, or moons being considered for science visits.
I used to use the python package “jplephem” to support ephemeris queries, but I understand that SpiceyPy is a more modern replacement (https://github.com/AndrewAnnex/SpiceyPy). They all, I believe, use the same underlying sets of “spk” files containing coded ephemeris.
I would recommend the Skyfield library: https://rhodesmill.org/skyfield/
It does the same thing, uses the spk files to compute planetary positions, but it does so with a beautifull API which is a pleasure to use.
Seconding this. Skyfield is a great tool maintained by a great guy, Brandon Rhodes. I've built many a production tool for spacecraft with it.
Indeed, I've met many of them and worked with some of them. One of the main devs for this webapi project, who is a delight to work with, was just laid off sadly.
Just for some additional context, the main library used by all these packages is SPICE, a C library written and maintained by JPL. https://naif.jpl.nasa.gov/naif/aboutspice.html
It dates back to 1982, IIRC. And yeah, as mentioned you can still telnet in and check your calculations using their reference implementation.
The C library has been wrapped many times, but remains the main implementation at the core, and is used by a ton of missions and spacecraft for determining sun up/down times, pointing angles for heavenly bodies, time and precise keeping, etc etc.
I used it here to determine the relative angle of the sun at one of my favorite spots on the moon: https://api.jodavaho.io/s/readme
The software reads "kernel" files, which are very precise tables of positions over time, shape, etc, and can output just about anything you'd want to know about the layout of the solar system with precision good enough for whatever you'd want. Publishing a new kernel file is an infrequent, but fairly major affair, afaict.
It's a really fascinating look at what is required to do business in space. I recommend someone peruse their training materials for answers to questions you never thought about like: "If you want to view a crater during sunrise to get the nice shadows, what do you even mean "sunrise"?" which gets weird to answer because of speed of light and cosmic distances.
Totally sentimental view on my part, but I consider the JPL ephemeris files one of the crowning achievements of humankind. On par with other things like a modern microprocessor, the pyramids, or the electric grid.
You of course know this, saying it for others: The files themselves are relatively unassuming, moderate sized (~3.1 GB the largest of them) binary files which contain the distilled best knowledge of where the planets and their moons will be based on humanity's best observations (visual, radar, trajectory data from probes, etc). They each have a validity window within which you can query the relative transforms between the objects the database contains. For example de441.bsp was published in 2020 and you can use it to predict the relative positions of any of the planets/moons it contains between the years −13200 to 17191. Or if you don't need to look that far in time you can use one of the smaller models like de440s.bsp (32 MB) which is good between 1849 to 2150.
it's not sentimentality. They represent a truly amazing effort to gather both the raw data and the underlying mathematical models to make unbelievably accurate predictions.
It took me entirely too long to realize that SPICE may be useful for navigation around the Solar System.
> used by a ton of missions and spacecraft for determining sun up/down times, pointing angles for heavenly bodies, time and precise keeping, etc etc.
Yes. My use case was/is determining pointing angles between a telescope at L2 and various nearby stars, to be sure it's not pointing anywhere near a bright body like a planet (around Sol) when it's expected to be observing exoplanets.
There are a lot of diverse use cases!
:D all of these super cool and highly professional uses of SPICE kernels and here I am using the same thing to point an arrow to where the planets are as a room decoration :D https://www.youtube.com/shorts/32BGeJav2OQ
(On the video the mechanism is not using SPICE, just pointing at manually selected alt-az)
Of course the SPICE is vital to space travel. Travel without moving, as long as you don’t consider telnet to be moving.
There are also access points to Horizons via astroquery (https://astroquery.readthedocs.io/en/latest/jplhorizons/jplh...) and l'horizon (https://github.com/millionconcepts/lhorizon).
Whether you want to use SPICE or Horizons will depend on what you are trying to accomplish.
oh hey, I'm the developer of SpiceyPy. IIRC jplephem implements their own parsing of spk files and isn't a full implementation of the SPICE API. SpiceyPy simply wraps SPICE (via CSPICE).
This is consistent with what I know. I did not need the full API for my use case, just access to planet positions across times in the next few decades.
It is Dmitry Savransky who recommended your package, btw.
Im a developer for the upcoming space telescope NEO Surveyor (Near Earth Object Surveyor). I actually work quite a bit with a number of people on the team up at JPL, Horizons is the canonical source for ephemeris information. Another vital part of the chain is the Minor Planet Center (MPC), which is where all observations of asteroids and comets are sent by the community. The MPC is the international authority for these observations, which JPL ingests and computes orbits for (though the MPC also has to compute orbits as a part of their work).
As a part of my work I have written a rust/python package[1] to compute the position of asteroids accurately using the ephemeris data provided by these two excellent sources. For the people who use SPICE kernels (a rather old binary format for storing orbital ephemeris), I have also written a custom implementation of spice kernel reading which is natively parallel.
Awesome project!
I want to plug our project for the curious: https://github.com/DarkStar1982/Orbidium/
it is just a static viewer, but can be augmented to do simulation/visualization in a similar manner.
Is there an explanation somewhere of how JPL knows/receives the latest satellite position data?
I think I've read about maneuvers being sent in advance, but once a maneuver (or flyby) actually happens (which may result in deviations from the plan), how (fast) does the ephemeris data actually align with reality through measurement of the actual spacecraft position and speeds again?
Sorry, I know some of the ways measurements are taken for satellite orbits, but not who actually does them or how that information makes its way to JPL.
Do you know -- is the SPICE API or HORIZONS API available for public use (i.e. within an app)? And if so where can I read about getting an API key / usage limitations (rate limits etc)
SPICE itself is a C package with a number of wrappers in other languages. JPL use it, along with numerical integrator and orbit determination code to generate SPICE "kernels", IE: binary files. The Horizons API allow you to use their numerical integrators to calculate the position of asteroids and comets. This works great for single objects, or a handful, but struggles when you want to look at the entire solar system at a time. This is where my code comes in, it enables similar calculations to what Horizon's provides, but you can do them locally on all known asteroids/comets.
The C SPICE library is available online, but it dates back decades, and was not really built with multi-core support in mind. My code enables reading of SPICE kernel files with native multi-core support. Though I would argue the bigger benefit that my code provides is the numerical integrator which can be used on the entire asteroid belt at once.
JPL Horizons API is open to anyone, if you hammer it enough they may rate limit you, but I don't believe they have limits. As far as I am aware they don't have any API keys or usernames. See: https://ssd-api.jpl.nasa.gov/doc/horizons.html
I love that the primary interface to Horizons is still via Telnet ^_^ I hope they keep that interface forever.
It made me wonder how old the Horizons system is... I couldn't find any information. I would've guessed it dates back to the age of UNIX workstations and NSFNET, given the "e-mail" [sic] interface that produces either pure ASCII or PostScript.
The public internet service is from 1996 https://ntrs.nasa.gov/citations/20060036597
i have been using this for many years to get the SPICE kernels for the space sim Celestia
Is it open source?
sort of: https://github.com/OpenSpace/Spice
but the you can use it to generate information by a really nice, freely-usable API.