Open mkelley opened 8 months ago
And, here are some code examples that I am trying to design to:
Examples
--------
Object specifications:
>>> from astroquery.jplhorizons import Horizons2
>>> Horizons2.query_observer("Jupiter")
>>>
>>> Horizons2.query_observer("1", center="568")
>>>
>>> Horizons2.query_observer("europa", center="I41", id_type="name")
>>>
>>> Horizons2.query_observer("2P", id_type="designation")
>>> Horizons2.query_observer("2P",
... id_type="designation",
... closest_apparition=True)
>>>
>>> Horizons2.query_observer("73P",
... id_type="designation",
... closest_apparition=True,
... fragments=False)
>>>
>>> tab = Horizons2.query_observer(
... "comet",
... id_type="orbit",
... epoch=Time(2450200.5, scale="tdb", format="jd"),
... ec=0.8241907231263196,
... qr=0.532013766859137 * u.au,
... tp=Time(2450077.480966184235, scale="tdb", format="jd"),
... om=89.14262290335057 * u.deg,
... w=326.0591239257098 * u.deg,
... in=4.247821264821585 * u.deg,
... a1=-5.113711376907895D-10 * u.au / u.d**2,
... a2=-6.288085687976327D-10 * u.au / u.d**2)
The observer (ephemeris center) can also be an
`~astropy.coordinates.EarthLocation`:
>>> from astropy.coordinates import EarthLocation
>>> college_park = EarthLocation.from_geodetic(-76.9378 * u.deg,
... 38.9897 * u.deg,
... 21 * u.m)
>>> tab = Horizons2.query_observer("Jupiter", center=college_park)
Specifying time:
>>> from astropy.time import Time
>>> import astropy.units as u
>>> tab = Horizons2.query_observer("Jupiter",
... start_time=Time("2023-12-11"),
... stop_time=Time("2023-12-12"),
... step_size=1 * u.hr)
>>>
>>> times = Time(["2023-12-11", "2023-12-20", "2024-01-08"])
>>> tab = Horizons2.query_observer("Jupiter", tlist=times)
Thank you @mkelley for taking care of the jplephem module. I honestly think it's one of the most used modules (if not no1) and therefore people are running into more issues than with other ones.
Some big-picture thoughts, without going into your implementation details:
points 6 and 7: What do you think about using a QTable right away? The rest of the points sound totally reasonable!
Thanks, @bsipocz . I agree with all your points! I'll try QTable
first.
My experience with the current jplhorizons sub-module suggests to me that it requires more maintenance than what I think is ideal. In addition, since it was written astroquery, astropy, and Horizons have evolved substantially, including the publication of a versioned Horizons API. I am attempting to write a new jplhorizons module from scratch that is at its heart aligned with the Horizons API as closely as possible, but also taking advantage of key astropy/astroquery infrastructure. I also want a user to be able to primarily refer to the Horizons documentation to develop their query, then implement it with astroquery as seamlessly as possible.
For the moment, I'm calling this new implementation
Horizons2
.Some design goals:
Horizons2.query_observer
for EPHEM_TYPE=OBSERVER, see https://ssd-api.jpl.nasa.gov/doc/horizons.html#ephem_typeEarthLocation
objectsget_query_payload=
andcache=
Table
without any column renaming and including all relevant metadata in theTable.meta
attributeTime
objectsSkyCoord
objects, with the appropriate reference frame definedUltimately, I'd like to more easily support all of Horizon's features, future-proof or at least simplify most minor version updates to the Horizons API, and keep the majority of the maintenance limited to astropy+astroquery version support.
This issue is intended to announce the development of
Horizons2
and to collect questions and feedback. I have a branch started at: https://github.com/mkelley/astroquery/tree/horizons2 Time frame for completion is probably six to twelve months.