Data sources and formats

Elevation is typically considered a continuous value and is best represented by 32-bit floats. In some cases, it can be stored in other formats (for example, SRTM is stored as 16-bit integers), but presuming your data includes numerous sources, it is typically managed as 32-bit float.

For a data format, it is recommended to use tiled TIFF, LZW compression, with internal tile size 128 or 256 pixels for storing elevation data. This generally provides the fastest access and smallest size. Since elevation data is often stored in other formats (FLT, IMG, BAG, HRE, ASCII, and so on), you may want to consider converting these formats to tiled TIFF to improve efficiency. In some cases (for example, ASCII), conversion to TIFF is highly recommended to reduce data volumes.

Note that elevation data should generally not be unnecessarily reprojected or resampled from its original source. Transforming rasterized elevation data from one coordinate system to another will degrade the quality of the data. See specific recommendations in the Standard Workflow that recommend that raster data not be reprojected as part of data management.

It is generally recommended that all source data include pyramids to provide faster access at smaller scales. This is especially important if users later do a lock raster on a dataset and want to view it at small scales. If pyramids are not provided with the original data (or the data is reformatted as noted above), pyramids should be created as described in the Standard Workflow (see Data structure and Preprocessing sections).

For lidar data (often stored as LAS), conversion to a format such as TIFF may significantly reduce data volume, but it will result in loss of point information. Within ArcGIS, lidar data can be handled by directly using LAS files or LAS datasets within a mosaic dataset so that no data is lost. Alternatively, the lidar can be rasterized to a DEM or DSM with fixed pixel size. For terrains that are best represented by model points and breaklines, it is best to either manage the data as a LAS dataset that includes both the LAS data and breaklines or extract only the required points and breaklines into a managed terrain. This guidebook will focus primarily on gridded elevation data sources, but the same concept can be applied to LAS files, LAS datasets, and terrains, which can be used as input to mosaic datasets.

Many organizations have their own collections of elevation data acquired by various means. Typically, these have been managed as separate projects, often resulting in users spending a considerable amount of time finding data suitable for different projects. Similar to the World Elevation services, it is generally recommended that data managers combine elevation sources into a single set of mosaic datasets and elevation services that can then be easily referenced by multiple applications.

In many cases, it is advantageous to obtain datasets that cover larger areas than the individual project areas, to provide a better, more extensive base. The following are locations for datasets that are publicly available and can be downloaded for use in such services.

Approximate Pixel Size (m)

Data Identifier

Primary Sources

3.1

NED 1/9 Arc Second

http://www.usgs.gov

10

NED 1/3 Arc Second

http://www.usgs.gov

31

NED 1 Arc Second

http://www.usgs.gov

62

NED 2 Arc Second

http://www.usgs.gov

93

SRTM

http://www.usgs.gov, http://www.cgiar-csi.org, http://www.nasa.gov

232

GMTED2010

http://www.usgs.gov

928

GEBCO bathymetry

http://www.bodc.ac.uk

4,638

EGM2008 geoid

http://earth-info.nga.mil

Elevation datasets location

In addition, multiple commercial vendors provide elevation data.

Typically, each of the sources is combined into separate source mosaic datasets, and quality assurance checks are done on each. Then a derived mosaic dataset is created and combines all the datasets into a single mosaic dataset that is served.

10/28/2013