You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Definite 👍 to this, I'm going to milestone it for 1.1 and consider it a high priority for coordinates.
The catch is that we currently don't have a framework for ephemerides in general. I have some thoughts on this, but it require some discussion. (It also ties into the RV and PM work @adrn has been keen on, which will be the next high priority coordinates item).
There will also be need for some kind of general Observer class that caters for arbitrary points, which would be useful for SunPy in the current coordinate frames.
Let me add that providing this would remove a major annoying dependency for the pulsar timing package PINT.
It looks like jplephem is modest in size and requirements; the only concern is what to do about big ephemeris data. de421 at least is in pip, so one could make it an optional dependency, I suppose. Or it could be downloaded as needed, but then where to put it?
skyfield dependes on jplephem anyway, and it is higher level.
Now there are two methods to compute ephemerides: pip-installing de421 and related packages or working with SPK files. Quoting from the PyPI page:
If you want to use one of these pip-installable ephemerides, you will be using a slightly older API, and will lose the benefit of the efficient memory-mapping that the newer SPK code performs.
de432s is "only" 10 MiB covering from 1950 to 2050, but anyway I agree with @mhvk that a mechanism for the user to download the files would be desirable.
Note that while jplephem will continue to support its own old pip-installable ephemeris format, that the project has now pivoted to also support pure SPICE kernel files through NumPy, so that it can run from standard .spk files. See the first few sections of its docs on PyPI:
@brandon-rhodes - that's great! I think for astropy, it definitely makes most sense to base our work on jplephem, and this should make it all the easier.
Activity
astrofrog commentedon Dec 17, 2014
+1, I found myself having to parse a file from there by hand today.
eteq commentedon Dec 17, 2014
Definite 👍 to this, I'm going to milestone it for 1.1 and consider it a high priority for coordinates.
The catch is that we currently don't have a framework for ephemerides in general. I have some thoughts on this, but it require some discussion. (It also ties into the RV and PM work @adrn has been keen on, which will be the next high priority coordinates item).
Cadair commentedon Dec 17, 2014
There will also be need for some kind of general Observer class that caters for arbitrary points, which would be useful for SunPy in the current coordinate frames.
Cadair commentedon Dec 17, 2014
ping @dpshelio
aarchiba commentedon Apr 29, 2015
Let me add that providing this would remove a major annoying dependency for the pulsar timing package PINT.
It looks like jplephem is modest in size and requirements; the only concern is what to do about big ephemeris data. de421 at least is in pip, so one could make it an optional dependency, I suppose. Or it could be downloaded as needed, but then where to put it?
There is also "skyfield": http://rhodesmill.org/skyfield/
aarchiba commentedon Apr 29, 2015
For comparison, the skdata is mostly python code but downloads large data files as needed; here is how they arrange it: https://github.com/jaberg/skdata/wiki/Managing-Data
astrojuanlu commentedon Apr 29, 2015
skyfield dependes on jplephem anyway, and it is higher level.
Now there are two methods to compute ephemerides: pip-installing de421 and related packages or working with SPK files. Quoting from the PyPI page:
de432s is "only" 10 MiB covering from 1950 to 2050, but anyway I agree with @mhvk that a mechanism for the user to download the files would be desirable.
brandon-rhodes commentedon May 5, 2015
Note that while
jplephemwill continue to support its own old pip-installable ephemeris format, that the project has now pivoted to also support pure SPICE kernel files through NumPy, so that it can run from standard.spkfiles. See the first few sections of its docs on PyPI:https://pypi.python.org/pypi/jplephem
In case that helps anyone. :)
mhvk commentedon May 5, 2015
@brandon-rhodes - that's great! I think for astropy, it definitely makes most sense to base our work on
jplephem, and this should make it all the easier.bsipocz commentedon May 14, 2016
This can be closed as #4890 is now merged.
mhvk commentedon May 14, 2016
Yay, a very old wishlist item is done!