SQLxMatch: In-Database Spatial Cross-Match of Astronomical Catalogs

DOI

SQLxMatch (or sequel cross match) is a SQL stored procedure that allows to perform 2-dimensional spatial cross-matches and cone searches across multiple astronomical catalogs stored in relational databases.

We have integrated SQLxMatch with more than 50 astronomical catalogs, and made those publicly available as tables in remote SQL Server databases through the CasJobs website, as part of the SciServer science platform ([1]). In CasJobs, users can directly execute form-free SQL queries for cross-matching, either synchronously or as asynchronous jobs. For general audiences, a simpler form-based interactive web interface that uses the CasJobs REST API for running cross-match queries will be soon available in the SkyServer astronomy portal. A stand-alone version of this web interface can accesed at https://skyserver.sdss.org/xmatch.

Documentation

Detailed documentation can be found HERE.


Demo

Here we will show how to run a cross-match between objects in the avaiable catalogs, including those in the Sloan Digital Sky Survey (SDSS).

In order to communicate and send queries to CasJobs, we need to import the CasJobs module from the SciServer python package. You will need to install this package if you are not running this notebook in SciServer-Compute.

Listing all catalogs

Here we run a SQL query to the Catalogs view that lists the names of all available catalogs. This query is run in the xmatch database context.

Listing tables in a catalog

The Tables view contains the tables available in all catalogs. We can use the WHERE clause to filter rows on the catalog_name column. Note that the table_name column is unique and written in the following format: <CatalogName>_<TableName>, and will be passed as parameter in the SQLxMatch stored procedure, as shown later.

Listing columns in a table

Given a table name, we can run this SQL query containing the getTableColumns function in order to get more information about its columns.
This helps identifying the RA and Dec columns, as well as possible column on which we could impose filters.


Cross-Match Examples

Quick cross-match of small catalogs - Pandas DataFrame output

As a quick example, here we cross-match two small infrared catalog tables: IRAS_PhotoObj and AKARI_FIS.

We can retrieve the cross-match output table as a Pandas dataframe by using the syncronous executeQuery function in CasJobs, as this cross-match takes less time than its 1 minute timeout.

The first input parameters are the names of 2 catalog tables, views, or temporary tables located in the CasJobs xmatch database context. This context already contains several table views from specific astronomical catalogs, and are named with the following format: <CatalogName>_<TableName>.

The input tables or views are expected to have at least one unique identifier column (e.g. objid, specobjid, etc), as well as an RA (Right Ascension) and Dec (Declination) columns.
However, the code will run faster if the input tables or views already contain the cx, cy, and cz columns (3-D cartesian coordinates of an object located on the surface of a unit-radius sphere).

The procedure returns by default a table as TABLE (id1, id2, sep), where id1 and id2 are the names of the columns that uniquely identify objects in the first and second catalogs, respectively, and sep is the angular separation between objetcs in arseconds.

Cross-matching two filtered catalogs - Pandas DataFrame output

Here we use two bigger tables (the PhotoObjAll tables in the BestDR18 and GalexDR6 catalogs), which we filter by ra and dec in rectangular regions and store in local temporary tables. These temporary tables are then passed as input to the SQLxMatch procedure.

Note that we can also store the (cx, cy, cz) columns in the temporary tables in order to avaoid having the code to compute them later internally on the fly.

Also, note that this time we also give @include_radec=1, @include_sep_rank=1, @sort_by_separation=1 as input parameters.

Cross-Match beween 2 catalogs as an asynchronous job - Output to MyDB

When the cross-match is expected to take longer than the 1 minute timeout, it is recommendable to run it as an asynchronous job store the cross-match results asynchronous job into a table in your own MyDB database.

First, one must create the output table in MyDB, or delete if this table was already created by previous runs of this demo.


The result of the sp_xmatch procedure can be stored in a local temporary table specified by the @output_table input parameter. This output table can be then used to fill the table in MyDB.


We can now inspect the contents of the MyDB output table: