search

NASA-NAVO / navo-workshop

Tutorial notebooks for how to use PyVO to access NASA and other data in Python.
https://NASA-NAVO.github.io/navo-workshop
BSD 3-Clause "New" or "Revised" License
41 stars 26 forks source link

BUG: use `radius` rather than `diameter` in query examples #159

Open mstalbot opened 7 months ago

mstalbot commented 7 months ago

The 'diameter=Angle(cone_search_radius * 2 * u.arcsec)' will lead to a crash in code below, which appears related that the passed **kwargs may not be used in service I am reaching out too.

import pyvo as vo
from astropy.coordinates import SkyCoord
import numpy as np
from astropy.coordinates import Angle
from astropy import units as u

cone_search_services = vo.regsearch(servicetype='conesearch')
service = cone_search_services[458] 
cone_search_radius = 3
coordinates = SkyCoord(233.319218, 48.119651, unit="deg")
table = service.search(pos=coordinates, diameter=Angle(cone_search_radius * 2 * u.arcsec)).to_table()

edit by bsipocz: some reformatting

Second scenario, using diameter=2*cone_search_radius/3600 has no spacial cut effect, a full search is run and results outside of the cone are returned

bsipocz commented 7 months ago

The triage of this issue: we use diameter rather than radius in some of the examples, and under the hood it's neither been sent through sanity check (thus this scalar error for the Angle example above), nor necessarily been used upstream (thus the return of the max number of results without doing a spatial cut in the case of passing a float rather than an Angle).

mstalbot commented 7 months ago

I did some further tests, and it looks like, and only considering using Angle formatted input, that 'radius' works for NED/table searches, 'size' for image searches, and 'diameter' for spectra searches. Otherwise, weird stuff happens when either Angle formatted is not used, or these preferences are swapped. I'll open a second git issue for this.