I've been trying to build a model of the solar system in a game. Thus far I've succeeded in placing each of the planets in position using Keplerian elements and formulae from https://ssd.jpl.nasa.gov/?planet_pos An example for Jupiter is:

               a              e               I                L            long.peri.      long.node.
           AU, AU/Cy     rad, rad/Cy     deg, deg/Cy      deg, deg/Cy      deg, deg/Cy     deg, deg/Cy
Jupiter   5.20288700      0.04838624      1.30439695       34.39644051     14.72847983    100.47390909
         -0.00011607     -0.00013253     -0.00183714     3034.74612775      0.21252668      0.20469106

At this point, I want to add several of the Jovian moons, however the same site doesn't seem to provide the same type of data for these moons, perhaps because the moons behave differently. Unfortunately, my math is not great; I can usually implement something that's written down, but I don't have the wherewithal to work it out myself.

For the Jovian moons, the data is listed at: https://ssd.jpl.nasa.gov/?sat_elem#jupiter Here is an example for Ganymede:

 Sat.           a       e          w           M        i            node      n             P       Pw      Pnode    R.A.        Dec.     Tilt
 (km)        (deg)     (deg)      (deg)       (deg)    (deg/day)    (days)    (yr)          (yr)    (deg)    (deg)    (deg)
 Ganymede  1070400.    0.0013    192.417    317.540    0.177        63.552    50.3176072    7.155   63.549  132.654   268.168    64.543    0.068

Here they state that the data is "Mean orbital elements referred to the local Laplace planes", as opposed to "Keplerian Elements for Approximate Positions of the Major Planets".

Whilst the first 6 parameters appear to be the same (a, e, w, M, i, node), the Keplerian elements also have "rates", or time derivatives (according to this post: https://space.stackexchange.com/questions/8911/determining-orbital-position-at-a-future-point-in-time). The forumlae kindly provided by NASA for the Keplerian elements relies on these rates.

If I could understand how to determine the "rates" for the Jovian moons, then I might be able to use the same formula (is this the right thing to do?) It looks to me like those rates are something I should be able to compute from the other data provided for the moons, however I haven't been able to determine how.

My suspicion is that I either need a different formula for the computation using the Laplace Planes, or I need to compute those 'rate' values and use the same formula I already have.

I'm trying to generate cartesian (x, y, z) coordinates for each Moon where (0,0,0) is the centre of Jupiter itself, for a given date/time (typically "now").

I'm beginning to wonder if I'm barking up the wrong tree on this. Can anyone shed any light

  • 1
    $\begingroup$ Have you tried ssd.jpl.nasa.gov/horizons.cgi#top using the ELEMENTS setting for the moon you want? You can get the osculating elements from there. $\endgroup$
    – user21
    Commented Aug 4, 2018 at 18:22
  • $\begingroup$ Yes, though I'm afraid I don't quite see how it helps. Yes that site will give me static data for a given time range. I want to be able to calculate the position for any given date (before 2050 since that seems to be when the mean data loses validity, and it's unlikely my game will exist in ~30 years). $\endgroup$
    – PKCLsoft
    Commented Aug 5, 2018 at 21:55
  • 1
    $\begingroup$ If you want accurate data, you'll have to use something like SPICE (naif.jpl.nasa.gov/naif). If you look at the osculating elements, you might find they follow an approximate pattern you could mimic. In theory, you could even solve differential equations given initial positions, but that's very time consuming. Ultimately, it's a question of information theory (these orbits just aren't that simple) and time/space tradeoff (if you don't want to record positions, you'll have to compute them). $\endgroup$
    – user21
    Commented Aug 6, 2018 at 3:13
  • $\begingroup$ OK thanks. That's a shame. I took a look at SPICE on the weekend, and whilst it will obviously do what I want, I was left a little nonplussed by the API, and the fact that I'd possibly face the need to port it to iOS. I've managed to get the moons orbiting now, though they won't be in the right places which is a shame. $\endgroup$
    – PKCLsoft
    Commented Aug 6, 2018 at 10:16
  • 1
    $\begingroup$ You could use the current osculating elements and pretend the moons' orbits will always be elliptical-- that would be accurate short term. Also, feel free to contact me directly for free help (contact info in profile). SPICE should compile on iOS "as is", but I've never used it there, so I'm not sure. It's basically just a C++ library, so, if you know C++, you should be able to use it. $\endgroup$
    – user21
    Commented Aug 6, 2018 at 17:14

2 Answers 2


An excellent book by Jean Meeus, "Astronomical Algorithms", provides the calculations for planetary positions and Jupiter's Galilean Moons (Io, Europa, Ganymede, and Callisto). Meeus does not really explain the math to a great degree, so it is relatively simple to follow it as a formulaic approach. He uses VSOP for planetary positions and Lieske's E5 theory for the moons (you can get an explanation of both on Wikipedia). As a bonus, Meeus shows how to make calculations for both parameters with a lesser degree of accuracy which might improve your calculation speed. Though this book can be a bit dense, you might want to read up on the difference between "ephemeris time" and "terrestrial time", as this will affect your accuracy as well.

  • $\begingroup$ Thank you for this suggestion. As it turned out, I took the advice of @barrycarter above and looked up SPICE. I'm now posting an answer below that is the result of that. $\endgroup$
    – PKCLsoft
    Commented Jun 17, 2020 at 13:03

Thank you to those people that have tried to help me with this, both back when I first posted the question, and later.

With the solid advice of @barrycarter in the comments, I looked into using the SPICE library to compute the positions of the various celestial bodies of interest.

After some reading, and further advice from NAIF themselves, I took it upon myself to port the CSPICE library, Version 66 to work on iOS (and consequently, macOS).

I then used the SPKMERGE tool to generate ephemeris files that contained just the data I needed for my app. The app then loads those files via CSPICE and generates the positional data it needs.

The modified version of the CSPICE library for iOS is now available for others that want to make use of it.

It can be found at:



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .