Add small moon orbital data from SPICE kernels

[theradioboy]

I just learned that Cartes du Ciel uses Spice kernels for proper computation of the position of small satellites of Jupiter and Saturn. See for instance this discussion: https://groups.io/g/skychart/topic/himalia_and_other_faint_moons/87269173

Would it be possible to include this kind of feature?

[gzotti]

Sure.

[Ajaja]

+1
A long-needed feature

[gzotti]

Who needs it? (I don't currently navigate a spacecraft to Himalia.)

As always, to speed up the process, you can

• find the actual SPICE kernels (data files)
• find documentation and algorithms/working code to use them
• make sure existing code can be re-used under GPL2.

Then one of us (including you, of course) can more rapidly

• add glue code
• make it work
• write encouraging words for the User Guide, pointing users to websites to download optional data files (SPICE kernels) that shows dim moons of the outer planets that most small telescopes still cannot easily show, just at other locations.
• A lucky handful with larger telescopes may indeed enjoy the update during actual observation. Is systematic observation of these moons still a thing to do?

[theradioboy]

This is useful not only for owners of big telescopes, or those who have access to them via online rentals, but also for imagers with smaller telescopes using ephemeris/blind synthetic tracking, like what can be done with Tycho Tracker.

See for instance this use case, tracking asteroids up to magnitude 20.8 with a 127mm refractor. My use case was planning an observation session with the Oculars/sensors plugin, to optimize the observation sessions dates according to framing, so I could get a decent number of faint Moons in the same field in one go, given the need for long total integration times, determined by my imaging equipment. Since the position of the Moons was wrong according to Stellarium, I spent a lot of time imaging the wrong place in the sky, and only got Himalia by accident when I imaged the field centered on Jupiter for context.

[Ajaja]

I'm not familiar with the Stellarium plugin API. Can coord_func now be defined in a dynamic plugin? This would help avoid potential licensing issues with the SPICE Toolkit. Stellarium would provide only an API for implementing custom orbits, while the implementation could be completely separate from Stellarium as a plugin with a different license and could be developed by third parties, like me or anyone else. Also, plugin-defined rotation (something like rotation_func) might be useful too.

[gzotti]

For technical reasons, dynamical plugins were not usable on all platforms since about 2010.

[Ajaja]

A recent example of who might benefit from this is:
https://www.gano.name/shawn/artemis2/
They had to generate RA/Dec tables from Horizons for a specific location to track Artemis II in Stellarium. For another location, a different table is required, which is not very convenient.
It would be easier with support of SPK, or at least XYZ table based trajectories.

[theradioboy]

Yup, I tried using that but it didn't work very reliably for me, so I ended up entering reference marks by hand, using coordinates generated by JPL/Horizons. Of course I just entered those coordinates in Sharpcap for goto+platesolving, but I wanted to verify I was picking the right fields with Stellarium, and then refine and plan the framing for synthetic stacking later on, indispensable for when the capsule was not even visible on individual images.
Passable for one object, but not a great solution for imaging multiple objects which can only be well placed with a SPICE Kernel.

[axd1967]

And please use the vendor branch strategy when importing whatever lives in an external repository . See #1906 .

Please do.

It is a simple and sound software engineering practice. Given by a (former) software engineer.

Remember: "copy-paste is evil".

Use this issue to demonstrate the concept; someone will have to do it once, I wish I could do this.

[alex-w]

This practice is not acceptable here