DR2 Help
 Archive Intro
 Table Descriptions
 Schema Browser
 Glossary
 Algorithms
 Introduction to SQL
 Form Query User Guide
 Query Limits
 How To
 FAQ
 API
 sdssQA
 Download
 SkyServer Sites
 SkyServer Traffic Page
 Web Browsers
 Contact Help Desk
Archive Intro

Click here for any release note(s) that may apply to this release.

The Catalog Archive Server (CAS) provides access to the object catalogs and related data from the Sloan Digital Sky Survey (SDSS). It is a companion to the Data Archive Server (DAS), which allows users to download raw (FITS) images and spectra from the survey. The SkyServer provides the Web interface to the CAS.

Data Organization

The SDSS Catalog Data Model

The SDSS catalog data is stored in a commercial relational database management system (DBMS) - Microsoft's SQL Server. The data is therefore organized in several 2-dimensional tables. The tables and their relationships to each other are referred to as the schema in database jargon.

Diagrammatic view of the DR2 schema

There are 3 different types of data in the tables - imaging data is in the photo group of tables, spectroscopic and tiling data is in the spectro tables, and other data such as documentation or other information about the photo and spectro data, i.e. metadata, is in the meta tables. Some tables are also created specifically for speef or convenience, for example the SpecPhotoAll table, which contains a pre-computed join of relevant fields in the PhotoObjAll and SpecObjAll tables.

The important tables are described below, along with the views that are currently defined on each table. A view is a subset of the corresponding table that can be used instead of the table - in other words it is a virtual table. A view is usually faster than using the base table, since it only loads a subset of the objects, but more importantly, the views we have defined on the tables select only the objects that are important for science, and they filter out non-science objects such as sky, QA or defective observations. As such, even though we list the base tables for completeness below, in the vast majority of the cases, you should use the views defined on the tables instead of the tables themselves, e.g. use the PhotoObj and SpecObj views for science instead of the PhotoObjAll and SpecObjAll tables.

BESTDR2, TARGDR2 and other databases

There are two main datasets in the SDSS catalog archive server - the BEST and TARGET datasets that are contained in separate databases. Each contains different reprocessings of the same raw data:

  • the BEST dataset is contained in the BESTDR2 database, and represents the latest, greatest calibration of the raw data. BESTDR2 is the default database for queries. Other databases must be explicitly specified (see below for sample syntax).
  • The TARGET dataset is contained in the TARGDR2 database, and represents a snapshot of the data as it was when the target selection algorithm was run on it, i.e. it is the calibration upon which the spectroscopic targets were chosen.  Preserving this data version is important for doing science with the data.

Both databases have the identical schema (tables), but different data.  The BESTDR2 database also contains the spectroscopic and tiling data, whereas the TARGDR2 database only contains imaging data.  The vast majority of queries are run on the BESTDR2 database.

There are two other databases currently in the CAS - RC3 and Stetson. These contain photometry of objects from the RC3 and Stetson datasets that match SDSS objects. Each database contains a single table - the PhotoObj table in RC3, and the Stetson table in Stetson.

To choose a database other than the default BESTDR2 in your query, you must specify it as <dbname>..<tablename>, e.g., TARGDR2..PhotoObj, RC3..PhotoObj, Stetson..Stetson, etc. A quick way to get the fields in the RC3 and Stetson tables is to type:

	   SELECT TOP 1 * FROM RC3..PhotoObj  
	   SELECT TOP 1 * FROM Stetson..Stetson  
Please see the SQL Intro page for further help with SQL queries.

The Hierarchical Triangular Mesh (HTM)

We have build a spatial indexing scheme called the Hierarchical Triangular Mesh (HTM) that spatially decomposes the region of the sky that is covered by the SDSS data and enables much faster spatial searches of the data by coordinate cuts.

Database Indices

In addition to the HTM, which is an overall indexing scheme for multidimensional spatial data, the DBMS itself has the capability to define indices for fast searches on each table. We have defined indices on all the major tables.

An index is a tree representation of a subset of the columns in a table that enables much faster searches of the table (compared to sequential scans of the table data) when constraints involving those columns are included in the query. All tables have an index on their primary key (unique row identifier), but the larger tables have indexes in addition to the primary key index. In all there are 3 kinds of indices:

  • Primary Key Index - index on the unique primary key of a table.
  • Foreign Key Index - index on a foreignkey of a table, i.e. a column that is a primary key of another table.
  • Covering Index - an index that covers one or more columns of a table. This is a combined index on those fields, so it speeds up searches if any of those fields are included in the WHERE clause.
