Is there a way one can query on multiple positions (i.e., pairs of [ra,dec] coordinates) using a TAP query? For example, say I’ve got a list of 10,000 sources whose [ra,dec] I know (and they’re scattered all over the sky, so often many degrees separated from one another), how would I get, say, their g-band fluxes from dp02_dc2_catalogs.Object?
While I know you can use WHERE…IN… if you have a list of objectIds (as described here), but often you don’t know the objectIds before you’ve first done some initial query. I’d like my initial query to be on that list of 10,000 [ra,dec] pairs.
I can’t see how a WHERE…IN… would work for coordinates, since how would ADQL know to take each coordinate pairwise (nor what would go between WHERE and IN). But maybe that’s just my lack of experience with SQL/ADQL.
A brute-force approach would be to stick the query in a for loop, and just loop over those [ra,dec] pairs, but that seems inelegant and an inefficient use of ADQL. Another possibility would be to be able to create a user table, which I guess could somehow be JOINed with, say, dp02_dc2_catalogs.Object (I don’t know how I’d do this with a pair of columns [ra,dec] but, again, that’s as likely to be my lack of knowledge of SQL/ADQL as anything else).
Update: I found this in the ADQL document, which describes how one can perform a positional crossmatch between two different tables.
This is what I was referring to by my second suggestion (i.e., JOINing a table with dp02_dc2_catalogs.Object), so it is possible within the ADQL framework. However, it still requires me to be able to upload my own table and make it available to the TAP service on the RSP. Can this be done?
The capability for users to temporarily upload tables into the TAP service and join them against available tables is something we will provide in the future, but unfortunately it has not yet been implemented for DP0.2. For DP0.3, a similar capability exists (see the tutorial at 05. Using user-supplied catalogs in in DP0.3 (beginner) — Rubin Observatory DP0.3), but this method will not work for DP0.2, as those data are backed by a different type of database.
For now I think your best bet is to do the loop over coordinates as you suggested, but there will be better options in the long run!