Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Coordinates and proper motion #4344

Closed
hamogu opened this issue Nov 24, 2015 · 7 comments

Comments

@hamogu
Copy link
Member

commented Nov 24, 2015

Is there a way to add proper motion to a SkyCoord object and calculate the position on the sky at a different time?
I did not find a good way to do that, so I tried to calculate the change in position myself (as delta_t * proper_motion), so that I could assign the new value to my coord.ra and coord.dec. That did not work either, because .ra and .dec cannot be modified.

from astropy import coordinates

import astropy.units as u

c = coordinates.SkyCoord.from_name('HD140283')

c.ra = 8.5 * (-1115. * u.marcsec)

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-9-c41ebd38338f> in <module>()
      2 import astropy.units as u
      3 c = coordinates.SkyCoord.from_name('HD140283')
----> 4 c.ra = 8.5 * (-1115. * u.marcsec)

/melkor/d1/guenther/soft/anaconda/lib/python2.7/site-packages/astropy-1.1.dev14143-py2.7-linux-x86_64.egg/astropy/coordinates/sky_coordinate.pyc in __setattr__(self, attr, val)
    445                 (not attr.startswith('_') and
    446                  hasattr(self._sky_coord_frame, attr))):
--> 447                 setattr(self._sky_coord_frame, attr, val)
    448 
    449             frame_cls = frame_transform_graph.lookup_name(attr)

/melkor/d1/guenther/soft/anaconda/lib/python2.7/site-packages/astropy-1.1.dev14143-py2.7-linux-x86_64.egg/astropy/coordinates/baseframe.pyc in __setattr__(self, attr, value)
   1041         if attr in repr_attr_names:
   1042             raise AttributeError(
-> 1043                 'Cannot set any frame attribute {0}'.format(attr))
   1044         else:
   1045             super(BaseCoordinateFrame, self).__setattr__(attr, value)

AttributeError: Cannot set any frame attribute ra

I ended up with the following solution (targets is a table with target names and obsdates):

# I looked up those numbers on SIMBAD by hand and pasted them here
simbadcoords = ['15 43 03.09706 -10 56 00.6036', '03 08 25.58962 +26 19 51.3957', '04 03 14.99911 +35 16 23.7899']
simbadmotion = [(-1114.93, -304.36), (-207.97, -830.01), (1732.84, -1365.72)]
simbadparallax = [17.16, 24.92, 54.68]

coos = SkyCoord(simbadcoords, unit=(u.hourangle, u.deg), frame='icrs')
ra = []
dec = []
for i, c in enumerate(coos):
    delta_t = time.Time(targets['Obs date'][i]).decimalyear - 2000.
    ra.append(c.ra + delta_t * simbadmotion[i][0] * u.marcsec)
    dec.append(c.dec + delta_t * simbadmotion[i][1] * u.marcsec)
finalcoos = SkyCoord(ra, dec)

targets['pos'] = finalcoos

It works, but it seems more complicated than it has to be.

@pllim pllim changed the title Feature request: Coordiantes and proper motion Feature request: Coordinates and proper motion Nov 24, 2015

@embray embray added the coordinates label Nov 24, 2015

@eteq

This comment has been minimized.

Copy link
Member

commented Dec 18, 2015

@hamogu - the answer to your question thus far is no. But we really do want that feature, so this is something that would be nice to target for 1.2.

A few thoughts about this, in no particular order:

  • It's a feature that you can't update coordinates the way you're wanting here - there's a lot of subtleties in deciding how to relate coordinate frames to proper motions - that is, are you also updating the equinox as time goes on (for a coordinate frame that has equinoxes)? Or if you're in FK4 do you want to update the e-terms but not the equinox? (Some catalogs from back in the FK4 era actually do that.) It also makes it much easier to trust that we can cache things, like the cartesian<->spherical transformations, if the frame can't be updated without creating a new object.
  • So in my head the more natural way is to create something like ProperMotion objects that take in a SkyCoord and proper motions, and then when you call it it yields a new SkyCoord at the appropriate time. That way those details can be locked away in one place (the ProperMotion class) and you can trust that they'll do what you expect. Admittedly, this feels a bit icky from a relativistic perspective (where spatial and time coordinates should be on the same front), but in practice for most situations, keeping them separated is more akin to what we actually do.
  • It probably also makes sense to try to integrate this with the other high-priority feature for coordinates: velocities. That is, there's a natural connection between proper motions, RVs, and the positions - but there are a variety of subtlties in considering the best way to define velocities given that coordinate frames can be in various different representations. None of it is at all insurmountable, but it requires some time and work to decide what's the best way to actually implement it.

Sometime in Jan/early Feb hopefully we'll have a hangout to discuss plans for coordinates in 1.2. Hopefully we can discuss the topic more then?

@Juanlu001

This comment has been minimized.

Copy link
Member

commented Feb 4, 2016

Subscribing to this issue as @mhvk pointed me here after raising up the need of having velocity transformations also for bodies in the Solar System (see https://groups.google.com/d/msg/astropy-dev/UZJ5764jGec/WEaPjaRIAwAJ).

@Juanlu001

This comment has been minimized.

Copy link
Member

commented Jul 2, 2016

May I ask, what was discussed in the hangout regarding this? Should #4268 be addressed before working on proper motions or are they separate issues?

@kelle

This comment has been minimized.

Copy link
Member

commented May 5, 2017

Any update/progress on this? Is it worthy of an unconference session at PyAstro17? I have a student who could potentially do some work on this this summer. cc @adrn

@adrn

This comment has been minimized.

Copy link
Member

commented May 5, 2017

There should definitely be discussion about this, but it's still not clear to me whether we open it up (as an unconference) or keep it internal until we have a trial implementation to discuss.

@mhvk

This comment has been minimized.

Copy link
Contributor

commented May 5, 2017

@kelle - @adrn, @eteq, @astrofrog and I had a hangout together; one result of that is #5871, which aims to provide the underlying machinery to represent positional differences. @adrn has been trying it out (and seem to like it), but more eyes would be most welcome! The next step was for @adrn and @eteq to think through the higher-level interface, with specific test cases identified (conversion to the local standard of rest being one, IIRC). Thoughts again most appreciated; it is not a trivial problem...

@adrn

This comment has been minimized.

Copy link
Member

commented Sep 18, 2017

@adrn adrn closed this Sep 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.