Click here to view a table of all the current indices defined on the data.

Imaging (Photo) Data Tables

The important tables and views are described below. For each table, the views and indices are defined on that table are described in brief. For more information, please see the Table Descriptions help page as well as the links to the Glossary entries that are incorporated in the table listing below.

  1. PhotoObjAll - By far the largest table in the database, PhotoObjAll contains the 100+ parameters for each imaging (photo) object. For most of these parameters, there are actually 5 rows each, one for each wavelength band. This table includes data on all photo objects, not just science objects, hence the name PhotoObjAll. The view of this table that includes only science objects and excludes sky and other unknown objects is the PhotoObj view. The PhotoObjAll table is there for completeness, but science queries are usually done on the PhotoObj view.
    PhotoObjAll Views:

    View NameContentsDescription
    PhotoFamily These are in PhotoObj, but neither PhotoPrimary or Photosecondary. These objects are generated if they are neither primary nor secondary survey objects but a composite object that has been deblended or the part of an object that has been deblended wrongfully (like the spiral arms of a galaxy). These objects are kept to track how the deblender is working. It inherits all members of the PhotoObj class.
    PhotoObj All primary and secondary objects in the PhotoObjAll table, which contains all the attributes of each photometric (image) object. It selects PhotoObj with mode=1 or 2.
    PhotoPrimary These objects are the primary survey objects. Each physical object on the sky has only one primary object associated with it. Upon subsequent observations secondary objects are generated. Since the survey stripes overlap, there will be secondary objects for over 10% of all primary objects, and in the southern stripes there will be a multitude of secondary objects for each primary (i.e. reobservations).

    They are defined by the status flag: (PRIMARY & OK_RUN) = 0x2010.

    PhotoSecondary Secondary objects are reobservations of the same primary object.

    PhotoObjAll Indices:

    Index TypeKey or Field List
    primary keyobjID
    foreign keyField(fieldID)
    covering indexmode, cy, cx, cz, htmID, type, flags, status, ra, dec, u, g, r, i, z, rho
    covering indexhtmID, cx, cy, cz, type, mode, flags, status, ra, dec, u, g, r, i, z, rho
    covering indexfield, run, rerun, camcol, type, mode, flags, rowc, colc, ra, dec, u, g, r, i, z
    covering indexfieldID, objID, ra, dec, r, type, status, flags
    covering indexSpecObjID, cx, cy, cz, mode, type, flags, status, ra, dec, u, g, r, i, z, rho
    covering indexcx, cy, cz, htmID, mode, type, flags, status, ra, dec, u, g, r, i, z, rho
    covering indexrun, mode, type, status, flags, u, g, r, i, z, Err_u, Err_g, Err_r, Err_i, Err_z
    covering indexrun, camcol, rerun, type, mode, status, flags, ra, dec, fieldID, field, u, g, r, i, z
    covering indexrun, camcol, field, mode, parentID, q_r, q_g, u_r, u_g, isoA_r, isoB_r, fiberMag_u, fiberMag_g, fiberMag_r, fiberMag_i, fiberMag_z

  2. PhotoTag - This is a vertical partition of the PhotoObjAll table, and contains only those columns that are most often requested. Due to the smaller size of each row in the table, many more rows can be loaded into the memory cache at one time, hence searches on the PhotoTag table are much faster than searches on PhotoObjAll. Whenever possible, use the PhotoTag table instead of PhotoObjAll or PhotoObj.
    PhotoTag Indices:

    Index TypeKey or Field List
    primary keyobjID
    foreign keyPhotoObjAll(objID)
    foreign keyField(fieldID)
    covering indexmode, cy, cx, cz, htmID, type, flags, status, ra, [dec], modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z, [size]
    covering indexhtmID, cx, cy, cz, type, mode, flags, status, ra, [dec], modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z, [size]
    covering indexfield, run, rerun, camcol, type, mode, flags, ra, [dec], modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z
    covering indexfieldID, objID, ra, [dec], modelMag_r, type, status, flags
    covering indexSpecObjID, cx, cy, cz, mode, type, flags, status, ra, [dec], modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z, [size]
    covering indexcx, cy, cz, htmID, mode, type, flags, status, ra, [dec], modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z, [size]
    covering indexrun, mode, type, status, flags, modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z, modelMagErr_u, modelMagErr_g, modelMagErr_r, modelMagErr_i, modelMagErr_z
    covering indexrun, camcol, field, rerun, type, mode, status, flags, ra, [dec], fieldID, modelMag_u, modelMag_g, modelMag_r, modelMag_i, modelMag_z

  3. Segment - This table contains the basic parameters associated with a Segment, which is a unit of data corresponding to a single camera column within a chunk.
    Segment Indices:

    Index TypeKey or Field List
    primary keysegmentID
    foreign keyChunk(chunkId)
    foreign keyStripeDefs(stripe)

  4. Field - This table contains all the measured parameters of each imaging field, along with relevant summary statistics, and astrometric and photometric information.
    Field Indices:

    Index TypeKey or Field List
    primary keyfieldID
    foreign keySegment(segmentID)
    covering indexfield, camcol, run, rerun
    covering indexrun, camcol, field, rerun

  5. Chunk - A chunk is a contiguous section of imaging data within a stave (stripe for the south). It consists of complete North and South strips between lower and upper mu limits. A chunk is composed of a set of touching but non-overlapping primary segments (or parts of segments).
    Chunk Indices:

    Index TypeKey or Field List
    primary keychunkID
    foreign keyStripeDefs(stripe)

  6. PhotoProfile - This table contains the light profiles of SDSS photo objects.
    PhotoProfile Indices:

    Index TypeKey or Field List
    primary keyobjID, bin, band
    foreign keyPhotoObjAll(objID)

  7. FieldProfile - This table contains the light profiles of SDSS field objects.
    FieldProfile Indices:

    Index TypeKey or Field List
    primary keyfieldID, bin, band
    foreign keyField(fieldID)

  8. Neighbors - SDSS objects within 0.5 arcmins and their match parameters are stored here. Make sure to filter out unwanted PhotoObj, like secondaries.
    Neighbors Indices:

    Index TypeKey or Field List
    primary keyobjID, NeighborObjID
    foreign keyPhotoObjAll(objID)

  9. Match - This table contains PhotoObj (primary and secondary object) pairs from different runs (observations) that probably are the same object. In effect, this table records multiple observations of each object.
    Match Indices:

    Index TypeKey or Field List
    primary keyobjID, matchObjID
    foreign keyPhotoObjAll(objID)

  10. MatchHead - Thhis table records the canonical object from each match cluster, and cluster statistics. The observations for an object (as recorded in the Match table) form a cluster named by the minimum objID in the cluster. MatchHead has summary information about the cluster keyed by the objID.
    MatchHead Indices:

    Index TypeKey or Field List
    primary keyobjID
    foreign keyPhotoObjAll(objID)

  11. First, Rosat and Usno - These tables contain matches between the FIRST, ROSAT and USNO survey objects and SDSS.

