Skip to content

Add reference frames of planets and other bodies #5898

Open

Description

@astrojuanlu

Using the machinery to define new reference frames in Astropy and the information of this report of the IAU Working Group on Cartographic Coordinates and Rotational Elements it should be possible to define the reference frames of the planets of the Solar System and other bodies:

https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2009reprint.pdf

Is this something that would be in scope for Astropy? If not, I will try to implement them outside: poliastro/poliastro#109

Activity

  1. Cadair commented on Mar 22, 2017

    @Cadair
    Member

    I have looked into this report a little with the intent of defining a transformation between the SunPy solar frames.

    Correct me if I am wrong, but the information in the report provides a reference at some point in time? To define a transformation into something like ICRS you would have to know how the reference points change over time?

  2. astrojuanlu commented on Mar 22, 2017

    @astrojuanlu
    MemberAuthor

    Correct me if I am wrong, but the information in the report provides a reference at some point in time? To define a transformation into something like ICRS you would have to know how the reference points change over time?

    Yes, that's how I understand it.

    In the case of Mars, for example, we have [and now I miss LaTeX on GH issues]:

    α_0 = 317.68143 - 0.1061 T
    δ_0 = 52.88650 - 0.0609 T
    W = 176.630 + 350.89198226 d

    where (α_0, δ_0) are "ICRF equatorial coordinates at epoch J2000.0" of the north pole of the body, W is "the ephemeris position of the prime meridian", T is "interval in Julian centuries (of 36525 days) from the standard epoch" and d is "interval in days from the standard epoch".

    page-shot-2017-3-22 wgccre2009reprint pdf

  3. Cadair commented on Mar 22, 2017

    @Cadair
    Member

    OK, so if we are to define these transformations, what can we use to calculate the offset at a given obs time?

  4. astrojuanlu commented on Mar 22, 2017

    @astrojuanlu
    MemberAuthor

    I'm not sure I understand, could you elaborate on what you're missing?

  5. Cadair commented on Mar 22, 2017

    @Cadair
    Member

    I think I am not understanding it correctly. I am coming at this from the point of view of trying to convert from a coordinate frame that uses the Sun (centre and north pole) as a reference point.
    If I want to go (for simplicity) from a point on the Sun today to ICRS I am going to need to compensate for the precession of the Sun from the epoch no?

  6. astrojuanlu commented on Mar 22, 2017

    @astrojuanlu
    MemberAuthor

    The coordinates of the poles of the bodies are referred to the ICRF, so if I understood correctly all the information is captured by the terms that depend on the passage of time. Notice that, for the case of the Sun, the evolution of the prime meridian is also considered:

    α_0 = 286°.13
    δ_0 = 63°.87
    W = 84°.176 + 14°.1844000 d

  7. Cadair commented on Mar 22, 2017

    @Cadair
    Member

    Ok, it's been a while since I looked at this, I will see if I can find the time to re-read the report and wrap my head around it again.

    Thanks a lot for your help.

  8. mhvk commented on Mar 22, 2017

    @mhvk
    Contributor

    @Juanlu001 - on your original question - my own sense is that this is in scope for astropy itself, partially because I feel it is important that astropy is the package to use if one wants to conform to IAU standards. Also, more practically, while for the Sun arguable sunpy is just as logical, for the planets I don't see another package (poliastro is not particularly logical in itself, though it is very logical that it would use the information if available).

    In principle, given what you wrote, it should not be that difficult to implement in astropy either: we already have access to the planet ephemerides, so really it is a matter of defining appropriate reference frames (that rely not on EarthLocation, but something more general planet location; indeed, this may be a point where we generalize EarthLocation as a representation that can convert between lon, lat, height and cartesian; see #4261 (comment))

    Anyway, it would be really cool if one could use astropy to tell where the planets would be in the sky as seen by a mars rover!!

  9. astrojuanlu commented on Mar 22, 2017

    @astrojuanlu
    MemberAuthor

    If it is in scope for Astropy itself then I might as well propose a PR. I wonder if it would be nice to agree on an API before start coding, what's the usual way to proceed? An AEP, discussion on the mailing list, perhaps iterating on the wiki?

    Anyway, it would be really cool if one could use astropy to tell where the planets would be in the sky as seen by a mars rover!!

    😍

  10. pllim commented on Mar 22, 2017

    @pllim
    Member

    it would be really cool if one could use astropy to tell where the planets would be in the sky as seen by a mars rover

    And perhaps also a function called find_matt_damon()?

  11. mhvk commented on Mar 22, 2017

    @mhvk
    Contributor

    I guess it would be good to lay out what would be needed, realizing there are two different purposes: knowing where a given location on the sun or a planet is (i.e., where it would be in one's telescope from earth), and using such a location to see where other things are. So, very broadly, I guess one would need

    1. a generalized EarthLocation;
    2. conversion of that to a SkyCoord so it can be localized;
    3. use in sun/planet frames (in which it replaces obsgeoloc, obsgeovel).

    Point 3 may require creating frames on demand (as for the offset frames).

    My overall sense would be to start with the Sun, since then 1 and 2 may already be done in sunpy. I also feel that we could have those without worrying too much about generalizing to many planets. @Cadair, what do you think?

  12. Cadair commented on Mar 22, 2017

    @Cadair
    Member

    So in SunPy, the frames we have specify location of the observer in the heliosphere, with respect to the solar centre. So we specify location of the observers with an instance of one of our frames (currently a PR).

    Things that would be useful to SunPy that I think this has the possibility to address or at least help with are:

    • Position of the earth with respect to the solar equator.
    • Location of the north pole of the Sun in ICRS coordinates (for defining a transformation from sunpy frames to ICRS)
    • Calculation of the locations of planets in solar frames from arbitrary locations in the heliosphere (satellites).
  13. aelanman commented on Nov 8, 2017

    @aelanman

    Has there been any further development on this?
    I'm interested in using astropy to do ra/dec to az/alt coordinate transformations for observers located on the Moon.

  14. 11 remaining items

  15. aelanman commented on Jan 6, 2020

    @aelanman

    I have started working on some changes to address this, which you can find here https://github.com/aelanman/astropy/tree/moon_locations. I started writing this before thinking to re-check this issue... This works by incorporating SPICE transformations directly in astropy via the spiceypy module.

    There are two Moon-centered-moon-fixed (MCMF) reference frames in common use, described in this white paper. I'm using the "mean Earth/Polar axis" frame (MOON_ME in SPICE), which sets the prime meridian of to the mean direction of the Earth and sets the North pole to the mean rotation axis. SPICE can make a rotation matrix to transform from ICRS (which it calls J2000) to the MOON_ME frame, but I'm not sure how to include stellar aberration from the Moon's motion.

    The changes I've made define a MoonLocation class, which describes positions on the moon in the Moon_ME frame (cartesian "selenocentric" positions as well as "geodetic" lat/lon/height, where height is with respect to a sphere of fixed radius). I'm not sure how SPICE kernels describe the shape of the moon mathematically. Is there a more precise ellipsoid model?

  16. jarmokivekas commented on Jan 16, 2020

    @jarmokivekas

    @aelanman SPICE is a complex system, so there are many ways to represent things like the moon surface, but at least the spheroids/ellipsoids defined in the "IAU2000" spatial reference recommendations are readily available. I would recommend using those.

    I usually look up IAU recommended ellipsoids here:
    https://spatialreference.org/ref/iau2000/?search=IAU+2000&srtext=Search

    For example IAU2000:30100 "Moon 2000" ellipsoid is +proj=longlat +a=1737400 +b=1737400 +no_defs in proj4 notation.

  17. aelanman commented on Jan 22, 2020

    @aelanman

    @jarmokivekas Thanks for the suggestion! From your comment, it sounds like the reference ellipsoid for the Moon is a sphere anyway?

    Since my last comment, I've gone in a slightly different direction with this. I've moved my changes to a new package (github.com/aelanman/lunarsky), which includes the new frames and a modification to SkyCoord as well as tests. If this works out well, I would like to make the changes to astropy instead of having a separate module, but for now I can work with this.

  18. cmarmo commented on Dec 4, 2020

    @cmarmo
    Member

    Hi @astrojuanlu and all people working about this issue. Thanks a lot for trying to address the insertion of Solar System bodies reference systems in astropy! The entire planetary community is struggling with interoperability issues, their solution might depend on this implementation. I've never dived into the astropy code so this will probably take me some time... but may I ask if adding some more planetary related keywords to the WCS as from the work done during the EuroplanetH2020 could be helpful in some way?

  19. mhvk commented on Dec 4, 2020

    @mhvk
    Contributor

    @cmarmo - I'll let @astrojuanlu answer more about the details, but it does seem logical that astropy.io.fits would be able to interpret any planetary keywords and astropy.wcs represent the corresponding coordinate systems. It would seem that would get us some way to defining the coordinate systems themselves too!

    And at least from the outside, this looks exactly like the step-by-step approach that would be easiest to implement (and where every step is useful on its own). Before diving in any code, it might be good to open a first issue specifically about supporting the relevant FITS keywords and what would be needed in WCS, giving some explicit details.

    One good thing is that @astrojuanlu has just been adding generalizations of the geodetic representations in #11086, which I think would form a good framework to build a general ellipsoid model on for the [ABC]_RADIUS mapping in the reference you gave. The idea is that we'll use the geodetic representations in EarthLocation (instead of it just being the representation), making it more like a coordinate frame object. This should make it much easier to have equivalent PlanetLocations...

  20. cmarmo commented on Dec 5, 2020

    @cmarmo
    Member

    Thanks @mhvk for your answer.

    Before diving in any code, it might be good to open a first issue specifically about supporting the relevant FITS keywords and what would be needed in WCS, giving some explicit details.

    I will do that ASAP.

  21. astrojuanlu commented on Dec 6, 2020

    @astrojuanlu
    MemberAuthor

    Hi @cmarmo , thanks for drawing my attention (again!) to this issue. It's been a while since I last worked on it, but according to my old comments, this is soft blocked on #7770 - which shouldn't be difficult to fix anyway. I have a few other astropy.coordinates tasks I'd like to work on, but I'm definitely raising the priority of this one.

  22. pllim commented on Mar 17, 2023

    @pllim
    Member

    To those still interested in this issue, please see #11170 for proposed path forward. Thanks!

  23. jacopok commented on Oct 10, 2023

    @jacopok

    Hello, I came across this issue while looking for the functionality of transforming between an ICRS solar-centered frame and one centered on the Moon, with axes rotating so that they remain aligned to its surface.
    It seems like this is completely implemented in @aelanman 's package lunarsky.

    I tried to read #11170 and cannot really understand what's going on - will it implement equivalent functionality? Has it already done so? It seems like it's already closed and the remaining issues are minor, but I cannot find the functionality (documented) in the current version of astropy, 5.3.4.

    My main question is: for a new project requiring this functionality, should we use @aelanman 's package or will there be / is there already some native astropy implementation?

  24. cmarmo commented on Oct 10, 2023

    @cmarmo
    Member

    Hi @jacopok the work in #11170 will be available in Astropy 6.0. I have summed up the implementation on the OpenPlanetary forum if you want to have a look.
    Spheroidal body-fixed reference frames only are implemented in 6.0: transformations between, let's say, ICRS and body-fixed are not available yet.

  25. jacopok commented on Oct 15, 2023

    @jacopok

    I see, thanks! So there is no current plan to implement the transformations as well, correct?
    Is that within the scope of this issue or should an independent one be made to track that feature request?

  26. cmarmo commented on Oct 15, 2023

    @cmarmo
    Member

    I see, thanks! So there is no current plan to implement the transformations as well, correct?

    Let's say there is the intention of , but not current plan to : it needs some time and funding...

    Is that within the scope of this issue or should an independent one be made to track that feature request?

    I believe this is within the scope of the issue, but I let the maintainers comment on this.

  27. mhvk commented on Oct 15, 2023

    @mhvk
    Contributor

    I think indeed the present issue was to ask whether it is possible to transform coordinates to apparent ones on any solar system body. I think astropy should certainly provide the ability to do so - for which we now have a very nice start with @cmarmo's work. I'm less sure whether the actual planetary constants belong; they might more logically be in a specific solar system package (like sunpy provides for the sun). (At least, sadly it does not seem likely a typical astronomer will soon analyze data observed from other planets than Earth...). But in the end, astropy is driven forward by people who make PRs!

  28. Caraffa-git commented on Mar 29, 2025

    @Caraffa-git

    If this works out well, I would like to make the changes to astropy instead of having a separate module, but for now I can work with this.

    @aelanman did you made any progress in this direction? I've come across similar problem, where i have to determine distance between defined point on the moon and specific location on the earth. I don't know if there is a way to do it with the astropy alone but it's kinda off-topic. (I'm not an astrophysicist)

  29. aelanman commented on Mar 29, 2025

    @aelanman

    Hi @Caraffa-git -- As far I'm aware, the last astropy development on that is @cmarmo 's planetary WCS work, but I haven't been following very closely.

    My package lunarsky can certainly do what you're asking, in conjunction with astropy. Feel free to contact me if you want any help with it! You would create a MoonLocation instance with the position you want there, and an EarthLocation instance with the Earth location. Then you'd transform them to a common reference frame (e.g., ITRS for a geocentric position) and measure the cartesian distance between them. Whether or not this is close enough to correct will depend on your application.

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