Add methods for querying NASA Exoplanet Archive for ephemeris

[bmorris3]

Demo

from lcviz import LCviz
from lightkurve import search_lightcurve

lc = search_lightcurve(
    "TRAPPIST-1", mission='K2', author='EVEREST'
)[0].download().remove_nans().normalize().remove_outliers()

# load into LCviz:
lcviz = LCviz()
lcviz.load_data(lc)
lcviz.show()

# flatten the light curve to remove rotational modulation:
flatten = lcviz.plugins['Flatten']
flatten.window_length = 31
flatten.flatten();

# query for the planets in this system:
ephem = lcviz.plugins['Ephemeris']
ephem.query_for_ephemeris()

# make a new ephemeris viewer for the first three planets:
for planet in ephem.query_result.choices[:3]:
    ephem.query_result = planet
    ephem.adopt_from_catalog_in_new_viewer()

[codecov]

Codecov Report

Attention: Patch coverage is 91.17647% with 6 lines in your changes missing coverage. Please review.

Project coverage is 91.19%. Comparing base (7b78df5) to head (aa1a4f8).
Report is 42 commits behind head on main.

Files with missing lines	Patch %	Lines
lcviz/plugins/ephemeris/ephemeris.py	91.04%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #127      +/-   ##
==========================================
- Coverage   93.92%   91.19%   -2.74%     
==========================================
  Files          37       41       +4     
  Lines        1598     2147     +549     
==========================================
+ Hits         1501     1958     +457     
- Misses         97      189      +92     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kecnry]

I like it! Just a few suggestions, mostly so that we can move towards exposing the API. This will also need test coverage before merge (but I'm guessing that's partly why its still in draft).

I'm not too worried yet about whether this will ultimately live here or need to be shared by other plugins - we're before 1.0 release and haven't committed to backwards compatibility yet, so let's just implement things and we can always change them.

[kecnry]

can we either have the UI reflect this logic (only show coordinate inputs if the name entry is empty or something) or just require inputing a name (is there ever a case where someone would actually want to use this by coordinates? I guess maybe to search for background contamination?)?

[bmorris3]

My main motivation for the backup here is that anyone can generate a file with whatever they want in the "OBJECT" card, and every star has aliases. If the name that they use can't be resolved by the archive, the coordinates provide another way.

[kecnry]

That's fine, I just think we need to think of a UI/UX that helps make that clear. So either a dropdown to choose whether to query by identifier or coords, or have the coords hide when the identifier is not blank might help to make that feel intuitive without having to look in the docs.

[kecnry]

I think eventually we may want to move this up or even into the ephemeris component... component, but this is good for now until we decide what else we want to support for querying (other catalogs, loading from metadata, etc).

Just one comment on the diff and then we can always iterate further later before an official 1.0 release - this definitely is useful to get in ASAP!

[bmorris3]

@kecnry I've renamed adopt_from_catalog_in_new_viewer to create_ephemeris_from_query, and removed the unused method adopt_from_catalog.

[kecnry]

Functionality looks good to me now, just a few requests for API docs, but otherwise I think this is good to go in, thanks!

[kecnry]

query_for_ephemeris, query_result, and create_ephemeris_from_query need to be added to the API docs.