<p>The issue is with differences in how the defaults behave between the code and the website. In the code version of the API <code>id=3</code> gives the Earth-Moon Barycenter (as opposed to <code>id=399</code> which is the Earth itself; not sure which is wanted but it's not the most significant problem). The major problem is that <code>location=0</code> in the Python code produces the position of Greenwich Observatory relative to the geocenter, which is why the numbers are so small (~2850 km).</p>
<p>To get the desired position of the Earth relative to the Solar System Barycenter requires using <code>location='500@0'</code> in the code (I also used <code>astropy.units</code> to do the conversion to km):</p>
<pre><code>from astroquery.jplhorizons import Horizons
import astropy.units as u
from datetime import datetime, timedelta
today = datetime(2022,2,7)
yesterday = today - timedelta(days=1)
obj_earth = Horizons(id='399', location='500@0', epochs={'start':str(yesterday), 'stop':str(today),'step':'1d'})
print(obj_earth.vectors().columns['x'].to(u.km))
</code></pre>
<p>This produces the following output, matching the web query:</p>
<pre><code>[-1.08939344e+08 -1.10724448e+08] km
</code></pre>
<p>(As an aside to help diagnose this, you can do <code>obj_earth.uri</code> which shows the query URL string (urlencoded) in the same format as originally posted. This showed that the original Python code was submitting <code>CENTER=0</code> not the desired <code>CENTER=500@0</code>)</p>

CC BY-SA 4.0
2023-02-06T18:29:45.933Z
2023-02-06T18:29:45.933Z
astrosnapper
<p>On JPL Horizons website, I'm using the following query to get vector state for Earth:</p>
<pre><code>MAKE_EPHEM=YES
COMMAND=3
EPHEM_TYPE=VECTORS
CENTER='500@0'
START_TIME='2023-02-06'
STOP_TIME='2023-02-07'
STEP_SIZE='1 DAYS'
VEC_TABLE='3'
REF_SYSTEM='ICRF'
REF_PLANE='ECLIPTIC'
VEC_CORR='NONE'
OUT_UNITS='KM-S'
VEC_LABELS='YES'
VEC_DELTA_T='NO'
CSV_FORMAT='NO'
OBJ_DATA='YES'
</code></pre>
<p>I'm getting two values for 'x', which I guess make perfect sense, being in km:</p>
<pre><code>X =-1.085163786984627E+08
X =-1.103097877035814E+08
</code></pre>
<p>I'm trying to have the same query in Python, using <code>jplhorizons</code> from <code>astroquery</code> library, like this:</p>
<pre><code>from astroquery.jplhorizons import Horizons
from datetime import datetime, timedelta
today = datetime.now()
yesterday = today - timedelta(days=1)
obj_earth = Horizons(id='3', location='0', epochs={'start':str(yesterday), 'stop':str(today),'step':'1d'})
print(obj_earth.vectors().columns['x'])
</code></pre>
<p>Running this code, I get the following output:</p>
<pre><code>          x           
          AU          
----------------------
-3.582503526151746e-05
-3.948114036370441e-05
</code></pre>
<p>The values are apparently in AU, but honestly, they make no sense to me. Shouldn't I get the exact same values running this through web Horizons' interface and through the script --even if the values are in different units?</p>

CC BY-SA 4.0
2023-02-06T17:56:31.367Z
Not sure why you aren't defining `today` and `yesterday` in the Python code as a specific `datetime` values matching your web query rather than the ever-changing `.now()`... ? Am I missing something ?
astrosnapper
CC BY-SA 4.0
2023-02-06T18:01:44.710Z
No specific reason. Not a great choice, I know. I changed them to:
`today = '2023-02-07'
yesterday = '2023-02-06'`
I'm getting wildly different values for `x` this way, and I still don't understand what's happening, why the values are so small.
Claudiu
CC BY-SA 4.0
2023-02-06T18:06:07.343Z
I suspect a reference frame difference but wanted to check the difference in the time specification wasn't significant before investigating since using an incorrect/different time system (TDB vs UTC) often leads to differences (but not this large)
astrosnapper
CC BY-SA 4.0
2023-02-06T18:10:26.427Z
The `x` values returned by the Python script just don't *feel* AU. Even if it says it's in AU.
Claudiu
CC BY-SA 4.0
2023-02-07T01:00:30.217Z
It's pretty easy to use the [Horizons file API](https://ssd-api.jpl.nasa.gov/doc/horizons_file.html). Or you can use the [GET-based API](https://ssd-api.jpl.nasa.gov/doc/horizons.html) to send a query in a URL. [Query demo](https://ssd.jpl.nasa.gov/api/horizons.api?format=text&MAKE_EPHEM=YES&COMMAND=3&EPHEM_TYPE=V&CENTER=500%400&TLIST=%272023-02-06%27&VEC_TABLE=3&REF_PLANE=ECLIPTIC&VEC_CORR=NONE&OUT_UNITS=KM-S&VEC_LABELS=YES&VEC_DELTA_T=NO&CSV_FORMAT=NO&OBJ_DATA=YES). I have several examples on this site which use the file API in Python, but I'll post a minimal example in my next comment.
PM 2Ring
CC BY-SA 4.0
2023-02-07T01:00:49.323Z
https://sagecell.sagemath.org/?z=eJxdkUFr4zAQhe8C_QdtWlACieJ12C0UBFUchXprWcZWC9mLMBu3dUls11JKael_7zgkl70I5nvzhtG8C3Lb9vVH2ziyrfYtI5kiYV43TyQMwgULQhZcYVTvu7b3pK9eD5XzDiOMDv2OcDJ69r5z1_O5c1v20u1YU7qSPbVv87Kr58-n0fax3lUMyGhw_ttvB-cIih-Xl4VeY6TEnbQyu5WKb2SBUaSVEumKLzA6Ums2meQPMjI6H2SZGplz-isIbgKKUWFEbqyJleR0WHsWhLPg91HQ2f_86shlZov4L_CfZCU2BTCYbo1YJsAWUOZybYsNNCpO4yhfn1CWiBQ6ZJTEmYmjky_SOayT6lQC0PfG3qexKTi9U7Pz6EQsZQII_nciK5kYYc3gAxIVD3atcyXOQC__2JUw4mw5HgwjyACud06Cda3zY8hiSralL_knfWz7fenpNaG-evf0a0qG4ztQ6qY7DMKYQgJ0SuCdfE0w6vq68WOYyAbH5BuvQZEh&lang=sage
PM 2Ring
<solar-system><earth><python><ephemeris>
Different results for the same JPL Horizons query
Claudiu
# Different results for the same JPL Horizons query

(Asked by: username_0 on 2023-02-06)

On JPL Horizons website, I'm using the following query to get vector state for Earth:
MAKE_EPHEM=YES
COMMAND=3
EPHEM_TYPE=VECTORS
CENTER='500@0'
START_TIME='2023-02-06'
STOP_TIME='2023-02-07'
STEP_SIZE='1 DAYS'
VEC_TABLE='3'
REF_SYSTEM='ICRF'
REF_PLANE='ECLIPTIC'
VEC_CORR='NONE'
OUT_UNITS='KM-S'
VEC_LABELS='YES'
VEC_DELTA_T='NO'
CSV_FORMAT='NO'
OBJ_DATA='YES'

I'm getting two values for 'x', which I guess make perfect sense, being in km:
X =-1.085163786984627E+08
X =-1.103097877035814E+08

I'm trying to have the same query in Python, using jplhorizons from astroquery library, like this:
from astroquery.jplhorizons import Horizons
from datetime import datetime, timedelta
today = datetime.now()
yesterday = today - timedelta(days=1)
obj_earth = Horizons(id='3', location='0', epochs={'start':str(yesterday), 'stop':str(today),'step':'1d'})
print(obj_earth.vectors().columns['x'])

Running this code, I get the following output:
          x           
          AU          
----------------------
-3.582503526151746e-05
-3.948114036370441e-05

The values are apparently in AU, but honestly, they make no sense to me. Shouldn't I get the exact same values running this through web Horizons' interface and through the script --even if the values are in different units?

**Tags:** solar-system, earth, python, ephemeris
> **Comments:**
> **username_1**: Not sure why you aren't defining `today` and `yesterday` in the Python code as a specific `datetime` values matching your web query rather than the ever-changing `.now()`... ? Am I missing something ?  
> **username_0**: No specific reason. Not a great choice, I know. I changed them to: `today = '2023-02-07' yesterday = '2023-02-06'` I'm getting wildly different values for `x` this way, and I still don't understand what's happening, why the values are so small.  
> **username_1**: I suspect a reference frame difference but wanted to check the difference in the time specification wasn't significant before investigating since using an incorrect/different time system (TDB vs UTC) often leads to differences (but not this large)  
> **username_0**: The `x` values returned by the Python script just don't *feel* AU. Even if it says it's in AU.  
> **username_2**: It's pretty easy to use the [Horizons file API](https://ssd-api.jpl.nasa.gov/doc/horizons_file.html). Or you can use the [GET-based API](https://ssd-api.jpl.nasa.gov/doc/horizons.html) to send a query in a URL. [Query demo](https://ssd.jpl.nasa.gov/api/horizons.api?format=text&MAKE_EPHEM=YES&COMMAND=3&EPHEM_TYPE=V&CENTER=500%400&TLIST=%272023-02-06%27&VEC_TABLE=3&REF_PLANE=ECLIPTIC&VEC_CORR=NONE&OUT_UNITS=KM-S&VEC_LABELS=YES&VEC_DELTA_T=NO&CSV_FORMAT=NO&OBJ_DATA=YES). I have several examples on this site which use the file API in Python, but I'll post a minimal example in my next comment.  
> **username_2**: https://sagecell.sagemath.org/?z=eJxdkUFr4zAQhe8C_QdtWlACieJ12C0UBFUchXprWcZWC9mLMBu3dUls11JKael_7zgkl70I5nvzhtG8C3Lb9vVH2ziyrfYtI5kiYV43TyQMwgULQhZcYVTvu7b3pK9eD5XzDiOMDv2OcDJ69r5z1_O5c1v20u1YU7qSPbVv87Kr58-n0fax3lUMyGhw_ttvB-cIih-Xl4VeY6TEnbQyu5WKb2SBUaSVEumKLzA6Ums2meQPMjI6H2SZGplz-isIbgKKUWFEbqyJleR0WHsWhLPg91HQ2f_86shlZov4L_CfZCU2BTCYbo1YJsAWUOZybYsNNCpO4yhfn1CWiBQ6ZJTEmYmjky_SOayT6lQC0PfG3qexKTi9U7Pz6EQsZQII_nciK5kYYc3gAxIVD3atcyXOQC__2JUw4mw5HgwjyACud06Cda3zY8hiSralL_knfWz7fenpNaG-evf0a0qG4ztQ6qY7DMKYQgJ0SuCdfE0w6vq68WOYyAbH5BuvQZEh&lang=sage  

---

## 1 answers

### Answer by username_1 on 2023-02-06. Score: 7 | Accepted answer

The issue is with differences in how the defaults behave between the code and the website. In the code version of the API id=3 gives the Earth-Moon Barycenter (as opposed to id=399 which is the Earth itself; not sure which is wanted but it's not the most significant problem). The major problem is that location=0 in the Python code produces the position of Greenwich Observatory relative to the geocenter, which is why the numbers are so small (~2850 km).
To get the desired position of the Earth relative to the Solar System Barycenter requires using location='500@0' in the code (I also used astropy.units to do the conversion to km):
from astroquery.jplhorizons import Horizons
import astropy.units as u
from datetime import datetime, timedelta
today = datetime(2022,2,7)
yesterday = today - timedelta(days=1)
obj_earth = Horizons(id='399', location='500@0', epochs={'start':str(yesterday), 'stop':str(today),'step':'1d'})
print(obj_earth.vectors().columns['x'].to(u.km))

This produces the following output, matching the web query:
[-1.08939344e+08 -1.10724448e+08] km

(As an aside to help diagnose this, you can do obj_earth.uri which shows the query URL string (urlencoded) in the same format as originally posted. This showed that the original Python code was submitting CENTER=0 not the desired CENTER=500@0)


---