Spectro/Tiling Data Tables

  1. PlateX - This table contains data as exported (the X is for exported) from a given plate used for spectroscopic observations. Each plate has 640 observed spectra and hence 640 corresponding entries in SpecObjAll.
    PlateX Indices:

    Index TypeKey or Field List
    primary keyplateID
    covering indexhtmID, ra, dec, cx, cy, cz

  2. SpecObjAll - This is a base table containing ALL the spectroscopic information, including a lot of duplicate and bad data. Use the SpecObj view instead (see below), which has the data properly filtered for cleanliness.
    SpecObjAll Views:

    View NameContentsDescription
    SpecObj A view of Spectro objects that just has the clean spectra. The view excludes QA and Sky and duplicates. Use this as the main way to access the spectro objects.

    SpecObjAll Indices:

    Index TypeKey or Field List
    primary keyspecObjID
    foreign keyPlateX(plateID)
    covering indexhtmID, ra, dec, cx, cy, cz, sciencePrimary
    covering indexBestObjID, objType, objTypeName, sciencePrimary, specClass, htmID, ra, dec, fiberMag_u, fiberMag_g, fiberMag_r, fiberMag_i, fiberMag_z
    covering indexspecClass, zStatus, zWarning, z, sciencePrimary, primTarget, secTarget, plateId, bestObjID, targetObjId, htmID, ra, dec
    covering indextargetObjID, objType, objTypeName, sciencePrimary, specClass, htmID, ra, dec, fiberMag_u, fiberMag_g, fiberMag_r, fiberMag_i, fiberMag_z

  3. SpecLineAll - A compendium of all the spectral lines found in all the spectroscopic objects in the SpecObjAll table. Contains all the parameters measured for each spectral line. There is a SpecLine view of this table that contains only the lines that have been measured.
    SpecLineAll Views:

    View NameContentsDescription
    SpecLine A view of SpecLines objects that have been measured The view excludes those SpecLine objects which have category=1, thus they have not been measured. This is the view you should use to access the SpecLine data.

    SpecLineAll Indices:

    Index TypeKey or Field List
    primary keyspecLineID
    foreign keySpecObjAll(specObjID)
    covering unique indexspecobjID, specLineID

  4. SpecLineIndex - Precomputed spectral line indices. These are combinations of spectral line intensities used to determine various properties of galaxies, like age or metallicity.
    SpecLineIndex Views:
    None found
    SpecLineIndex Indices:

    Index TypeKey or Field List
    primary keyspecLineIndexID
    foreign keySpecObjAll(specObjID)
    covering unique indexspecobjID, speclineindexID

  5. TileAll - Contains information about individual tiles on the sky.
    TileAll Views:

    View NameContentsDescription
    Tile A view of TileAll that have untiled=0 The view excludes those Tiles that have been untiled.

    TileAll Indices:

    Index TypeKey or Field List
    primary keytile
    foreign keyTilingRun(tileRun)
    covering unique indextileRun, tile
    covering indexhtmID, racen, deccen, cx, cy, cz

  6. TiledTargetAll - This table stores information that keeps track of why a Target was assigned to a Tile.
    TiledTargetAll Views:

    View NameContentsDescription
    TiledTarget A view of TiledTargetAll objects that have untiled = 0 The view excludes those TiledTarget objects that have been untiled.

    TiledTargetAll Indices:

    Index TypeKey or Field List
    primary keytargetID, tile
    foreign keyTileAll(tile)
    covering unique indextile, targetID
    covering indexhtmID, ra, dec, cx, cy, cz, objtype
    covering unique indexobjType, targetID, tile

  7. TilingGeometry - This table contains geometrical information about tiling regions, including tiling boundaries. The TileBoundary view serves up the boundaries.
    TilingGeometry Views:

    View NameContentsDescription
    TilingBoundary A view of TilingGeometry objects that have isMask = 0 The view excludes those TilingGeometry objects that have isMask = 1. See also TilingMask.
    TilingMask A view of TilingGeometry objects that have isMask = 1 The view excludes those TilingGeometry objects that have isMask = 0. See also TilingBoundary.

    TilingGeometry Indices:

    Index TypeKey or Field List
    primary keytilingGeometryID
    foreign keyTilingRun(tileRun)
    foreign keyStripeDefs(stripe)

  8. TilingRun - Contains basic information about each run of the tiling software.
  9. TilingInfo - Contains information on what happened to a Target in a run of tiling software.

