The SRTM instrument consisted of the Spaceborne Imaging Radar-C (SIR-C) hardware set modified with a Space Station-derived mast and additional antennae to form an interferometer with a 60 meter long baseline. A description of the SRTM mission, can be found in Farr and Kobrick (2000).

The Shuttle Radar Topography Mission (SRTM) obtained elevation data on a near-global scale to generate the most complete high-resolution digital topographic database of Earth. SRTM consisted of a specially modified radar system that flew onboard the Space Shuttle Endeavour during an 11-day mission in February of 2000.

Synthetic aperture radars are side-looking instruments and acquire data along continuous swaths. The SRTM swaths extended from about 30 degrees off-nadir to about 58 degrees off-nadir from an altitude of 233 km, and thus were about 225 km wide. During the data flight the instrument was operated at all times the orbiter was over land and about 1000 individual swaths were acquired over the ten days of mapping operations. Length of the acquired swaths range from a few hundred to several thousand km. Each individual data acquisition is referred to as a "data take."

SRTM was the primary (and pretty much only) payload on the STS-99 mission of the Space Shuttle Endeavour, which launched February 11, 2000 and flew for 11 days. Following several hours for instrument deployment, activation and checkout, systematic interferometric data were collected for 222.4 consecutive hours. The instrument operated virtually flawlessly and imaged 99.96% of the targeted landmass at least one time, 94.59% at least twice and about 50% at least three or more times. The goal was to image each terrain segment at least twice from different angles (on ascending, or north-going, and descending orbit passes) to fill in areas shadowed from the radar beam by terrain.

This perspective view shows Mount Ararat in easternmost Turkey, which has been the site of several searches for the remains of Noah's Ark.

This 'targeted landmass' consisted of all land between 56 degrees south and 60 degrees north latitude, which comprises almost exactly 80% of the total landmass.

Data Set Characteristics

SRTM data were processed in a systematic fashion using the SRTM Ground Data Processing System (GDPS) supercomputer system at the Jet Propulsion Laboratory. Data were mosaicked into approximately 15,000 one degree by one degree cells and formatted according to the Digital Terrain Elevation Data (DTED) specification for delivery to NIMA, who will use it to update and extend their DTED products. Data were processed on a continent-by-continent basis beginning with North America. NIMA is applying several post-processing steps to these data including editing, spike and well removal, water body leveling and coastline definition. Following these "finishing" steps data will be returned to NASA for distribution to the scientific and civil user communities, as well as the public. In advance of that, the unedited data are being released for public use subject to the caveats discussed below.

Organization

SRTM data are organized into individual rasterized cells, or tiles, each covering one degree by one degree in latitude and longitude. Sample spacing for individual data points is either 1 arc-second or 3 arc-seconds, referred to as SRTM-1 and SRTM-3, respectively. Since one arc-second at the equator corresponds to roughly 30 meters in horizontal extent, the sets are sometimes referred to as "30 meter" or "90 meter" data.

Unedited SRTM-3 data are being released continent-by-continent, with the definitions of the continents displayed in the file Continent_def.gif. By agreement with NIMA unedited SRTM-1 data for the United States and its territories and possessions are also being released and can be found in the directory /United_States_1arcsec./ Cells that straddle the border with neighboring countries have been masked with quarter degree quantiation such that data outside the U.S. have the void value.

Elevation mosaics

Each SRTM data tile contains a mosaic of elevations generated by averaging all data takes that fall within that tile. Since the primary error source in synthetic aperture radar data is speckle, which has the characteristics of random noise, combining data through averaging reduces the error by the square root of the number of data takes used. In the case of SRTM the number of data takes could range from a minimum of one (in a very few cases) up to as many as ten or more.

Data Formats

The names of individual data tiles refer to the longitude and latitude of the lower-left (southwest) corner of the tile (this follows the DTED convention as opposed to the GTOPO30 standard). For example, the coordinates of the lower-left corner of tile N40W118 are 40 degrees north latitude and 118 degrees west longitude. To be more exact, these coordinates refer to the geometric center of the lower left pixel, which in the case of SRTM-1 data will be about 30 meters in extent.

SRTM-1 data are sampled at one arc-second of latitude and longitude and each file contains 3601 lines and 3601 samples. The rows at the north and south ecges as well as the columns at the east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell.

SRTM-3 data are sampled at three arc-seconds and contain 1201 lines and 1201 samples with similar overlapping rows and columns. This organization also follows the DTED convention. Unlike DTED, however, 3 arc-second data are generated in each case by 3x3 averaging of the 1 arc-second data - thus 9 samples are combined in each 3 arc-second data point. Since the primary error source in the elevation data has the characteristics of random noise this reduces that error by roughly a factor of three.

This sampling scheme is sometimes called a "geographic projection", but of course it is not actually a projection in the mapping sense. It does not possess any of the characteristics usually present in true map projections, for example it is not conformal, so that if it is displayed as an image geographic features will be distorted. However it is quite easy to handle mathematically, can be easily imported into most image processing and GIS software packages, and multiple cells can be assembled easily into a larger mosaic (unlike the pesky UTM projection, for example.)

