Convert velocities between Topocentric, Geocentric, and Heliocentric frames

[astrofrog]

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

[astrofrog]

I feel like there is going to start being some overlap with SunPy - in particular for the Heliocentric frame.

[quantshah]

Isn't it listed as a GSoc project ?

[astrofrog]

@sahmed95 - indeed it is, just noticed it! It would indeed be a nice GSoC project.

[quantshah]

Yeah, will be a nice addition to SkyCoord I guess

[mhvk]

See also #2244 - and, yes, we should have this! Including of course barycentric velocities.

[eteq]

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 coordinates feature, but it definitely requires some careful planning.

So it should be done, but definitely advenced/high effort!

[keflavich]

👍, also should include LSR conversions

[astrojuanlu]

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.

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]

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. Time already has light_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 a SkyCoord. 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]

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]

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.