Metadata and Other Tables

  1. DBObjects - An auto-generated documentation table that contains a description of every object (table, view, function, stored procedure) in the database.
  2. DBViewCols - An auto-generated table containing a description of every column in every table in the database.
  3. DBColumns - An auto-generated table containing a description of every column in every view in the database.
  4. SpecPhotoAll - The combined spectro and photo parameters of an object in SpecObjAll. This is a precomputed join between the PhotoObjAll and SpecObjAll tables. The photo attibutes included cover about the same as PhotoTag. The table also includes certain attributes from the Tile table.
    SpecPhotoAll Views:

    View NameContentsDescription
    SpecPhoto A view of joined Spectro and Photo objects that have the clean spectra. The view includes only those pairs where the SpecObj is a sciencePrimary, and the BEST PhotoObj is a PRIMARY (mode=1).

    SpecPhotoAll Indices:

    Index TypeKey or Field List
    primary keyspecObjID
    foreign keySpecObjAll(specObjID)
    covering indexobjID, sciencePrimary, specClass, z, targetObjid, targetId
    covering indextargetObjID, sciencePrimary, specClass, z, objid, targetId
    covering indextargetID, sciencePrimary, specClass, z, objid, targetObjId

Accessing the CAS Data

The CAS uses a Microsoft SQL Server database to store and serve the data. Users can access this data by a number of methods.

