[AstroPy] astropy.vo.client conesearch radius problem?
Francisco Gallardo lópez
f.gallardo.lopez at gmail.com
Mon Jan 16 16:20:21 EST 2017
Hi Daniel!
Thanks a lot for replying.
I'm afraid It seems like the attached file was not included (sorry!).
Thanks for raising the Cos(dec) term issue.
Nonetheless, the code of the example can be found below. As you can see the
cone search is as follows: conesearch.conesearch(a,*0.2*u.arcsec*
,catalog_db=k)
The radius is 0.2 arcsec (or I may be missing something). As you point out
the list I was showing in my last email differs by much more than 0.2
arcsec. That is exactly the problem. Moreover the rest of the catalogs
don't show this behavior.
If the radius is not wrongly set (please refer to the conesearch, I think
it is fine, according to the documentation
<http://docs.astropy.org/en/stable/api/astropy.vo.client.conesearch.conesearch.html>),
then by no means the resulting list of sources could be so far from the
center. If the radius is properly set, I don't think the Cos(dec) term
could explain the resulting list with the USNO.
Please find below the example code. Do you see something not properly set?.
According to what I saw no other catalog is showing this behavior apart of
those from USNO. Nonetheless I could be missing something. The rest of the
catalogs return only one source (note I'm using a large list of sky
positions. For this particular position the only catalogs showing results
are the USNO catalogs and it may be due to this problem with the radius as,
as you are pointing out, the closer source in USNO catalogs seems to be 26
arcsec away)
Thanks a lot!
BR
Fran
==============
#!/usr/bin/python
import pdb
from astropy.vo.client import conesearch
from astropy.coordinates import ICRS
from astropy import units as u
from astropy.coordinates import SkyCoord
def main():
ra=159.315075782
dec=-27.6515145412
a=SkyCoord(ra=float(ra)*u.deg,dec=float(dec)*u.deg,frame='icrs')
for k in conesearch.list_catalogs():
try:
temp=conesearch.conesearch(a,*0.2*u.arcsec*,catalog_db=k)
pdb.set_trace()
except:
print "Nothing found."
if __name__=="__main__":
main()
2017-01-16 21:18 GMT+01:00 Daniel Evans <d.f.evans at keele.ac.uk>:
> I'm not entirely sure what radius you're querying, as your quoted
> coordinates vary by much more than 0.2 arcsec, and the nearest object I can
> find in USNO-A2.0 is 26 arcsec away. It looks more like you've used 2
> degrees?
>
> Running the code with 0.20 degrees as the search radius, the RA coordinate
> values do indeed differ by +-0.22 degrees. However, this is entirely
> correct, because a change of 0.2 degrees in RA coordinate does not equal an
> angular separation of 0.2 degrees between two objects (unless you're on the
> equator). The RA coordinate difference must be multiplied by cos(Dec), so
> because you're querying at Dec=-27.65, the angular distance along the RA
> axis is (0.22 degrees) * cos(-27.65) = 0.20 degrees.
>
> (If anything, it seems the USNO ought to be congratulated for seemingly
> being the only catalog providers to remember the cos(Dec) term!)
>
> Regards,
> Daniel
>
> On 16 January 2017 at 19:57, Francisco Gallardo lópez <
> f.gallardo.lopez at gmail.com> wrote:
>
>> Hi Evert!
>>
>> Thanks a lot for answering.
>>
>> I would say it only happens with the USNO catalogs, both 'The PMM
>> USNO-A1.0 Catalogue (Monet 1997) 1' and 'The USNO-A2.0 Catalogue (Monet+
>> 1998) 1'.
>>
>> I created a small code to show the thing (please find it attached to this
>> email).
>>
>> It iterates through all the available catalogs and breaks into the
>> debugger as soon as the query returns some sources (with the AR,DEC
>> hard-coded in the program, only USNO catalogs will return sources). It
>> stores the result in the “temp” variable. No big deal.
>>
>> For instance, with the second catalog (*'The USNO-A2.0 Catalogue (Monet+
>> 1998) 1')* and the sky position (ra=159*.31*5075782, dec=-27.6515145412
>> <(651)%20514-5412>):
>>
>>
>> <Table masked=True length=49>
>> _r USNO-A2.0 RAJ2000 DEJ2000 ... Bmag Rmag
>> Epoch
>> deg deg deg ... mag mag
>> yr
>> float64 str13 float64 float64 ... float32 float32
>> float64
>> ---------- ------------- ---------- ---------- ... ------- -------
>> --------
>> 0.041089 0600-13508332 159.269631 -27.643284 ... 19.3 17.9
>> 1981.701
>> 0.039111 0600-13508442 159.271653 -27.644431 ... 20.2 17.9
>> 1981.701
>> 0.038170 0600-13508467 159.272078 -27.654039 ... 20.6 17.5
>> 1981.701
>> 0.039771 0600-13508743 159.277409 -27.629875 ... 19.8 17.9
>> 1981.701
>> 0.031614 0600-13508894 159.280334 -27.644278 ... 19.8 17.9
>> 1981.701
>> 0.037095 0600-13509081 159.283342 -27.675723 ... 16.1 15.6
>> 1981.701
>> ... ... ... ... ... ... ...
>> ...
>> 0.040114 0600-13512624 159.348720 -27.678370 ... 15.9 15.4
>> 1981.701
>>
>> =========================================================
>>
>>
>> I would say it is not paying attention to the requested radius. (Again,
>> this does not happen with other catalogs, only with the USNO catalogs)
>>
>> Thanks a lot!
>> BR
>> Fran
>>
>> 2017-01-16 8:46 GMT+01:00 Evert Rol <evert.rol at gmail.com>:
>>
>>> Hi Francisco,
>>>
>>> Could you send a short working code example around that shows the actual
>>> problem?
>>> Possibly for both the GSC (ok) and the USNO catalogs (not ok).
>>>
>>> Evert
>>>
>>>
>>>
>>> > Hi all!
>>> >
>>> > I looked in the Internet but I did not find references to this
>>> problem, so maybe I'm making something wrong.
>>> >
>>> > So I'm using the conesearch from astropy.vo.client to query some
>>> catalogs (indeed all the catalogs that are returned by
>>> conesearch.list_catalogs() ).
>>> >
>>> > The thing is, I'm using a radius of 0.2 seconds of arc and it seems
>>> like when querying some catalogs the results seem to be out of that
>>> requested radius. For instance, two sources returned by the query were, one
>>> at ra=5.602814 deg and another one @ ra=5.536589 deg.
>>> >
>>> > That does not happen with the 'Guide Star Catalog v2 1' which seems to
>>> work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue
>>> (Monet 1997) 1'.
>>> >
>>> > Am I missing something or making something wrong or is it a known bug?
>>> >
>>> > Thanks a lot!
>>> > BR
>>> > Fran Gallardo
>>> > _______________________________________________
>>> > AstroPy mailing list
>>> > AstroPy at scipy.org
>>> > https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> https://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20170116/ad1b2c35/attachment.html>
More information about the AstroPy
mailing list