<div dir="ltr"><div><div><div>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.<br><br></div>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.<br><br></div><div>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.<br><br></div><div>Daniel<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 January 2017 at 21:20, Francisco Gallardo lópez <span dir="ltr"><<a href="mailto:f.gallardo.lopez@gmail.com" target="_blank">f.gallardo.lopez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Daniel!<br><br></div><div>Thanks a lot for replying.<br></div><div><br></div>I'm afraid It seems like the attached file was not included (sorry!).<br><br></div><div>Thanks for raising the Cos(dec) term issue.<br><br></div>Nonetheless, the code of the example can be found below. As you can see the cone search is as follows: conesearch.conesearch(a,<u><b>0.2*u.<wbr>arcsec</b></u>,catalog_db=k)<br></div><div><div><br>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.<br><br></div><div>If the radius is not wrongly set (please refer to the conesearch, I think it is fine, according to the <a href="http://docs.astropy.org/en/stable/api/astropy.vo.client.conesearch.conesearch.html" target="_blank">documentation</a>), 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.<br><br></div><div>Please find below the example code. Do you see something not properly set?.<br></div><div>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)<br></div><span class=""><div><br><br></div><div>Thanks a lot!<br></div><div>BR<br></div><div>Fran<br></div><div> <br></div><div><br></div></span><div><br>==============<br><br><br>#!/usr/bin/python<br><br>import pdb<br>from astropy.vo.client import conesearch<br>from astropy.coordinates import ICRS<br>from astropy import units as u<br>from astropy.coordinates import SkyCoord<br><br>def main():<br>    ra=159.315075782<br>    dec=-27.<a href="tel:(651)%20514-5412" value="+16515145412" target="_blank">6515145412</a><br>    a=SkyCoord(ra=float(ra)*u.deg,<wbr>dec=float(dec)*u.deg,frame='<wbr>icrs')<br>    for k in conesearch.list_catalogs():<br>        try:<br>            temp=conesearch.conesearch(a,<font size="4"><b><span style="background-color:rgb(255,0,0)">0<wbr>.2*u.arcsec</span></b></font>,catalog_db=k)<br>            pdb.set_trace()<br>        except:<br>            print "Nothing found."<br><br><br><br>if __name__=="__main__":<br>    main()<br><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-01-16 21:18 GMT+01:00 Daniel Evans <span dir="ltr"><<a href="mailto:d.f.evans@keele.ac.uk" target="_blank">d.f.evans@keele.ac.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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?<br><br></div>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.<br><br></div><div>(If anything, it seems the USNO ought to be congratulated for seemingly being the only catalog providers to remember the cos(Dec) term!)<br></div><div><br></div>Regards,<br></div>Daniel<br></div><div class="m_-1627764605356768572HOEnZb"><div class="m_-1627764605356768572h5"><div class="gmail_extra"><br><div class="gmail_quote">On 16 January 2017 at 19:57, Francisco Gallardo lópez <span dir="ltr"><<a href="mailto:f.gallardo.lopez@gmail.com" target="_blank">f.gallardo.lopez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Evert!<br><br></div>Thanks a lot for answering.<br><div><div><br>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'.<br><br>I created a small code to show the thing (please find it attached to this email).<br><br>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.<br><br>For instance, with the second catalog (<i>'The USNO-A2.0 Catalogue (Monet+ 1998) 1')</i> and the sky position (ra=159<b><span style="background-color:rgb(255,0,0)"><span style="background-color:rgb(255,255,255)">.</span>31</span></b>5075782, dec=-27.<a href="tel:(651)%20514-5412" value="+16515145412" target="_blank">6515145412</a>):<br><div><br><br><Table masked=True length=49><br>    _r       USNO-A2.0    RAJ2000    DEJ2000   ...   Bmag    Rmag   Epoch  <br>   deg                      deg        deg     ...   mag     mag      yr   <br> float64       str13      float64    float64   ... float32 float32 float64 <br>---------- ------------- ---------- ---------- ... ------- ------- --------<br>  0.041089 0600-13508332 159.<span style="background-color:rgb(255,0,0)">26</span>9631 -27.643284 ...    19.3    17.9 1981.701<br>  0.039111 0600-13508442 159.271653 -27.644431 ...    20.2    17.9 1981.701<br>  0.038170 0600-13508467 159.272078 -27.654039 ...    20.6    17.5 1981.701<br>  0.039771 0600-13508743 159.277409 -27.629875 ...    19.8    17.9 1981.701<br>  0.031614 0600-13508894 159.280334 -27.644278 ...    19.8    17.9 1981.701<br>  0.037095 0600-13509081 159.283342 -27.675723 ...    16.1    15.6 1981.701<br>       ...           ...        ...        ... ...     ...     ...      ...<br>  0.040114 0600-13512624 159.<span style="background-color:rgb(255,0,0)">34</span>8720 -27.678370 ...    15.9    15.4 1981.701<br><br>==============================<wbr>===========================<br><br><br></div><div>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)<br><br></div><span><div>Thanks a lot!<br></div><div>BR<br></div><div>Fran<br></div></span><div><div class="m_-1627764605356768572m_-8707911817847227870h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-01-16 8:46 GMT+01:00 Evert Rol <span dir="ltr"><<a href="mailto:evert.rol@gmail.com" target="_blank">evert.rol@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Hi Francisco,<br>
<br>
Could you send a short working code example around that shows the actual problem?<br>
Possibly for both the GSC (ok) and the USNO catalogs (not ok).<br>
<br>
Evert<br>
<div><div class="m_-1627764605356768572m_-8707911817847227870m_-8305907124488652055gmail-h5"><br>
<br>
<br>
> Hi all!<br>
><br>
> I looked in the Internet but I did not find references to this problem, so maybe I'm making something wrong.<br>
><br>
> 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() ).<br>
><br>
> 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.<br>
><br>
> 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'.<br>
><br>
> Am I missing something or making something wrong or is it a known bug?<br>
><br>
> Thanks a lot!<br>
> BR<br>
> Fran Gallardo<br>
</div></div>> ______________________________<wbr>_________________<br>
> AstroPy mailing list<br>
> <a href="mailto:AstroPy@scipy.org" target="_blank">AstroPy@scipy.org</a><br>
> <a href="https://mail.scipy.org/mailman/listinfo/astropy" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman<wbr>/listinfo/astropy</a><br>
<br>
______________________________<wbr>_________________<br>
AstroPy mailing list<br>
<a href="mailto:AstroPy@scipy.org" target="_blank">AstroPy@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/astropy" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman<wbr>/listinfo/astropy</a><br>
</blockquote></div><br></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
AstroPy mailing list<br>
<a href="mailto:AstroPy@scipy.org" target="_blank">AstroPy@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/astropy" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman<wbr>/listinfo/astropy</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
AstroPy mailing list<br>
<a href="mailto:AstroPy@scipy.org" target="_blank">AstroPy@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/astropy" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman<wbr>/listinfo/astropy</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
AstroPy mailing list<br>
<a href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/astropy" rel="noreferrer" target="_blank">https://mail.scipy.org/<wbr>mailman/listinfo/astropy</a><br>
<br></blockquote></div><br></div>