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
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
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.