B.27.2 Examples

Here are some examples of tapskymatch:

stilts tapskymatch tapurl=http://dc.g-vo.org/tap
                   taptable=twomass.data taplon=raj2000 taplat=dej2000
                   in=dr5qso.fits inlon=RA inlat=DEC sr=0.00027 find=all
                   out=qso_2mass.fits

Matches a local catalogue dr5qso.fits against the table named twomass.data in the GAVO TAP service. The search radius is 1/3600 degrees (1 arcsecond) and all 2MASS sources within the radius of each input source are returned.

If you run the command with "stilts -verbose ..." the text of the ADQL query submitted to the TAP service will (amongst other things) be logged on the console, and you will also see the number of rows uploaded and matched in each chunk.

stilts tapskymatch tapurl=http://dc.g-vo.org/tap
                   taptable=rave.dr3 taplon=raj2000 taplat=dej2000
                   tapcols=name,raj2000,dej2000,pmra,pmde
                   in=hip_main.fits inlon=RAdeg inlat=DEdeg
                   icmd='keepcols "HIP RAdeg DEdeg pmra pmde"'
                   sr=0.00027
                   icmd='select nearMoc(\"III/265/ravedr3\",RAdeg,DEdeg,.00027)'
                   icmd=cache icmd=progress
                   blocksize=5000
                   fixcols=all suffixin=_hip suffixremote=_rave
                   find=best
                   omode=topcat

This matches a local copy of the Hipparcos survey against a remote copy of the RAVE survey with a 1-arcsecond radius. The output table contains only the identifier, position and proper motion columns from both the input table (by using the keepcols filter) and the remote table (by specifying tapcols); the other columns are discarded. The fixcols and suffix* parameters ensure that a suffix is added to all the output column names, _hip for the input (Hipparcos) columns and _rave for the remote (RAVE) ones.

Before uploading, the input table is preprocessed by selecting only those rows that fall within the actual footprint of the RAVE survey, by filtering with a MOC giving RAVE coverage (the RAVE dr3 MOC is also available at this URL). This step reduces the amount of data that needs to be uploaded, since only those rows in the given coverage region stand a chance of having a match in the remote table. Note use of the nearMoc function with the value of the match radius as the fourth parameter; this includes those objects which may be outside the actual MOC region but close enough that a match could still result.

The blocksize parameter determines the number of rows uploaded at a time. If you receive warnings that the output has been truncated, you should decrease this number.

Progress is displayed as the match continues. The cache filter must be applied upstream of (before) the progress filter itself for this to work, since otherwise the match processing reads all the input rows before the actual work is done, and the progress monitor completes before the match actually starts.