Closed mschwamb closed 10 years ago
I've provided a method to highlight regions on the lightcurve which can be used towards this goal as soon as we have the data in place. At the moment I'm randomly generating (fake) transit locations between 0.5 and 3 days "wide."
PH 1.0 we used was cyan for the user drawn markings and red to show the locations of the simulated transit data point - so I'd like to see something similar one color for transits marked by the user and a different color when we show either where the simulated transit is/where the known planet candidates are. I think it separates them out and distinguishes them as separate things. Thoughts?
Also the message that flashed said here is what other people were marking - what I'm talking about it is showing the locations of transits already found (mostly not by PH) plant detections. Just wanted to be clear we're talking about the same thing. As far as I know there is no plan to show people what other people marked in the light curve after submitting. Is that still true?
closing this to open up a separate one with updated information
PH 1.0 doesn't do this for planet candidates. After the classification is submitted a bubble pops up saying, the star is a Kepler favorite (even if the actual known planet candidate's transit wasn't in that section of the light curve presented) and doesn't say report parameters like radius and orbital period.
I grabbed the info from the NASA Exoplanet Archive (NExScI)and picked the relevant columns of the table and made a csv file which you can get at https://dl.dropboxusercontent.com/u/56971802/PH2.0_KOI_info.csv (I include everything from the Kepler of object list false positives, confirmed planets, planet candidates -figured better to give all and it can be sorted what should go in/displayed). Each row is a different planet candidate in the csv file and some stars have multiple planet candidates (more than one transiting exoplanet).
Description of columns are same as what's on NExScI for the listed column names at http://exoplanetarchive.ipac.caltech.edu/docs/API_kepcandidate_columns.html . I just picked what I thought were the most relevant columns + what we have previously stored in for PH 1.0. You can use the epoch (should be the epoch of the first transit it's in the same time format as what the kepler light curves are in) with the orbital period and duration to make a best guess of where the transit is.
I think it's probably best if the interface calculate the transit positions rather than the someone on the science team supplying the times of each predicted transit, so that if more kepler planet candidates and false positives come out or for K2 if known planets come out then it means we add to the database the parameters without waiting for someone on the science team to calculate the values.