|
Smithsonian Astrophysical Observatory |
SDSS @ CFA |
|
Contents: | Introduction | ||
| Photometric Data | |||
| Spectral Data | |||
| Spectral Line Data | |||
| Tools & Examples | getobjid | - get thumbnail or finder image | |
| getspecid | - get spectra from local archive | ||
| footserver | - Check if coordinate in SDSS footprint | ||
| sdssquery | - query Sloan SkyServer from CFA |
The majority of the "best" photometric database (not including the image thumbnails) and all of the spectral databases (as reduced at Princeton by David Spergel et al.) have been so condensed. The files locally are stored in the directory:
To ensure you get the latest version of the Starbase programs and the tools described below, please set your PATH variable to include the following two directories at its beginning:
/data/oiropt/starbase /data/oiropt/bin
There are 218,098,488 rows in the database, out of over 354,000,000 in the full PhotObjAll set. Using the search program from the Starbase package (see http://www.cfa.harvard.edu/~john/starbase/starbase.html) makes obtaining region-delimited objects quick even for this size database of about 196 GB.
The selected columns are:
objID fieldID specObjID
skyVersion rerun run camcol field obj flags flags2 type status ra dec probPSF u g r i z Err_u Err_g Err_r Err_i Err_z type_u type_g type_r type_i type_z flags_u flags_g flags_r flags_i flags_z flags2_u flags2_g flags2_r flags2_i flags2_z psfMag_u psfMag_g psfMag_r psfMag_i psfMag_z psfMagErr_u psfMagErr_g psfMagErr_r
psfMagErr_i psfMagErr_z psfMag_u_g psfMag_g_r psfMag_r_i psfMag_i_z fiberMag_u fiberMags_g fiberMag_r fiberMag_i fiberMag_z fiberMagErr_u fiberMagErr_g fiberMagErr_r
fiberMagErr_i fiberMagErr_z
fiberMag_u_g fiberMag_g_r fiberMag_r_i fiberMag_i_z petroMag_u petroMag_g petroMag_r petroMag_i petroMag_z petroMagErr_u petroMagErr_g petroMagErr_r
petroMagErr_i petroMagErr_z
petroMag_u_g petroMag_g_r petroMag_r_i petroMag_i_z extinction_u extinction_g extinction_r extinction_i
extinction_z sky_u sky_g sky_r sky_i sky_z skyErr_u skyErr_g skyErr_r skyErr_i skyErr_z isoA_u isoA_g isoA_r isoA_i isoA_z isoAErr_u isoAErr_g isoAErr_r isoAErr_i isoAErr_z isoB_u isoB_g isoB_r isoB_i isoB_z isoBErr_u isoBErr_g isoBErr_r isoBErr_i isoBErr_z isoPhi_u isoPhi_g isoPhi_r isoPhi_i isoPhi_z isoPhiErr_u isoPhiErr_g isoPhiErr_r
isoPhiErr_i isoPhiErr_z
To see this for yourself, use the Starbase progran headline and execute:
headline </data/astrocat/SDSS-dr6/PhotoPrim.db
Full documentation on these columns is available at: http://cas.sdss.org/dr6/en/help/browser/browser.asp?n=PhotoPrimary&t=U
Note that the u, g, r, i, z magnitudes are the modelMag magnitudes from the SDSS view, and to get the dereddened magnitude, you need to subtract the corresponding extinction_ value. The petroMag_x magnitudes are recommended for use with galaxies and the psfMag_x magnitudes are recommended for stars.
Also, note that the colors, e.g. petroMag_u_g, are not in the original table view from Sloan, but were computed including the extinction corrections, when extracting the values to put in this database, e.g.:
petroMag_u_g = (petroMag_u - extinction_u) - (petroMag_g - extinction_g)
These columns have been indexed for use by search, where all but the
ra & dec are secondary indices:
ra dec type specObjID objID petroMag_u petroMag_g petroMag_r petroMag_i petroMag_z petroMag_u_g petroMag_g_r petroMag_r_i petroMag_i_z psfMag_u psfMag_g psfMag_r psfMag_i psfMag_z psfMag_u_g psfMag_g_r psfMag_r_i psfMag_i_z
The primary index being on RA and Dec means the database file itself is sorted by RA and Dec. In this case the sorting is optimized into into bins of 0.1 degrees in Dec and by RA within each Dec bin, so that nearby objects are likely to be in the same disk block or at least nearby. Each secondary index consists of a sorted file of pointers to the indexed column. The search program uses these indices, if available, for fast access. See also the section below Searching the database.
For example, if the type field is 3,
the object is (supposed to be) a galaxy, type == 6
is a star and
type == 8 is a sky exposure.
The full type table, reproduced from the SDSS web site:
Also, each object has associated flag bits from the reduction stage
to allow selection or rejection on various citeria. These are 64-bit
quantities in the original SDSS database. Since Starbase is an awk
front end, it cannot handle these as numbers, so I have split them into
two 32-bit fields, calling the lower-order one flags and the high
order one flags2. Then, one or more bits can be tested using the
bit-field testing functions, and(), or(), not(), and xor().
Class Name Code Unknown UNK 0 Cosmic Ray CR 1 Defect DEFECT 2 Galaxy GALAXY 3 Ghost GHOST 4 Known object KNOWNOBJ 5 Star STAR 6 Star trail TRAIL 7 Sky SKY 8
For example, the 0x4 bit signifies an object too close to the edge of the frame, the 0x40000 bit means the object has one or more saturated pixels, while the 0x400000 bit means the sky level was bad. To test and reject objects with any of these conditions, the following pipeline fragment can be used:
[...input... ] | row 'and(flags, 0x440004) == 0' | [...output...]Since the 'stationary' bit is 0x1000000000, it is in the upper 32 bits, so the bit-field and test would be
and(flags2,0x10) == 0x10and has to be tested separately from the bits in flags.
The full set of 64 flag bits is documented at the cas.sdss.org site.
http://www.cfa.harvard.edu/~john/starbase/starbase.htmlBriefly, search uses index files, if available, to quickly seek to matching rows in the database, while row is a front-end for the awk variant mawk, for statements where the column names substitute for $1, $2, etc., so the user does not have to know the column order of the database.
To find all the objects with photometry near one or more coordinates, a small Starbase tab-separated table containing the RA and Dec is used containing the center(s) of the space to be searched. The example below is for one coordinate, but more are possible (the SDSS coordinates are all in degrees).
There are multiple ways to create a Starbase table. Two examples:
echo "190. 50." | fldtotable ra dec >/tmp/tableBoth of these result in a table that looks like:
printf "ra\tdec\n-\t-\n190.\t50.\n" >/tmp/table
ra dec -- --- 190. 50.where the whitespace between the columns is a single tab character. Then, using this table /tmp/table, the command to search around the coordinate with a radius of 0.05 degrees is:
search PhotoPrim.db -S2ddd ra dec 0.05 </tmp/tableNote that unless you are in the /data/astrocat/SDSS-dr6 subdirectory, you need to give the full path to PhotoPrim.db ; I am typing only the file name for clarity in this document.
A simple table cam be made on the fly, piping it directly into search:
printf "ra\tdec\n-\t-\n190.\t50.\n" | search PhotoPrim.db -S2ddd ra dec 0.05This returns a short table with 165 rows in just a fraction of a second. Searching linearly through the 196 GB would take approximately 8 hours, depending on the speed of your network link and machine.
To find all the objects with observed spectra near one or more coordinates, the output of a search such as the above is checked for rows where the column specObjID is non-zero. It happens that the 165 returned objects from the above search contains just a single object with a corresponding spectrum. It can be isolated using row on the above output:
printf "ra\tdec\n-\t-\n190.\t50.\n" | search PhotoPrim.db -S2ddd ra dec 0.05 | row 'specObjID != 0' | project specObjID[N.B.: the above is a single command broken across lines for readability]
specObjID - 359951516078964736
Using this result for a query of the SpecPhoto.db database, the command:
row <SpecPhoto.db 'specObjID == "359951516078964736"' | justify DR class subclass ra%.4f dec%.4f z z_err zwarningNote that the awk statement inside the row command is using a string comparison, not a numeric one. The specObjID and objID columns are 64-bit numbers which are too big for starbase's underlying implementation of awk.
The command returns (where justify projects and formats a subset of the columns to display):
DR class subclass ra dec z z_err zwarning --- ------ ----------- -------- ------- -------- -------- -------- DR3 GALAXY STARFORMING 189.9365 50.0143 0.083877 0.000009 0Note that the two databases may have slightly different values of RA and Dec for the object. In the above case, for example, the positions differ radially by 0.076 arc-seconds.
To print the RA and Dec in the conventional sexagismal format instead of degrees, use the Starbase compute command as a filter to convert the RA to hours (i.e., divide by 15), then use the "@" format specifier with justify on the ra and dec columns (and see the column name change at the end):
row <SpecPhoto.db 'specObjID == "359951516078964736"' | compute 'ra /= 15.' | justify DR progName class subclass ra%.1@ dec%@ z%.4f z_err%.4f zwarning=zwarnand the output is:
DR class subclass ra dec z z_err zwarn --- ------ ----------- ---------- -------- ----- ----- ----- DR3 GALAXY STARFORMING 12:39:44.6 50:00:51 0.084 0.000 0
for example, the command
getobjid -d $HOME -h 200 -w 400 -e GL -q 'GA(15,18)'
-b 1. -f sdss.jpg -v -o 587731511532060708
(line broken into two or clarity) delivers
this image whose
objid = 587731511532060708, where there is a
label, a grid marking the center, and triangles marking galaxies with
magnitudes between 15 and 18 in any of its bands.
For those interested in the details, see the documentation on the getobjid tool, below, and the full set of options is documented at the SDSS help page: http://cas.sdss.org/dr6/en/tools/chart/chart.asp
The spectral reductions are from the Princeton/Sloan database, who redid the Sloan reductions. The Princeton info page is:
http://spectro.princeton.eduThere are 734,864 rows in the SpecPhoto.db table and 1,059,840 in the full set in SpecObjAll.db. These numbers from the Princeton data set are slightly different from those given by the Sloan server. The CFA database files are 279 MB and 395 MB, respectively.
The subset of columns is the same in both databases:
specObjID objID DR progName ra dec primTarget secTarget specPrimary plate mjd fiberID plqual plsn2 class subclass objType waveMin waveMax wcoverage z z_err zwarning RChi2 RChi2Diff vdisp vdisp_err vdispChi2 vdispZ vdispZ_err firstRA firstDec firstWarning firstFInt firstFPeak firstRMS firstMaj firstMin firstFPA firstSkyRMS firstMatchDist firstNmatch tmassRa tmassDec firstErrMaj tmassErrMin tmassErrAng tmassJ tmassJIvar tmassH tmassHIvar tmassK tmassKIvar tmassPhQual tmassRdFlg tmassBlflg tmassCcFlg tmassGalContam tmassMpflg tmassJdate tmassDupSrc tmassMatchDist tmassNmatch usnoRA usnoDec usnoRmag usnoBmag usnoMatchDist unnoNmatch
The DR column gives which data release this row is from, i.e., one of: DR0, DR1, DR2, DR3, DR4, DR5 or DR6 (where I have renamed EDR to DR0).
Full information on the meaning of these columns is found at:
http://spectro.princeton.edu/#dm_spplateSee also their information on known problems. More information is also available from the SDSS web site:
http://cas.sdss.org/dr6/en/help/browser/browser.asp?n=SpecObj&t=U
http://www.cfa.harvard.edu/~john/starbase/starbase.htmlBriefly, row is a front-end for awk statements where the column names substitute for $1, $2, etc., so the user does not have to know the column order of the database. The command to pull all primary observations from the SpecObjAll.db table is:
row 'specPrimary == 1 && primTarget != 0 && secTarget == 0' <SpecObjAll.dbNote that this does not eliminate the duplications among the data releases, so it is still somewhat larger than the SpecPhoto.db dataset.
To find all the objects with spectra near one or more coordinates, a small Starbase tab-separated table containing the RA and Dec is used containing the center(s) of the space to be searched. [see the discussion above] The example below is for one coordinate, but more are possible (the SDSS coordinates are all in degrees):
printf "ra\tdec\n-\t-\n190.\t50.\n" | [this makes the table] search SpecObjAll.db -S2ddd ra dec 0.05 | [this performs the search] justify ra%4f dec%4f class subclass z z_err objID [project & format output]It happens that the search returns a single object, a starforming galaxy at Z = 0.08. The output from above is:
ra dec class subclass z z_err objID -------- ------- ------ ----------- ----- ----- ------------------ 189.9365 50.0143 GALAXY STARFORMING 0.084 0.000 587735430151929950And, since the objID is non-zero, that means it is in the photometric database PhotoPrim.db also. To access that data row, you could row the entire database, testing for the correct objID, but that would take hours. So, use search again, and scan the much smaller output of the search:
printf "ra\tdec\n-\t-\n190.\t50.\n" | [this makes the table] search PhotoPrim.db -S2ddd ra dec 0.05 | [this performs the search] row 'objID == "587735430151929950"' | [select the object] justify ra%.4f dec%.4f r Err_r%.3f i Err_i%.3f isoA_r isoB_r isoPhi_rreturns:
ra dec r Err_r i Err_i isoA_r isoB_r isoPhi_r -------- ------- ------ ----- ------ ----- ------ ------ -------- 189.9365 50.0143 17.272 0.007 16.996 0.008 21.982 17.175 170.37The search returns 165 rows in less than a second, so the row command has a far smaller table to check.
Actually, since the objID column is a secondary index, the PhotoPrim database should be directly searched:
search PhotoPrim.db -V objID 587735430151929950 | justify ra%.4f dec%.4f r Err_r%.3f i Err_i%.3f isoA_r isoB_r isoPhi_rand the output is the same as before.
For example, if the search in the SpecPhoto database is:
printf "233.45. 54.75." | fldtotable ra dec | search SpecPhoto.db -S2ddd ra dec 0.075 | justify specObjID objID ra%.4f dec%.4f class z z_errthen the output is:
specObjID objID ra dec class z z_err ------------------ ----------------- -------- ------- ------ ------ -------- 173055145871933440 588007004725117130 233.4319 54.7478 GALAXY 0.1179 0.000042 173613531751514112 588007004725117173 233.5103 54.7107 GALAXY 0.1531 0.000035 173613531772485632 588007004725117186 233.5444 54.7246 GALAXY 0.1173 0.000028This can be combined into a search on these objects in the PhotoPrim.db database, yielding columns from both. If a column name is duplicated between the two databases (other than the join field), the input database columns have "_1" appended to them and the searched database columns have "_2" appended. In the example below, "z" in SpecPhoto is the redshift, but "z" in PhotoPrim is a Z-filter magnitude. Other columns such as ra and dec also conflict.
This pipeline of commands:
printf "233.45. 54.75." | fldtotable ra dec |
search SpecPhoto.db -S2ddd ra dec 0.075 |
search -j PhotoPrim.db objID |
compute 'ra_2 /= 15. |
justify ra_2=ra%.1@ dec_2=dec%.0@ class petroMag_r petroMag_i \
petroMag_r_i z_1=z%.3f zwarning=zw
generates:
ra dec class petroMag_r petroMag_i petroMag_r_i z zw ---------- -------- ------ ---------- ---------- ------------ ----- -- 15:33:43.6 54:44:52 GALAXY 17.455 16.944 0.499152 0.118 0 15:34:02.3 54:42:38 GALAXY 17.294 16.852 0.430647 0.153 0 15:34:10.6 54:43:28 GALAXY 17.565 17.17 0.38362 0.117 0Note that the "z" from the input SpecPhoto.db table had been renamed to "z_1" because of the join conflict with "z" from PhotoPrim.db. The justify restored its original name and ignored the "z" magnitude from the PhotoPrim.db table, which became "z_2".
The getspecid program uses specObjID values from one of three sources: on the command line, input on standard input as a Starbase table, or input as a simple list on standard input.
For example, the search of SpecPhoto.db above yields three objects:
specObjID ------------------ 173055145871933440 173613531751514112 173613531772485632These can be extracted by piping this table into getspecid:
printf "233.45. 54.75." | fldtotable ra dec | search SpecPhoto.db -S2ddd ra dec 0.075 | getspecid -vwhich prints:
Extract fiber 1 to ./spPlate-0614-53437-001.fits Extract fiber 353 to ./spPlate-0616-52374-353.fits Extract fiber 358 to ./spPlate-0616-52374-358.fitswhile writing the files to the current directory. Without the "-v" option, it would silently write out the files. The FITS header is updated with the correct fiber RA and Dec, the source file name as "SPECFILE", the specObjID as "SPEC_ID" and the fiber ID as "FIBERID".
Sometimes it may be useful simply to extract the path to the file and fiber:
printf "233.45. 54.75." | fldtotable ra dec | search SpecPhoto.db -S2ddd ra dec 0.075 | getspecid -nwhich prints:
/data/astrocat/SDSS-dr6/Spectro/spectro_DR6/0614/spPlate-0614-53437.fits 1 /data/astrocat/SDSS-dr6/Spectro/spectro_DR2/0616/spPlate-0616-52374.fits 353 /data/astrocat/SDSS-dr6/Spectro/spectro_DR2/0616/spPlate-0616-52374.fits 358The following gives the details of the spectra storage hierachy. For those who want more details on the program, see the discussion and examples below.
To create the full path to one of the FITS files, use the DR, plate, mjd, and fiberID values. Using, for example, DR=="DR1", plate=="0649", mjd=="52201" and fiberid=="320", generates the full path which is
/data/astrocat/SDSS-dr6/Spectro/spectro_DR1/0649/spPlate-0649-52201.fitsTo actually get the spectrum for fiberID = 320 into its own file, one possibility is to use the imcopy command in IRAF, e.g. to get the 320th spectrum from one of these FITS files (see below for HDU explanation):
cl> imcopy file.fits[0][*,320] mydir/my.fits(where "file.fits" represents the actiual filename), or, using the funimage command from the FUNTOOLS package from a shell (single quotes prevent the shell from interpreting any characters as wildcards):
funimage file.fits'[0,*:*,320:320]' mydir/my.fitsThe Princeton web site also has instructions on using IDL and SuperMONGO.
In the Spectro subdirectory there is platelist.db, which lists all the plates from which release and MJD.
Each plate FITS file has 7 extensions, as documented at the Princeton web page.
HDU #0 = Flux in units of 10^(-17) erg/s/cm^2/Ang [FLOAT] HDU #1 = Inverse variance (1/sigma^2) for the above [FLOAT] HDU #2 = AND mask [32-bit INT] HDU #3 = OR mask [32-fit INT] HDU #4 = Wavelength dispersion in pixels [FLOAT] HDU #5 = Plug-map structure from plPlugMapM file [BINARY FITS TABLE] HDU #6 = Average sky flux in units of 10^(-17) erg/s/cm^2/Ang [FLOAT]Note that the spectra are in log-wavelength. To compute the wavelengths of each bin use the header values CRVAL1 and CD1_1. Below is an IDL code snippet contributed by Jenny Greene:
pix1=sxpar(header, 'CRVAL1', OOPS)
disp=sxpar(header, 'CD1_1', OOPS)
l=fltarr(n_elements(respec))
for k=0,n_elements(respec)-1 do begin
l[k]=disp*k+pix1
endfor
l=10^l
The Princeton info page is:
http://spectro.princeton.eduThe database table has 15,304,737 rows, or 21 different line observations for 728,797 spectra. The file size is 1.8 GB.
The columns are:
specObjID objID plateID mjd fiberID line wave z z_err sigma sigerr area area_err eqw eqw_err cont cont_err pix dof chi2
The entry in the line column is a short identifier for the 21 lines below:
line name LyA Ly alpha Ha H alpha Hb H beta Hg H gamma Hd H delta C3a C III] 1908 <--(sic) typo? C4 C IV 1549 He2 He II 1640 Mg2 Mg II 2799 N5 N V 1240 N2a [N II] 6548 N2b [N II] 6583 O1a [O I] 6300 O1b [O I] 6363 O2a [O II] 3725 O2b [O II] 3727 O3a [O III] 4363 O3b [O III] 4959 O3c [O III] 5007 S2a [S II] 6716 S2b [S II] 6730
If a line is missing or not measured, the z, etc. is 0 and the z_err, etc. is -1.
The specObjID and objID values are unique across all the SDSS databases, so these can be used to locate rows in the PhotoPrim.db and SpecPhoto.db tables as well.
To get the location of the actual spectrum corresponding to a row in the database, I've set up directories of the plates containing the multispec files. The plateID, mjd and fiberID values provide a path to the spectrum.
For example, if the plateID is "649", mjd is "52201" and fiberID = "320", the file is
/data/astrocat/SDSS-dr6/Spectro/spectro_DR1/0649/spPlate-0649-52201.fitsand spectrum 320 of that file is the target. See getspecid for a method of extracting the spectrum to your own directory.
Usage: getobjid [options] [objID_1 objID_2 ...] < table.db
If non-option args are present, they are taken as values for
images (i.e. RA, Dec pairs OR objIDs OR specObjIDs) to be
downloaded. The -l, -t flags are then ignored.
-c - input is ra, dec coordinates, degrees (default)
-o - input is objID
-s - input is specObjID
-h 400 - image height
-w 400 - image width
-b 0.396127 - image scale
-e GL - image opt
-q <str> - image query (Ex: "GR(15,20)")
-t <dbfile> - Take values from starbase file (STDIN is default)
-l <file> - Take values as simple list from file ("-" == STDIN)
-d . - Output directory
-f <name> - Output file name instead of default.
-a /data/astrocat/SDSS-dr6 - Path to SDSS data
-v - verbose output
Output: file(s) in directory "dirpath", with filename(s)
of form: SDSSJHHMMSS.ss[pm]DDMMSS.s.jpg
getobjid -h 200 -w 400 -f sdss.jpg -o 587731511532060708
generated the above image, while the command:
getobjid -q 'GA(15,18)' -h 200 -w 400 -e GL -b 1. -f sdss.jpg -vo 587731511532060708
generated the second image of the same coordinate, but where the GA(15,18) draws triangles around galaxies with any magnitude between 15 and 18, GL puts the grid and label on the image, and -b 1. enlarges the image scale (i.e. zooms out) from its default.
Usage: getspecid [options] [specID_1 specID_2 ...]
If non-option args are present, they are taken as specObjIDs
to be decoded. The -t, -l, -c, and -a flags are then ignored.
Options:
-t - Take specObjID's from STDIN as starbase table (default)
-l - Take specObjID's as simple list from STDIN, one per line
-d . - set output directory path
-f <id> - use fiberID=<id>
-m <mj> - use mjd=<mj>
-n - Print source file path+name, fiberid only
-s - Print source file name, fiberid only
-p <pl> - use plate=<pl>
-c specObjID - Column name to use from starbase table
-o <name> - Output file name instead of default.
-a /data/astrocat/SDSS-dr6/Spectro - Path to SDSS data
-v - verbose output
-x - Print this message and exit.
Output is file in directory "dirpath", which is "." by default.
File name is of form: spPlate-<plate>-<mjd>-<fiberID>.fits
To gather candidate Hypervelocity Stars for his project, Warren Brown (see Brown et al.) searched the SDSS catalog for late B-type objects. An approximate replication of the search would be the following script ( see explanatory notes):
#! /data/oiropt/bin/ksh
echo 18.25 |
fldtotable psfMag_g |
search /data/astrocat/SDSS-dr6/PhotoPrim.db -C1 psfMag_g 1.25 |
row 'type == 6 &&
and(flags2, 0x03000810U) == 0x10U && and(flags,0x80441044U) == 0' |
row 'psfMag_g_r > -0.38 && psfMag_g_r < -0.28' |
row ' (2.67 * psfMag_g_r) + 1.30 < psfMag_u_g &&
psfMag_u_g < (2.67 * psfMag_g_r) + 2.0' |
row ' -0.5 < psfMag_r_i && psfMag_r_i < 0.0 &&
17.0 < psfMag_g && psfMag_g < 19.5' |
column -a l b |
compute '[ l, b ] = eqgal(ra/15.,dec); if(b > 180.) b = (b % 180)-180' |
row 'abs(b) > -l/5. + 50 || abs(b) < l/5. - 50.'
generates hvstars.db with 563 rows. That table can be piped straight into getspecid to pull out all the objects with observed spectra:hvsearch >hvstars.db
for a total of 39 spectra, of which only 2 do not appear to be late B-type stars.getspecid -v <hvstars.db Extract fiber 304 to ./spPlate-0339-51692-304.fits Extract fiber 261 to ./spPlate-0332-52367-261.fits Extract fiber 175 to ./spPlate-0372-52173-175.fits ... Extract fiber 373 to ./spPlate-0543-52017-373.fits Extract fiber 358 to ./spPlate-0439-51877-358.fits Extract fiber 533 to ./spPlate-0497-51989-533.fits
A test run of this script took about 3 hours 52 minutes on the tdc computer, of which all but 7 minutes was the initial search with the condition 17.0 < psfMag_g > 19.5, which passed 6.8 million rows on to the pipeline of row statements.
flags2 & 0x03000810U == 0x10U (i.e. stationary only)
0x02000000U MAYBE_EGHOST
0x01000000U MAYBE_CR
0x00000800U SATUR_CENTER
0x00000010U STATIONARY
flags & 0x80441044U == 0
0x80000000U MOVED
0x00400000U BADSKY
0x00040000U SATURATED
0x00001000U COSMIC_RAY
0x00000040U NODEBLEND
0x00000004U EDGE
footserver [options] [ra1 dec1 ra2 dec2 ...]
-f - input file of coords, one ra,dec per line ('-' for stdin)
-d - force decimal output
-s - force sexagismal output
-v - verbose: see wget output (for debugging)
-h - print this usage message and quit
The input can be on the command line or the standard input or from a file,
using the -f filename option.
The coordinates must be either comma-separated or whitespace separated. The
coordinates can be in sexagismal format (RA hours, Dec degrees) or both in
floating point degrees. If any one of the input coordinates is in sexagismal
format, the output will be entirely so unless the -d option is
supplied. The option -s forces the output to be degrees regardless
of the input format.
footserver 12:04:22 10:12:33 16:38:12.2 -1:20:00outputs
ra dec run rerun camcol field
----------- ---------- ---- ----- ------ -----
12:04:22.08 10:12:33.0 3525 40 4 174
16:38:12.12 -1:20:00.0 0 0 0 0
and the zeroes in the run, etc. fields denote that the
object is not in the Sloan coverage.
138.719 +29.3497
138.888 +29.4622
138.901 +29.3232
Running the command:
footserver -d -f query
gernerates the output:
ra dec run rerun camcol field
---------- -------- ---- ----- ------ -----
138.719000 29.34970 4518 40 6 81
138.719000 29.34970 3900 41 2 114
138.888000 29.46220 3900 41 2 115
138.901000 29.32320 4518 40 6 82
138.901000 29.32320 3900 41 2 115
Without the -d option, the output would be:
ra dec run rerun camcol field
---------- ---------- ---- ----- ------ -----
9:14:52.55 29:20:58.9 4518 40 6 81
9:14:52.55 29:20:58.9 3900 41 2 114
9:15:33.12 29:27:43.9 3900 41 2 115
9:15:36.25 29:19:23.5 4518 40 6 82
9:15:36.25 29:19:23.5 3900 41 2 115
ok> echo 18:03:10 -10:55:00 | ~/progs/Sloan/footserver -d -f -
ra dec run rerun camcol field
---------- --------- --- ----- ------ -----
270.791667 -10.91667 0 0 0 0
The Skyserver has row and time limits on this kind of Web query. Currently a query taking longer than 10 minutes will be aborted, as will one returning more than 100,000 rows. Also, no more than 60 queries per minute are permitted from any one computer.
sdssquery '
select ra, dec, type, psfMag_r, psfMag_i
from PhotoPrimary
where type = 6 and
objID between 587727177912614921 and 587727177912614940
' |
justify
which produces:
ra dec type psfMag_r psfMag_i
------------- ------------ ---- --------- ---------
4.10721167E-3 -11.20992605 6 16.671963 16.471029
6.99093652E-3 -11.09600821 6 10.826494 14.766943
0.01242457 -11.09817569 6 23.750692 22.300419
Note that when the SQL query has shell wildcard characters, it will have
to be quoted or the characters individually escaped.
If the file 'query' has the following contents:
select ra, dec, type, petroMag_r, petroMag_i
from PhotoPrimary
where type = dbo.fPhotoType("GALAXY") and
objID between 587727177912614921 and 587727177912614940
then the command:
sdssquery query | justifywill print:
ra dec type petroMag_r petroMag_i
--------------- ------------ ---- ---------- ----------
2.19374561E-3 -11.21108779 3 21.808626 21.082067
359.99718839 -11.09709042 3 19.723789 19.228863
2.48314006E-4 -11.10074393 3 21.412432 20.003176
0.01382232 -11.09129188 3 28.062342 19.627892
359.99900278 -11.09956301 3 24.264151 20.487772
7.35112938E-3 -11.10532238 3 21.843147 21.612478
0.01313465 -11.09560537 3 21.185026 21.257969
4.74492335E-3 -11.10250524 3 22.213799 21.227732
5.17074845E-3 -11.10311999 3 23.016922 20.577419
359.9997454 -11.09724859 3 21.910898 20.741583
0.01066068 -11.10371495 3 23.119787 20.838671
0.01215572 -11.10134416 3 21.81654 20.78879
0.01505928 -11.09949988 3 24.35099 23.41531
4.43446229E-4 -11.09211681 3 27.203613 20.465734
3.96360601E-3 -11.08906882 3 25.067053 24.315235
Note that only the first query in a file is processed.
>> sqlcl << command line query tool by Tamas Budavari
-
Usage: sqlcl [options] sqlfile(s)
Options:
-s url : URL with the ASP interface (default: pha)
-f fmt : set output format (html xml csv - default: csv)
-q query : specify query on the command line
-l : skip first line of output with column names
-v : verbose mode dumps settings in header
-h : show this message
Note that sdssquery assumes the -q option
if the argument on the command line is not a file.