[AstroPy] astropy.vo.client conesearch radius problem?

[Benjamin Weiner]

​Hi,

I can't speak about the inner workings of either the astropy VO search or
the catalog search parsers, but I have a couple of suggestions, the first
related to the science goal.

1. The astrometric accuracy of GSC is about 0.2-0.3 arcsec rms and the
astrometric accuracy of USNO-B is about 0.2 arcsec (not sure if rms;
numbers are from the catalog papers). In general, it's probably not useful
to use a matching radius less than 2-3 times the rms accuracy of the
catalog, unless you have a specialized application.

2. Doing an astrometric difference of coordinates at less than 1 arcsec or
so can underflow a single precision floating point number. So if somewhere
in this processing chain is single precision, it risks getting erroneous
results.

The actual problem here could be something as simple as the CDS parser, but
it would be useful to know if the error persists with a larger search
radius.

Ben




>
> Message: 1
> Date: Mon, 16 Jan 2017 22:07:48 +0000
> From: Daniel Evans <d.f.evans at keele.ac.uk>
> To: Astronomical Python mailing list <astropy at scipy.org>
> Subject: Re: [AstroPy] astropy.vo.client conesearch radius problem?
> Message-ID:
>         <CANnaQabS+eSWJjWS35f6d_X-zbKie-eyEA9+jT3kNxPtsTZA0Q@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> >
> >
>

-- 
Benjamin Weiner
Associate Astronomer, Steward Observatory
bjw at as.arizona.edu
http://mingus.as.arizona.edu/~bjw/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20170117/37ee3ecf/attachment.html>