DEM File (.HGT)

The DEM is provided as 16-bit signed integer data in a simple binary raster. There are no header or trailer bytes embedded in the file. The data are stored in row major order (all the data for row 1, followed by all the data for row 2, etc.).

All elevations are in meters referenced to the WGS84 EGM96 geoid as documented at http://www.nima.mil/GandG/wgsegm/.

Byte order is Motorola ("big-endian") standard with the most significant byte first. Since they are signed integers elevations can range from -32767 to 32767 meters, encompassing the range of elevation to be found on the Earth.

In these preliminary data there commonly will be data voids from a number of causes such as shadowing, phase unwrapping anomalies, or other radar-specific causes. Voids are flagged with the value -32768.

Notes and Hints for SRTM Data Users 

Data Encoding

Because the DEM data are stored in a 16-bit binary format, users must be aware of how the bytes are addressed on their computers. The DEM data are provided in Motorola or IEEE byte order, which stores the most significant byte first ("big endian"). Systems such as Sun SPARC and Silicon Graphics workstations use the Motorola byte order. The Intel byte order, which stores the least significant byte first ("little endian"), is used on DEC Alpha systems and most PCs. Users with systems that address bytes in the Intel byte order may have to "swap bytes" of the DEM data unless their application software performs the conversion during ingest.

SRTM Caveats

As with all digital geospatial data sets, users of SRTM must be aware of certain characteristics of the data set (resolution, accuracy, method of production and any resulting artifacts, etc.) in order to better judge its suitability for a specific application. A characteristic of SRTM that renders it unsuitable for one application may have no relevance as a limiting factor for its use in a different application.

In particular, data produced by the PI processor should be considered as "research grade" data suitable for scientific investigations and development and testing of various civil applications.

No editing has been performed on the data, and the elevation data in particular contain numerous voids and other spurious points such as anomalously high (spike) or low (well) values. Water bodies will generally not be well-defined - in fact since water surfaces generally produce very low radar backscatter they will appear quite "noisy" or rough, in the elevations data. Similarly, coastlines will not be well-defined.

References

Farr, T.G., M. Kobrick, 2000, Shuttle Radar Topography Mission produces a wealth of data, Amer. Geophys. Union Eos, v. 81, p. 583-585.

Rosen, P.A., S. Hensley, I.R. Joughin, F.K. Li, S.N. Madsen, E. Rodriguez, R.M. Goldstein, 2000, Synthetic aperture radar interferometry, Proc. IEEE, v. 88, p. 333-382.

DMATR 8350.2, Dept. of Defense World Geodetic System 1984, Its Definition and Relationship with Local Geodetic Systems, Third Edition, 4 July 1997. http://164.214.2.59/GandG/tr8350_2.html

Lemoine, F.G. et al, NASA/TP-1998-206861, The Development of the Joint NASA GSFC and NIMA Geopotential Model EGM96, NASA Goddard Space Flight Center, Greenbelt, MD 20771, U.S.A., July 1998.

Other Web sites of interest:

NASA/JPL SRTM

NIMA

STS-99 Press Kit

Johnson Space Center STS-99

German Space Agency

Italian Space Agency

U.S. Geological Survey, EROS Data Center

For ARC/INFO Users

Users of ARC/INFO or ArcView can display the DEM data directly after
renaming the file extension from .HGT to .BIL. However, if a user needs
access to the actual elevation values for analysis in ARC/INFO the DEM must be converted to an ARC/INFO grid with the command IMAGEGRID. For IMAGEGRID to work there must be a separate header file whose name (including case) is exactly the same as the image file name. The contents of a sample file that works with 3 arc-second SRTM file N37W105.hgt are below

BYTEORDER      M
LAYOUT       BIL
NROWS         1201
NCOLS         1201
NBANDS        1
NBITS         16
BANDROWBYTES         2402
TOTALROWBYTES        2402
BANDGAPBYTES         0
NODATA        -32768
ULXMAP        -105.0
ULYMAP        38.0
XDIM          0.000833333333333
YDIM          0.000833333333333

IMAGEGRID does not support conversion of signed image data, therefore the negative 16-bit DEM values will not be interpreted correctly. After running IMAGEGRID, an easy fix can be accomplished using the following formula in Grid:

out_grid = con(in_grid >= 32768, in_grid - 65536, in_grid)

The converted grid will then have the negative values properly represented, and the statistics of the grid should match those listed in the .ANN file.

Source: NIMA

Accessing SRTM Data

In accordance with NASA policy, the USGS EROS Data Center hosts and distributes SRTM data via the USGS Seamless Data Distribution System - Enhanced. Electronic Download: Up to an area 30 degrees square of raster data (1.6 gigabytes), in 100 megabyte sized files, are downloadable at no charge.

http://srtm.usgs.gov/data/obtainingdata.html

FTP site - ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/