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
{{ message }}
Repository navigation
Add reference frames of planets and other bodies #5898
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:
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?
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".
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?
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
@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!!
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!!
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
a generalized EarthLocation;
conversion of that to a SkyCoord so it can be localized;
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?
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).
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.
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?
@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.
@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.
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?
@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...
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.
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.
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?
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.
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?
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!
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)
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.
Activity
Cadair commentedon Mar 22, 2017
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?
astrojuanlu commentedon Mar 22, 2017
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".
Cadair commentedon Mar 22, 2017
OK, so if we are to define these transformations, what can we use to calculate the offset at a given obs time?
astrojuanlu commentedon Mar 22, 2017
I'm not sure I understand, could you elaborate on what you're missing?
Cadair commentedon Mar 22, 2017
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?
astrojuanlu commentedon Mar 22, 2017
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
Cadair commentedon Mar 22, 2017
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.
mhvk commentedon Mar 22, 2017
@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
sunpyis just as logical, for the planets I don't see another package (poliastrois 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 generalizeEarthLocationas 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!!
astrojuanlu commentedon Mar 22, 2017
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?
😍
pllim commentedon Mar 22, 2017
And perhaps also a function called
find_matt_damon()?mhvk commentedon Mar 22, 2017
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
EarthLocation;SkyCoordso it can be localized;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?
Cadair commentedon Mar 22, 2017
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:
aelanman commentedon Nov 8, 2017
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.
11 remaining items
aelanman commentedon Jan 6, 2020
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
MoonLocationclass, 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?jarmokivekas commentedon Jan 16, 2020
@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_defsin proj4 notation.aelanman commentedon Jan 22, 2020
@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
SkyCoordas 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.cmarmo commentedon Dec 4, 2020
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?
mhvk commentedon Dec 4, 2020
@cmarmo - I'll let @astrojuanlu answer more about the details, but it does seem logical that
astropy.io.fitswould be able to interpret any planetary keywords andastropy.wcsrepresent 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]_RADIUSmapping in the reference you gave. The idea is that we'll use the geodetic representations inEarthLocation(instead of it just being the representation), making it more like a coordinate frame object. This should make it much easier to have equivalentPlanetLocations...cmarmo commentedon Dec 5, 2020
Thanks @mhvk for your answer.
I will do that ASAP.
astrojuanlu commentedon Dec 6, 2020
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.coordinatestasks I'd like to work on, but I'm definitely raising the priority of this one.pllim commentedon Mar 17, 2023
To those still interested in this issue, please see #11170 for proposed path forward. Thanks!
jacopok commentedon Oct 10, 2023
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?
cmarmo commentedon Oct 10, 2023
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.
jacopok commentedon Oct 15, 2023
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?
cmarmo commentedon Oct 15, 2023
Let's say there is the intention of , but not current plan to : it needs some time and funding...
I believe this is within the scope of the issue, but I let the maintainers comment on this.
mhvk commentedon Oct 15, 2023
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!
Caraffa-git commentedon Mar 29, 2025
@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)
aelanman commentedon Mar 29, 2025
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
MoonLocationinstance with the position you want there, and anEarthLocationinstance 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.