Look at possibilities to vectorize queries

[bsipocz]

It would be nice to look at the possibilities of querying multiple objects at the same time, as doing it sequentially one-by-one has huge overheads when one has thousands of objects. When a module supports it check it out; or if isn't possible due to the remote API, cross it over.

• astroquery/alfalfa
• astroquery/alma
• astroquery/astrometry_net
• astroquery/atomic
• astroquery/besancon
• astroquery/cadc
• astroquery/casda
• astroquery/cds
• astroquery/cosmosim
• astroquery/dace
• astroquery/esa/hsa
• astroquery/esa/hubble
• astroquery/esa/iso
• astroquery/esa/jwst
• astroquery/esa/xmm_newton
• astroquery/esasky
• astroquery/eso
• astroquery/exoplanet_orbit_database
• astroquery/fermi
• astroquery/gaia
• astroquery/gama
• astroquery/gemini
• astroquery/heasarc
• astroquery/hips2fits
• astroquery/hitran
• astroquery/image_cutouts/first
• astroquery/imcce
• astroquery/ipac/irsa
• astroquery/ipac/irsa/ibe
• astroquery/ipac/irsa/irsa_dust
• astroquery/ipac/irsa/sha
• astroquery/ipac/ned
• astroquery/ipac/nexsci/nasa_exoplanet_archive
• astroquery/jplhorizons
• astroquery/jplsbdb
• astroquery/jplspec
• astroquery/lamda
• astroquery/linelists/cdms
• astroquery/magpis
• astroquery/mast
• astroquery/mpc
• astroquery/nasa_ads
• astroquery/nist
• astroquery/nvas
• astroquery/oac
• astroquery/ogle
• astroquery/open_exoplanet_catalogue
• astroquery/sdss
• astroquery/sha
• astroquery/simbad
• astroquery/skyview
• astroquery/solarsystem/neodys
• astroquery/solarsystem/pds
• astroquery/splatalogue
• astroquery/svo_fps
• astroquery/ukidss
• astroquery/utils
• astroquery/utils/tap
• astroquery/vamdc
• astroquery/vizier
• astroquery/vo_conesearch
• astroquery/vsa
• astroquery/wfau
• astroquery/xmatch

[jwoillez]

Vizier already supports this. You can even use the output of a first query as the input of another query. We have example somewhere in the documentation.

-Julien

On Apr 26, 2016, at 17:51, Brigitta Sipocz notifications@github.com wrote:

It would be nice to look at the possibilities of querying multiple objects at the same time, as doing it sequentially one-by-one has huge overheads when one has thousands of objects. When a module supports it check it out; or if isn't possible due to the remote API, cross it over. This is inspired by a conversiation on the python in astronomy facebook group [0].

alfalfa
alma
atomic
besancon
cosmosim
data
eso
extern
fermi
gama
heasarc
ibe
irsa
irsa_dust
lamda
lcogt
magpis
nasa_ads
ned
nist
nrao
nvas
ogle
open_exoplanet_catalogue
sdss
sha
simbad
skyview
splatalogue
template_module
tests
ukidss
utils
vizier
xmatch
[0] - https://www.facebook.com/groups/astropython/permalink/1729453593965990/#

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[bsipocz]

@jwoillez - Brilliant, thanks.

[eteq]

the IRSA dust service (which is what the fb post was about) supports a table upload. It's a completely different web API, but I don't see any reason why we couldn't just have that be transparent to the user... Will create an issue for that.

[bsipocz]

@keflavich - I've run into this one yet again, seeing a looping through coordinates before running a query in a user notebook. It would be nice to go through all the modules and make sure they work with vectorized SkyCoord inputs, and adding such a vector query to the test suite.
If the remote API doesn't support vector query, then ideally we should do the looping in the astroquery code, so the user facing API stays the same, and work with both scalar and vector inputs.

[bsipocz]

cc @nkphysics - If you're still looking for things to work on, this would be another of those issues that are very modular, and a long-term pain point.

[nkphysics]

cc @nkphysics - If you're still looking for things to work on, this would be another of those issues that are very modular, and a long-term pain point.

I can certainly take a look into this.