Repository navigation
Convert velocities between Topocentric, Geocentric, and Heliocentric frames #3544
Description
It would be nice to have functionality to convert between all these frames of reference. It seems we have all the pieces of the puzzle, including SkyCoord, Time, EarthLocation, and access to all wrapped ERFA functions (unless I'm missing something?).
EDIT: this would be a good GSoC project, and the people to contact are @eteq and @adrn
Activity
astrofrog commentedon Feb 24, 2015
I feel like there is going to start being some overlap with SunPy - in particular for the
Heliocentricframe.quantshah commentedon Feb 24, 2015
Isn't it listed as a GSoc project ?
astrofrog commentedon Feb 24, 2015
@sahmed95 - indeed it is, just noticed it! It would indeed be a nice GSoC project.
quantshah commentedon Feb 24, 2015
Yeah, will be a nice addition to SkyCoord I guess
mhvk commentedon Feb 24, 2015
See also #2244 - and, yes, we should have this! Including of course barycentric velocities.
eteq commentedon Mar 5, 2015
Note that this is a major undertaking because we have to build an entire framework from scratch for velocities to be able to do this. And we have to get that really right due to the fact that it's critical for PMs, RV measurements, and similar stuff that is high-precision bread-and-butter sort of astronomy. @adrn and I have talked about this as the next major
coordinatesfeature, but it definitely requires some careful planning.So it should be done, but definitely advenced/high effort!
keflavich commentedon Apr 19, 2015
👍, also should include LSR conversions
astrojuanlu commentedon Aug 11, 2016
And also for astrodynamics :) Once velocity measurements land into astropy, I will be able to use them in poliastro and take advantage of the frame conversion routines.
mhvk commentedon Oct 26, 2016
Just a link back to some discussion in astropy/specutils#112, and particularly https://gist.github.com/StuartLittlefair/5aaf476c5d7b52d20aa9544cfaa936a1
The main question now is where to put this.
Timealready haslight_travel_time, so it might be OK to put a barycentric velocity there as well. On the other hand, perhaps most people would try to find it in aSkyCoord. Maybe, in fact, this is one example where it makes sense to have both? Both methods could call a common function, just swapping the arguments around a bit.eteq commentedon Jan 24, 2017
To add more to #3544 (comment) - this connects back to the bigger question of whether velocity frames in general should be a thing tied to coordinate frames, or independent, or loosely coupled.
eteq commentedon Sep 20, 2017
In principal this was addressed by the velocities framework now in v2.0. I'm not sure we've tested all these use cases, but that's a subtly different question so I think this issue can now be closed.