Please look at the FAQ and tutorials below to see if your question has an answer. Much of what you need to know is already available:
If the FAQ and tutorials below, as well as the documentation here or on SkyServer, fail to answer your question, you may email us at the helpdesk, and your question will be directed to a survey expert.
Jump to:
SpecObj and SpecObjAll? What does sciencePrimary mean?PhotoObj, PhotoTag, and PhotoObjAll?SpecPhoto and SpecPhotoAll?specClass and objType for spectroscopic objects, and which one should I use?objID and SpecObj specObjID fields?HTM (Hierarchical Triangular Mesh) spatial index library?A terrific new survey mapping the Universe on the largest scales, mapping our galaxy, and finding planets around other stars. A full description of SDSS-III is available on our front page.
The most recent, 8th data release (DR8), is available here. The previous SDSS data release, DR7, can be obtained from this website.
The SDSS-III data can be accessed in two ways. It can be viewed as catalog data (such as redshifts, metallicity, etc.) or as FITS images and data files. Catalog data, along with preview images and spectra, are available from the Catalog Archive Server. FITS images and data are available from the Science Archive Server. For specific detail on how to access the data please refer to this page for the imaging data and this page for the spectroscopic data.
SkyServer is a web site where professional astronomers, students and members of the general public can get data from the SDSS. SkyServer's Projects are excellent resources for astronomy educators who want to include real data in their courses.
The SDSS takes data in long, narrow "stripes." See the scope page showing the DR8 imaging and spectroscopic coverage. The CAS Navigate tool also has an interactive sky globe that shows where the SDSS has data. To see if a specific area has been seen by the SDSS, enter its coordinates into the Finding Chart.
When you search for data in the SDSS, you are going through the SDSS database and looking for objects that match criteria you choose. For simple searches of photometric data, use the Imaging Query Form. For simple searches of spectroscopic data, use the Spectroscopic Query Form. For more complex searches, use Structured Query Language (SQL). See the CAS's guide on Searching for Data to learn more about SQL. To see thumbnail results of objects that meet your criteria, use the Image List tool.
For large, complex queries that will take a long time to run, use CasJobs, the SDSS's batch query interface.
The CAS has many other tools too. See Getting Started for more information on all the tools, as well as the imaging data access page and the the spectro data access page.
Apart from this page there is a Glossary of SDSS-III terms. Each SkyServer tool also has its own Help section. Finally, the SDSS-III helpdesk is there to help.
SkyServer's Projects use SDSS data to teach topics in astronomy and other sciences, using guided and open inquiry. With our Projects, you and your students can learn about spectra and colors of stars, galaxy types, the history of the universe, and much more.
You are welcome to use and adapt any of our projects in your classes, free of charge. For more information on what you can do with SkyServer in the classroom, see our Teacher FAQ.
Find the coordinates of the object using a name resolver like SIMBAD or NED.
Then, go to the CAS's Navigate tool and enter the object's coordinates. You can enter the coordinates as decimal degrees or as sexagesimal in the format HH:MM:SS and (+/-)DD:MM:SS. Click "Get Image" to see the object, and click on the object for its SDSS data. See the Help link in the Navigate tool for more information.
If you have a fairly small list of objects to match - a few hundred or so - use the Cross-ID tool. Paste your list of objects, or upload a file containing data with the last two columns as (ra, dec) in decimal degrees. Click Submit. The next page will show only those objects that appear in the SDSS, with SDSS Object IDs that link to the Explore tool.
To see a thumbnail SDSS image of each matching object, use the Image List tool. Enter your list in the textbox on the upper left and click "Get Image". Click on one of the thumbnails to go to that position in the Navigate tool, or on one of the object names to go to that object's Explore tool entry.
For longer lists, use the Neighbors Search feature of CasJobs. See the CasJobs FAQ entry on "How can I cross-identify (find matching objects in SDSS) for my list of sources for which I have RA,decs?" for more information.
The SDSS has a very sensitive camera. Stars that you can see with your unaided eyes are a little too bright for the SDSS's camera, so they show up as washed out. The SDSS still gets an image of those stars (for example, here is an image of Pollux from SkyServer), but their images are unreliable, and the SDSS gets no catalog data.
The SDSS distinguishes between stars and galaxies based on their shapes: single points of light are stars, and fuzzy patches of light are galaxies. Some stars are bright enough that their light washes out the camera, so to the SDSS's camera, they look like fuzzy disks instead of single points of light. Their appearance fools the SDSS's software into classifying them as galaxies.
The SDSS needs a way to uniquely identify every object in the database, so it generates ID numbers. The ID numbers are code numbers that include information about how the object was observed.
One very important point when working with SkyServer is that the object IDs are so long that they get cut off in Excel, and show up with 000 as the last three digits. This means you won't be able to find your objects anymore! To get around this problem, see this workaround.
The Catalog Archive Server (CAS) is the database that contains the SDSS-III's catalog data. The Science Archive Server (SAS) serves flat files and provides searches for FITS spectra, images of fields, and mosaics. There are multiple interfaces to the data, including:
The SDSS measures magnitudes through ugriz filters, which give ugriz magnitudes. These magnitudes can be converted into UBVRI magnitudes using a set of transformations described on the Algorithms page of this site.
The SpecObjAll table contains ALL spectroscopic
objects, even duplicate spectra of the same object. Thus, we have
created the SpecObj view, which contains data for ONLY
those fibers defined as sciencePrimary. That is, specObj contains no
duplicate observations. An exact definition of sciencePrimary can be
found in the spectroscopic catalog
documentation.
PhotoObjAll is a table which contains all of the measured photometric quantities for all of the imaging detections. Because we measure hundreds of parameters for each of 1.2 billion detections, this is a very large table, and queries can take very long to run. Also, because it includes duplicates and "special" detections such as parent or bright detections, it is not normally what you want.
In an effort to speed up queries, we have created PhotoTag, a table with only a subset of the parameters that are requested most often (a "thin table"). If you have a query that uses and returns only values stored in PhotoTag, it will execute much faster than if you used PhotoObjAll.
In addition, we have created PhotoObj, a view of PhotoObjAll that contains only those objects that are survey primary or survey secondary. These tables exclude special objects such as parent or bright detections. Because this view effectively contains fewer objects than PhotoObjAll (but all the measured quantities for these objects), queries will execute faster.
Finally, there is PhotoPrimary, a view of PhotoObjAll which only includes survey primary detections; if you are not interested in duplicate detections at all, this is the table to use.
Given the above, you should consider:
PhotoTag if it contains everything you are looking forPhotoObj otherwise, UNLESS you are interested in data for objects which are
neither PRIMARY nor SECONDARY. In that case, you will need to use PhotoObjAll.Because PhotoTag has many fewer parameters, larger portions of it can be cached, improving performance. We have found that for almost all queries which contain parameters fully in PhotoTag, it is faster.
The SpecPhotoAll table is a precomputed join between the PhotoObjAll and SpecObjAll tables. It includes the most requested parameters from these two tables. Because the join has already been performed, it can be faster than computing the join on the fly.
Be aware that the join was performed using bestobjid,
the flux-based match. Consult the spectroscopic-photoometric matching
documentation for details. In particular, for spectroscopic
objects which are definitely point sources, the flux-based match can
be less appropriate than a pure position-based match. To perform a
join using the position-based match, join using
origobjid.
The SpecPhoto view includes only those pairs where the SpecObj is a sciencePrimary (see the definition above), and the PhotoObj is a survey primary object.
Internally, these numbers are stored to their full precision as they come out of the spectroscopic pipeline. When you perform a query, they have some default string format applied that cuts them to what you see. But you can use SQL's str() function to change the string format to whatever you like.
To get z to 6 decimals, for example, change your query to 'select str(z,8,6) as z' instead of just z, and analogously for zErr. This applies the function str() to the values in column z and returns the result with column label z (without the "as", the result of a function has no column label). The str(col,length,dec) function takes the numerical value in 'col' and formats it as a string of length 'length' and with 'dec' significant digits. In other words, str(z,8,6) is the SQL equivalent to the C function printf("%8.6f",z). str() rounds the result to the number of decimals you request.
Use the str(column,n,d) SQL construct (where n is the total number of digits and d is the number of decimal places) to set the precision of the column that your query requests. SkyServer returns values with a default precision that is set for each data type, and this may not be enough precision for some types of science. See the sample query "Selected neighbors in run" for an example of how to use STR.
The objType parameter in SpecObj and other
tables was set when the objects are targeted
for spectroscopy in the Legacy survey, based only on the photometry. The
class parameter is set by the spectroscopic
pipeline after the spectrum is observed. Typically, you should use
the class attribute, which tells you what the spectrum actually
was. The objType field tells you about why it was targeted (however,
there is more information in the target bits; see the algorithms pages on target selection.
The 64-bit ID fields are required as primary keys (unique identifiers) in the SDSS database tables. They are used to uniquely identify each record in the database indices for enhanced performance. Each of them are bit-encoded with information about the observational origin, i.e., the run,rerun, camera column, etc. for photometric data, and the plate, MJD, fiberID etc. for spectroscopic objects. See the glossary for exactly how objid and specobjid are defined.
A copy of the current publicly-available SDSS data release is available from UIC (University of Illinois at Chicago) for worldwide distribution over fast links. Please see the SkyServer support site at skyserver.org for further details on how to host a mirror site and where to get the data. Click on the SDSS Mirrors link on that site.
Freely downloadable copies of the HTM library (in C++, Java and now C#) are available at the SkyServer support site at skyserver.org. Click on the HTM link on that site.
These are places where the SDSS spectrograph measured a spectrum, but that spectrum did not match spatially with a specific object in SDSS photometry. Most of these spectra without photometric matches are Sky spectra - but some are spectra of real objects that have no photometric match in DR8. For example, the deblending may have changed, or in the latest reductions the photometric pipeline may have failed on the field containing that object.
These pages provide detailed worked examples of SDSS data retrieval using the various interfaces provided. In addition, we provide discussions of how to access and read some of the unusual file types used in the survey, and perform certain operations, such as calibration.
.par files