jplhorizons packed designation resolution

[ben-cassese]

Hello!

Thanks for all the work maintaining this package! I've found a bug when querying JPL Horizons for the state of certain particles, but to be honest, I'm not sure this is the appropriate place for this report since I think the issue is with the Horizons API, not astroquery. Still, I wanted to leave this in case this trips up anyone else.

When querying a small body via its packaged designation that happens to be very similar to another small body's packed designation, Horizons will incorrectly return information about the other body. For example, in the case of "K12TB3C" (unpacked: 2012 TC113) vs "K12Tb3C" (unpacked: 2012 TC373), astroquery resolves both as 2012 TC113:

from astropy.time import Time
from astroquery.jplhorizons import Horizons

t0 = Time("2020-01-01")

obj1 = Horizons(
    id="K12TB3C",
    location="500@0",
    epochs=t0.tdb.jd,
    id_type="smallbody",
)
vecs1 = obj1.vectors(refplane="earth")

obj2 = Horizons(
    id="K12Tb3C",
    location="500@0",
    epochs=t0.tdb.jd,
    id_type="smallbody",
)
vecs2 = obj2.vectors(refplane="earth")

vecs1["targetname"], vecs2["targetname"]

(<MaskedColumn name='targetname' dtype='str12' unit='---' length=1>
 (2012 TC113),
 <MaskedColumn name='targetname' dtype='str12' unit='---' length=1>
 (2012 TC113))

I think the problem comes from Horizons, not astroquery, since when I query the API manually with the similar inputs I get the same result. However, when we use the full unpacked names, both astroquery and manual prompting of the API produce the correct output. Interestingly, the Horizons App online interface also correctly resolves the two different objects when we use their packed designations: it's only when using the API that there's a problem.

Thanks again!

[bsipocz]

cc @mkelley

[ben-cassese]

Looking more into the Horizons documentation, I see that you can avoid this behavior with COMMAND= DES='nnn' for a given provisional designation. In astroquery you can set this option with `id_type="designation". So, definitely on me for missing this initially! This now works:

from astropy.time import Time
from astroquery.jplhorizons import Horizons

obj1 = Horizons(
    id="K12TB3C",
    location="500@0",
    epochs=Time("2020-01-01").tdb.jd,
    id_type="designation",
)
vecs1 = obj1.vectors(refplane="earth")

obj2 = Horizons(
    id="K12Tb3C",
    location="500@0",
    epochs=Time("2020-01-01").tdb.jd,
    id_type="designation",
)
vecs2 = obj2.vectors(refplane="earth")

vecs1["targetname"], vecs2["targetname"]

(<MaskedColumn name='targetname' dtype='str12' unit='---' length=1>
 (2012 TC113),
 <MaskedColumn name='targetname' dtype='str12' unit='---' length=1>
 (2012 TC373))

However, frustratingly it looks like you can't use "designation" for a numbered object, in either its packed or unpacked form. This throws an error:

obj3 = Horizons(
    id="00001",
    location="500@0",
    epochs=Time("2020-01-01").tdb.jd,
    id_type="designation",
)
vecs3 = obj3.vectors(refplane="earth")

ValueError: Unknown target (00001). Maybe try different id_type?

Again, this seems to be the default behavior of the Horizons API, not astroquery. Overall I wish a) Horizons or Astroquery avoided this foot gun by not automatically attempting to resolve a provisional designation when in the id_type="smallbody" mode, and b) there was a channel that could accept an designation, provisional or numbered, from the MPCORB.DAT file.

[mkelley]

@ben-cassese Thanks for the feedback, those are interesting cases. I'll add that searching for DES=1; returns comet Halley and `Oumuamua, so it seems that "designation" means anything but asteroid permanent numbers.

I think the K12TB3C vs K12Tb3C case is a bug, and I recommend you report that to the Horizons team: https://ssd.jpl.nasa.gov/contact/ .

[ben-cassese]

Will do!