Simple Search: Rectangular Radial    
SQL Interfaces: Web Page sdssQA Emacs Command Line
CasJobs
List Uploads: CrossID SpecList   
Visualization: Finding Chart Image Lists Navigator Explore
  1. The SkyServer. This provides a variety of methods to retrieve data:
    1. Radial search. Allows entry of a central coordinate, radius, and constraints on the five simplified magnitudes (ugriz). This query returns ONLY the object coordinates, type. simplified mags with errors, and the object id, as well as the quantities necessary to get data from the DAS (run/rerun/camcol/ field/obj).
    2. Rectangular Search. Identical to the radial search, except that the user specifies a minimum and maximum RA and Dec.
    3. SQL web form. Users can enter Structured Query Language (SQL) queries in a form, and the query will be executed. The query is limited in duration to ??? hours, or ??? rows. This query type allows selection of various attributes, combined photometric and spectroscopic queries, and the application of complex constraints. Users new to SQL will want to read our SQL help and the description of the data model and the parameters stored in the various tables.
    4. CrossID. Users input or upload a list of object names and coordinates, and get the nearest oject or objects in the SDSS database for each input object. The match radius is adjustable up to three arcminutes, and users can choose the quantities they want output for each match. The input list is limited to 1000 objects and the output to 10000 objects.
    5. SpecList. This page performs dynamic cross identifications of the SDSS spectroscopic objects with a user defined list of (plate, mjd, fiber) values. In order to avoid congestion on the server, the list is limited to 1000 objects, and to a size of 80KB.
    In addition, the SkyServer provides a tool called the Schema Browser, with which users can browse the various tables, views, and functions available for SQL queries, as well as the different columns available in each. All of the SkyServer interfaces allow data to be returned in HTML, XML, or CSV (comma separated variable) format.
  2. The SDSS Query Analyzer (sdssQA). This is a fully self-contained, downloadable Java application that allows submission of SQL queries to the database. It also includes a version of the Schema Browser, and a variety of example queries. With the sdssQA you can open multiple database connections, run multiple queries, and save the output to files on your local disk. Users wishing to run complex SQL queries will want to use this tool. The sdssQA can be downloaded from this page. Documentation on using the sdssQA is also available. Users should read our SQL help and the descriptions of the data model and the parameters stored in the various tables.
  3. Emacs interface. This interface, developed by Robert Lupton, which can be downloaded here. Robert has provided some example queries, and there is additional documentation available for this tool. Our SQL help and the descriptions of the data model and the parameters stored in the various tables are also applicable.
  4. sqlcl command line interface. A straightforward command line interface written in Python by Tamas Budavari. The tool can be downloaded, and some help found, on the sqlcl page.
  5. CasJobs batch query service. CasJobs allows you to submit queries and recover the results at a later time. It is a Web Service developed by Wil O'Mullane and Nolan Li. CasJobs allows you to submit unlimited queries and save the results to your own database on the server called MyDB. There is a user guide and FAQ available on the CasJobs page.

In addition to these database access tools, we have developed some simple interfaces to retrieve color JPG images for lists of objects, with optional overlays of catalog data, finding charts, and a navigation tool that allows you to move around a sky region in a MapQuest-like fashion:

  1. Finding Chart. Returns a single JPEG image centered on (ra,dec). This tool allows scaling of the output image, and a variety of overlays are available.
  2. Cutout Service. Users can upload a list of up to 1000 objects, and have small JPEG image cutouts for each object displayed, 100 to a page. A variety of overlays are available.
  3. Navigator. Displays a JPEG of an area of the sky, and allows the user to zoom and pan. A variety of overlays are available.
  4. Object Explorer. Enables you to find individual objects, either based upon their object IDs, or their sky position. The page presents a concise summary of all relevant information about the object, and provides links to all the additional information, like neighbors, fields, the spectroscopic object, spectral plates, cross-identifications in other surveys, or photometric redshifts of galaxies. We also provide links to the low-level data available as binary FITS tables. These include the corrected frames, bit-masks, binned sky, the atlas images and the spectra.