# [AstroPy] consistency of reference frames between SkyCoord and JPL Horizons

Yang Hon-Jang hjyanghj at gmail.com
Wed Jan 27 09:05:40 EST 2021

I think your problem is nothing to do with astropy, nothing to do with
coordinate transform, GCRS, ICRS....

Explained below, if following paragraphs are hard for reading, please
see attached notebook.

## section 1
In astronomy, we see object/star at where it WAS not now it IS due to
light travel time.

Given $f(t), g(t)$, cartesian coordinate position functions of
observer, target respectively in some coordinate system,
then $h(t)=g(t)-f(t)$ is target's relative position.

When observer observe target, observer see target at target's previous
position(at $t-\delta_t$ due to light travel time).

$t$ and $\delta_t$ satisfy equation

$$\frac{||h(t-\delta_t)||}{c}=\delta_t$$

where c is speed of light.

If $t$ is fixed, we can solve $\delta_t$, then observer(at time $t$)
observe target at $h(t-\delta_t)$ location.

## section 2
Suppose given only $g(t_0)$ at fixed $t_0$, even we know whole $f(t)$
function, we can't compute which direction we can see the target at
$t_0$.

## section 3

In your senario, the task(using [position of an asteroid **at one
epoch**] to compute its astrometric position) is impossible as stated
above. Nothing to do with coordinate transform.

On Fri, Apr 24, 2020 at 9:09 PM Paolo Tanga <Paolo.Tanga at oca.eu> wrote:
>
> Hi all
>
> I am trying to plug the results by JPL Horizons into the appropriate
> reference system of a SkyCoord object, but it looks very trick. (bewore
> long message, I hope the explanation is clear for the specialists of
> reference systems)
>
> The Horizons server returns two types of equatorial coordinates:
> "astrometric" (1) and (2) "apparent".
>
> Their description is the following:
>
> - (1): astrometric RA and Dec with respect to the observing site
> (coordinate origin) in the reference frame of
> the planetary ephemeris (ICRF). Compensated for down-leg light-time
> delay aberration.
>
> - (2): Airless apparent RA and Dec of the target with respect to an
> instantaneous reference frame defined by the Earth equator of-date
> (z-axis) and meridian containing the Earth equinox of-date (x-axis,
> IAU76/80). Compensated for down-leg light-time delay, gravitational
> deflection of light, stellar aberration, precession & nutation. Note:
> equinox (RA origin) is offset -53 mas from the of-date frame defined by
> the IAU06/00a P & N system.
>
> My guess is none of these two systems correspond to either ICRS or GCRS
> as defined in astropy. The simplest possibility for me, would have been
> to assimilate (1), computed for the Solar System barycenter, to ICRS.
> But definitely (2) is not GCRS and the test below easily proves that.
>
> Verification (see the attached notebook if you want to play with) :
>
> - I queried for Solar System barycentric coordinates (1) of an asteroid
> at one epoch. I inserted them in a SkyCoord object as ICRS and use the
> transform_to(GCRS) towards geocentric, at the given epoch.
>
> - I queried again JPL Horizons for the apparent coordinates (2) from the
> geocenter, directly.
>
> As expected, by comparing the results I get the patent confirmation that
> GCRS is not the frame of (2), with a discrepancy of 16 arcmin in my
> case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put apparent coordinates
> (2) aside for the moment.
>
> Second possibility (see notebook again).
>
> I take coordinates (1), for the geocentric observer. I insert them as
> GCRS in a SkyCoord object. I trasform_to(ICRS) (barycentric observer)
> and compare the result to a query of (1) directly for the barycentric
> observer.
>
> Again this SHOULD NOT WORK accurately. In fact the definition of (1)
> does not contain annual aberration and light deflection that are part of
> GCRS. A difference of several arcsec (mostly due to annual aberration)
> SHOULD show up. And in fact IT DOES, ~8 arcsec of difference.
>
> The conclusions if that using SkyCoord with the output of JPL Horizons
> is far from obvious to the end user...
>
> ----
>
> So, my final questions/remarks are:
>
> - How to get a fully accurate consistency between a SkyCoord frame and
> JPL Horizons output, in the case of a barycentric, geocentric or
> topocentric observer, for both "astrometric" and "apparent" coordinates
> as provided by JPL? Which reference SkyCoord should use and how?
>
> - Does astropy implement GCRS correctly in the case of Solar System
> objects, by taking into account aberration and light deflection in the
> relativistic form, for an object at finite distance (different than for
> the stars!) ?
>
> - ...or... Am I missing something fundamental in my interpretation?
>
> - Eventually, this query to Horizons turns our to be tricky to manage as
> SkyCoord for the final user. I think it would be useful to provide the
> correct recipe and/or directly a SkyCoord as output of the query...
>
> Best regards
>
> Paolo
>
>
> --
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la Côte d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>                                           https://twitter.com/ziggypao
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: astrometric-question.ipynb
Type: application/octet-stream
Size: 1917 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/astropy/attachments/20210127/9903add3/attachment.obj>


More information about the AstroPy mailing list