Repository navigation
Exoplanet quantities proposal #764
Description
I'm beginning to develop a set of tools for parsing exoplanet catalog parameters and returning them as astropy.unit.Quantitys, with the intention of incorporating them into an astropy-affiliated package (this one or a new one). I'm opening this issue to start discussion on the topic after it was suggested that I do so on Twitter, to evaluate whether or not it could belong in astroquery.
The current prototype repository (which I intend to add more to) is developed using the astropy package template and has basic tests. The main feature is a class called PlanetParams which does the following:
>>> from exoparams import PlanetParams
>>> p = PlanetParams('HAT-P-11 b')
>>> p.per # orbital period
<Quantity 4.8878162 d>
>>> p.tt # mid-transit time
<Time object: scale='utc' format='jd' value=2454605.89132>
>>> p.transit # is planet transiting?
True
>>> p.r # planet radius
<Quantity 0.422 jupiterRad>
>>> p.mass # planet mass
<Quantity 0.0825354 jupiterMass>
>>> (p.mass / (4./3 * 3.1415 * p.r**3)).decompose() # computer your own planet density
<Quantity 1362.4203351174147 kg / m3>
>>> p.orbref # Show reference for planet's orbit
'Bakos 2010'The data come from a CSV archive of the exoplanets.org database, which gets (optionally) cached on the user's local machine, for convenience. A future version of the package will support alternative databases, like NExScI's. I also intend to return the full exoplanet parameter astropy.table.Table with the appropriate units assigned to each column (which is a small addition to what's already available in the prototype).
This means of accessing planet parameters is convenient for exoplanet folk, but breaks with the API in other astroquery modules.
Activity
keflavich commentedon Oct 11, 2016
@bmorris3 It is fine to have a new service that breaks from the "standard" astroquery API. I think this program is reasonable to include as part of astroquery. Including it here would also make it (marginally) more discoverable.
It would be pretty neat if we had comparable things for, e.g., stars from SIMBAD. Basically, the
PlanetParamsobject is a wrapper around some returned data from a (sometimes) remote query. Probably the main thing to do for this to make sure it kinda matches astroquery's general theme is to have aquery_exoplanet_catalogtool/method that would return aTable. Most of the main functionality, though, can be included in thePlanetParamsclass.@bsipocz, anything to add? Any objections?
bsipocz commentedon Oct 11, 2016
@bmorris3 - This definitely looks appropriate for astroquery. There are a few services where there is no API available and astroquery web scrapes instead, similarly to this.
However I agree with @keflavich, it would be nice if the default methods would return a Table, just like the other modules do.
bsipocz commentedon Nov 1, 2017
#771 addressed this, so I'm closing it now.