[AstroPy] astropy.vo.client conesearch radius problem?
Daniel Evans
d.f.evans at keele.ac.uk
Mon Jan 16 17:07:48 EST 2017
Playing around again, I do now see your problem! I think I hadn't got the
output showing correctly before I played with the arcsec/degrees part.
After a lot of poking around on the CDS (which is what Astropy is querying
for the USNO catalogs), it appears to be a problem with parsing Astropy's
preferred format for cone radius. Whilst the CDS allows radius in degrees,
arcmin, or arcsec, Astropy is querying with a very small degree value in
scientific notation - 5.55...6e-5. For some reason, the CDS parses this
scientific notation as "0.000056/0.", which it then interprets as being
equal 7.5 arcmin (the VO results returned in your script are truncated at
the 50 closest entries). The same incorrect results are returned via the
web interface with either "5.5555556e-5" or "0.000056/0.", with units of
degrees.
Now, whether Astropy is sending queries to the CDS in an unsupported format
(with the CDS handling this very strangely), or instead this being a bug
with the parser at the CDS, I don't know.
Daniel
On 16 January 2017 at 21:20, Francisco Gallardo lópez <
f.gallardo.lopez at gmail.com> wrote:
> 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 <(651)%20514-5412>
> 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
>>
>>
>
> _______________________________________________
> 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/4f2fa15f/attachment.html>
More information about the AstroPy
mailing list