Search provides two TPFs for Kepler-76

Problem description

Kepler-76b is in two tpfs. When we search for it, we get both back

Example

lk.search_targetpixelfile('kepler-76', quarter=3)

Expected behavior

It should only provide one file.

[scfleming]

OK so the cause is that these two targets are so close together in the sky that their footprints (which are 4 or 8 arcsecond squares in the Portal, cant remember which) on the sky overlap each other when searching for the exact position of the one star. See attached screenshot doing a very tight search of 1 arcsecond directly on the coordinate of the other target.

The distance column is the separation between the search coordinate and the closest edge of an observation’s footprint. So, because this coordinate is within the footprints of BOTH Kepler targets, that column is listed as “0.0” for both targets, even though on-sky they are separated by 7+ arcseconds. Note the mouseover description text for Distance in the Portal UI is not correct, I will file a ticket here to fix that.

As an immediate fix, you can further refine the closest target by using the RA and DEC columns of the returned footprints to caculate among those with distance=0 which one is actually closest to your search position (in this case, one should give you 0 and the other several arcseconds).

One possibility to reduce this problem on our side would be to assign footprints on sky that are point sources (no actual dimensions) but there are trade-offs there too (if you don’t have a perfect position or big enough search area you might miss a target entirely). Hope this helps for now at least to understand why this behavior is happening (it is correct based on what the actual definition of distance is as defined in the Portal).

[scfleming]

Oh sorry, since your screen shot had coordinates I thought you were searching on those. Yeah using the name resolver to get back resolved coordinates should work provided the user is searcing on an identiier it understands. I’ll ask about why that function is private…