Skip to content

Wishlist: support JPL ephemerides #3219

Closed

Description

@mhvk

As noted in #2244 and #3217, eventually we should support using the JPL ephemerides. A good place to start would be @brandon-rhodes https://github.com/brandon-rhodes/python-jplephem

It needs some mechanism by which a user can opt to download the (large) ephemeris files, as we would not want to include those in astropy by default.

Activity

  1. astrofrog commented on Dec 17, 2014

    @astrofrog
    Member

    +1, I found myself having to parse a file from there by hand today.

  2. eteq commented on Dec 17, 2014

    @eteq
    Member

    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).

  3. added this to the milestone on Dec 17, 2014
  4. Cadair commented on Dec 17, 2014

    @Cadair
    Member

    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.

  5. Cadair commented on Dec 17, 2014

    @Cadair
    Member
  6. aarchiba commented on Apr 29, 2015

    @aarchiba
    Contributor

    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/

  7. aarchiba commented on Apr 29, 2015

    @aarchiba
    Contributor

    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

  8. astrojuanlu commented on Apr 29, 2015

    @astrojuanlu
    Member

    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.

  9. brandon-rhodes commented on May 5, 2015

    @brandon-rhodes

    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:

    https://pypi.python.org/pypi/jplephem

    In case that helps anyone. :)

  10. mhvk commented on May 5, 2015

    @mhvk
    ContributorAuthor

    @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.

  11. removed this from the v1.1.0 milestone on Sep 29, 2015
  12. bsipocz commented on May 14, 2016

    @bsipocz
    Member

    This can be closed as #4890 is now merged.

  13. mhvk commented on May 14, 2016

    @mhvk
    ContributorAuthor

    Yay, a very old wishlist item is done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions