Managing elevation data: Part 1: About elevation data

Before getting started with a workflow to manage and disseminate your elevation data, there are many things that you should first understand about the data. This workflow is divided into three parts. The first part is a discussion about elevation data. The second part discusses the data management plan and issues to consider. The third part walks you through the steps to manage and publish the elevation data.

Ground versus surface elevation

There are two fundamental elevation representations required to support most users: the elevation of the ground and of the surface. The ground elevation is sometimes referred to as bare earth or bald earth or the digital elevation model (DEM), whereas the surface elevation is generally defined by the earth and the things upon it, including buildings, the canopy of trees, bridges, and so on. The surface elevation is sometimes referred to as the digital surface model (DSM). Some also use the digital terrain model (DTM) term to refer to DEM data stored and modeled directly from points.

Generally, the DEM is needed for orthorectification of aerial imagery, whereas a DSM should be used for viewshed calculations.

A fourth representation is a hydrographically enforced DEM. This is a special case of the DEM that has been developed according to rigorous methods and quality checks for use in hydrologic modeling, such as computer modeling of water flow. This type of DEM is not applicable in many organizations or applications, but will be mentioned where applicable in the remainder of this workflow.

Representation of water bodies

Water bodies can be represented differently in elevation models. How they’re represented generally depends on what the users will need. The typical options include:

1. Water is a flat surface—For example, for simple visualizations, all lakes and oceans should appear at their normal water levels. In some cases, the water bodies may be normalized to have an elevation value of zero. This is typically used for orthorectification.
2. Water subsurface is valid—For example, for hydrologic modeling, a civil engineer may want to know the topography of a river basin without any water present. Therefore, the DEM includes bathymetric data.
3. Water is NoData (since it is not ground)—For example, for an application requiring accurate calculations of land area.

For most applications, the first case is the preferred interpretation.

Ellipsoidal versus orthometric height

Another data attribute that the data manager needs to understand is ellipsoidal height and orthometric height. Ellipsoidal height refers to elevation values above or below an idealized surface which approximates the shape of the earth as a simple spheroid. An example of an ellipsoid is WGS 84, but there are many different ellipsoids in use.

It is important to understand that the ellipsoid is a very smooth surface, and it can vary greatly from the local sea level (which is defined by a geoid model). Modern positioning technologies (for example, satellite orbital positions and GPS, heavily used in aerial photography, lidar, and topographic radar, as well as ground-based surveying) typically make all measurements relative to a reference ellipsoid.

Orthometric height refers to elevation values above or below a geoid model surface; the geoid approximates local sea level. Although the geoid is also a mathematical surface that is relatively smooth, it includes much more variation than the ellipsoid, caused by local differences in gravity. For traditional (non-satellite based) surveying methods, all measurements are generally made relative to the geoid (local sea level).

• Ellipsoidal Heights are typically used for applications based on GPS data, and for orthorectification of satellite imagery, whereas aerial photography can use either depending on the datum used for the exterior orientation. The exterior orientation can be either orthometric (if the control for the project was generated using ground station data) or ellipsoidal (such as airborne GPS + IMU). In the latter case, ellipsoidal ground height would be required to support the orthorectification process.
• Orthometric Heights are typically used in surveying, hydrology, agriculture, and land management.

Most elevation datasets are processed to report orthometric height, but the data manager must understand the difference and confirm what is provided in input data. In addition, it is very likely to be a requirement to serve elevation data in both formats, requiring a conversion process.

For more information, see http://www.ngs.noaa.gov/GEOID/PRESENTATIONS/2007_02_24_CCPS/Roman_A_PLSC2007notes.pdf.

For most scenarios, it is recommended that the base elevation service is configured for orthometric height, then if ellipsoidal heights are required, functions may be applied (using an appropriate geoid) to calculate an ellipsoidal height service. Examples are available at the following links:

• Converting from orthometric to ellipsoidal heights using the geoid (EGM96) in ArcGIS.
• BLOG specific to EGM2008: Converting from orthometric to ellipsoidal heights using EGM2008.

Accuracy of elevation measurements

There are two common values associated with remotely sensed data and mapping to define the accuracy of the data: circular error and linear error. Horizontal spatial accuracy is the circular error of a dataset's horizontal coordinates at a specified percentage level of confidence. Vertical spatial accuracy is defined by the linear error of a dataset's vertical coordinate at a specified percentage of confidence, such as an elevation measurement. Basically, accuracy is measured by the probability distribution that a value has from the true value. An accuracy of 90 percent confidence level means that 90 percent of positional accuracies will be equal to or smaller than the reported accuracy value.

You may see items in the metadata, such as CE90; this signifies that it is a measure of circular error of 90 percent and will often have a value associated with it, whereas LE90 signifies a linear error of 90 percent. You may also see VE for vertical error (which is linear error in a vertical direction). For example, SRTM data is often reported as having VE90 = 16m, meaning that 10 percent of the vertical measurement may deviate by greater than 16m from the correct vertical measurement at a point (considering latitude, longitude, and height inaccuracies).

National mapping standards have been in place since 1947. For example, "For maps on publications scales larger than 1:20,000, not more than 10 percent of the points tested shall be in error by more than 1/30 inch…These limits of accuracy shall apply in all cases to positions of well-defined points only…such as, monuments, or markers, intersections of roads, etc." (U.S. Bureau of the Budget, 1947). New standards have been adopted over time, with the latest being published by the Federal Geographic Data Committee (FGDC) in 1998. For example, to report an accuracy classification of 1 meter for a feature with a 95 percent confidence, the accuracy on the data must be less than or equal to 1 meter. The main difference in these measurements is the standard is no longer based on a measure using scale. You may also notice that the measurement has become more accurate—changing from CE90 to CE95.

References:

1. Federal Geographic Data Committee, 1998, Part 2, Standards for Geodetic Networks, Geospatial Positioning Accuracy Standards, FGDC-STD-007.2-1998: Washington, D.C., Federal Geographic Data Committee.
2. Principles of Error Theory and Cartographic Applications by C.R. Greenwalt and M.E. Shultz, ACIC Technical Report No. 96, Aeronautical Chart and Information Center, St. Louis, 1968 (reprinted).
3. U.S. Bureau of the Budget, 1947, United States National Map Accuracy Standards: U.S. Bureau of the Budget, Washington, D.C.

Data Sources

There are three basic types of data.

1. Public data (free, typically from government sources)
2. Data procured from mapping vendors providing off-the-shelf products
3. Proprietary data generated by your organization (either via in-house sources or via contract with a mapping service provider)

These or other data sources may offer elevation data via the Internet as a service or as data that can be downloaded. An organization could consider using that service, but the associated workflow assumes the data manager is using in-house, locally stored data.

Public data

Below is a table listing some sources of public domain elevation data.

• GTOPO is a global elevation dataset with a resolution of 30 arc seconds (approximately 1 km), available for download at http://www1.gsi.go.jp/geowww/globalmap-gsi/gtopo30/gtopo30.html.
• ETOPO is a 1 arc-minute global relief model of Earth's surface that integrates land topography and ocean bathymetry, available for download at http://www.ngdc.noaa.gov/mgg/global/global.html.
• Global Multi-resolution Terrain Elevation Data 2010 (GMTED2010) is a suite of products at three different resolutions (approximately 1,000, 500, and 250 meters) that will be provided by the USGS. For more information, see http://pubs.usgs.gov/of/2011/1073.
• The Shuttle Radar Topography Mission (SRTM) is elevation data on a near-global scale, acquired from the Space Shuttle, to generate the most complete high-resolution digital topographic database of Earth. It is available at http://srtm.usgs.gov/index.php.
• The Advanced Spaceborne Thermal Emission and Reflection Radiometer (ASTER) is an instrument on NASA's Terra satellite, and stereo imagery from this sensor was processed to generate a nearly global digital-elevation model between 83N and 83S latitudes with 30-meter postings. It is available at http://asterweb.jpl.nasa.gov/gdem.asp.
• The National Elevation Dataset (NED) was created by the USGS for the USA. NED data is available nationally at resolutions of 1 arc-second, 1/3 arc-second, and 1/9 arc-second (in limited areas). Learn about it at http://ned.usgs.gov/.
• Geoid models such as EGM96 and EGM2008. (The geoid built into ArcGIS is an approximation of EGM96.)
• Esri's World Elevation services provide simple, online access to global collections of multi-resolution, multi-source elevation data, elevation data products, related applications, and additional services. These services are part of the World Elevation group in www.arcgis.com.

Procured

The following are some private companies that provide (for a cost) elevation data either as a preprocessed (off the shelf) product or via custom acquisition projects as desired:

• Intermap (www.intermap.com/)
• SPOT (http://www.spot.com/)
• FUGRO (http://www.fugro.com/)
• … and many private surveying companies

Organization data

A third possible source of elevation data is to develop it within your own organization. This may be internally generated using in-house capabilities such as ground surveying crews or other technologies, such as photogrammetry or lidar. Or your organization may acquire the data through a custom contract.

Types of systems as data sources

In addition to “Where can our organization get elevation data?”, it may be important for the data manager to understand the types of sensor systems or technologies that provide elevation data. A detailed discussion of technologies is not attempted here, but organizations using elevation data may need to understand a few basics regarding current technologies for terrain mapping from aerial or satellite platforms, such as photogrammetry, radar, and lidar.

Photogrammetry

An introduction to photogrammetry can be found at www.geodetic.com. The key concepts for a data manager to understand about photogrammetry include:

• Photogrammetry can be used to generate an elevation model for the area covered by stereo aerial photography.
• Elevation data, if available, can also be used as an input to the photogrammetric process to perform corrections to image data.
• In heavily forested areas, where bare ground cannot be observed in the imagery, the resulting elevation model may represent the top of the tree canopy (DSM), or the bare earth DEM may only be an estimated surface.

Airborne lidar

An introduction to lidar can be found at http://en.wikipedia.org/wiki/LIDAR.

The key concepts for data manager to understand about lidar data include:

• Lidar may be collected from a variety of platforms, including satellite, airborne, or mobile or stationary terrestrial platforms.
  • For topographic mapping, airborne lidar is the most common.
  • Terrestrial lidar systems are becoming more common for acquiring 3D data points of cities, buildings (exterior and interior), and other structures. (Terrestrial lidar data is typically not applicable in the context of this elevation workflow, but that may change over time.)
  • Specialized lidar systems can also be used for bathymetric mapping (see below).
• Lidar is (originally) ungridded 3D data stored in a point cloud format. It is often processed to create raster surfaces (DEM or DSM).
• Lidar is an active sensing system—not dependent on sunlight for operation. However, many modern lidar systems include a digital camera system.
• Lidar is arguably the most successful technology for acquiring both DSM and DEM elevation data. Although the lidar signal cannot penetrate tree canopies, the high resolution of the scanning laser can effectively pass through periodic gaps in the tree canopy to collect a relatively good representation of the bare earth DEM.

• Lidar data, stored as LAS files does not need to be converted to raster surfaces to add the data to a mosaic dataset. LAS files can be added to a mosaic dataset directly.

  Learn about adding LAS data to a mosaic dataset

• A detailed White Paper about Lidar Analysis in ArcGIS 10 for Forestry Applications.

Radar and radargrammetry

An introduction to radar terrain mapping can be found at http://www.intermap.com.

The key concepts for the data manager to understand about radar terrain mapping include:

• Radar mapping systems are active (they don’t require sunlight, unlike aerial photography) and the wavelengths can penetrate clouds. This makes radar effective in tropical climates and also for extended operation (early morning, late evening, or even after dark).
• Radar wavelengths result in limitations. For example, the horizontal and vertical accuracy are usually measured in meters or decimeters, versus centimeters for an optical system such as lidar.
• Depending on the wavelength, some radar systems partially penetrate vegetation (but with a tradeoff in terms of lower accuracy), versus others that are higher accuracy but cannot penetrate vegetation (thus generating a digital surface model, but having difficulty creating a digital elevation model in heavily forested areas).
• Raw radar data requires specialized processing to generate elevation data which is not available in ArcGIS.

Sonar

For bathymetric mapping of the subsurface geometry in lakes or the ocean, one common technology is sonar. See http://en.wikipedia.org/wiki/Bathymetry for background information.

The key concepts for data manager to understand about terrain mapping using sonar include:

• The horizontal resolution and vertical accuracy of sonar systems is less than it is for equivalent terrestrial surveys.
• A gap often exists along the shoreline between where bathymetric data ends and terrestrial elevation datasets begin. This tidal/shoreline region may require special processing to avoid NoData gaps.

Airborne lidar can also be used for bathymetric mapping. See http://gcmd.nasa.gov/records/GCMD_USACE_SHOALS.html.

Data structures

Floating point versus integer data

Elevation data is based on point samples, and interpolation is frequently necessary to estimate elevation areas lacking samples. The elevation values are typically stored in floating-point format, although some small-scale data (such as SRTM) is stored in integer format. The data manager should understand the data types.

In most cases, the results of analysis or visualization products can be delivered as images in integer format, whereas users and applications that utilize elevation data values require floating-point data. (See descriptions in Part 2 for more information.)

The advantages to using integer data (where appropriate) are

• Reduced data volume (8 or 16 bits per sample vs. 32 for floating-point data)
• Compression is simpler (faster to process, with a greater compression ratio)

But note that if integer elevation values are used, one disadvantage is that steps (terraces) may appear in some products (such as a hillshade) due to rounding. The example below shows a region represented by SRTM data with terracing in a hillshaded product.

Some data is provided in tiles. If you have control over how the data is tiled, it is recommended that there is at least a 1-pixel overlap between the tiles.

Typical formats

Esri’s recommended format for storing and serving raster elevation most efficiently is using the tiled TIFF 32-bit float format, using LZW compression. This format is the easiest to use and maintain, while providing the best performance. Other formats that may be encountered include:

• ESRI GRID—this is an older format that is no longer recommended for storing elevation data. The data manager should consider converting to TIFF to improve performance in a server environment.
• FLT—floating-point binary simple format—similar to 32-bit floating-point TIFF files but without a header. This is not a tiled format and is recommended only for small extents.
• ASCII DEM—this is a plain ASCII data file that may be a regular raster structure or irregularly gridded data. In the latter case, the file explicitly lists x,y,z values. It is inefficient for storage, reading, and writing, but it is a universal storage format. It is highly recommended that this data be converted to TIFF to improve performance.
• IMG from ERDAS—elevation data may be stored in the IMG format, which is supported by ArcGIS.
• BAG (bathymetry attributed grid)—this format is used for bathymetric data, and is partially supported in ArcGIS 10. The software properly reads the raster elevation data, but does not completely support all format components (such as golden points). For information about the format specification, see http://www.ngdc.noaa.gov/mgg/bathymetry/noshdb/ons_fsd.pdf.
• DTED (digital terrain elevation data)—this is a format specification with specific aspects about resolution and accuracy of elevation data, defined by the NGA (National Geospatial Intelligence Agency). The DTED format data will generally perform adequately; therefore, conversion is not required. See format information at https://www1.nga.mil/ProductsServices/TopographicalTerrestrial/DigitalTerrainElevationData/Pages/default.aspx.
• Esri’s terrain dataset—a terrain dataset is a multiresolution, TIN-based surface built from measurements stored as features in a geodatabase. They're typically made from lidar, sonar, and photogrammetric sources. Terrains reside in the geodatabase, inside feature datasets with the features used to construct them. They must be converted to a raster dataset—the TIFF is recommended. For more information, see What is a terrain dataset.
• HRE (high resolution elevation)—this is a relatively new format for storing high resolution elevation data. It is intended for a wide variety of National Geospatial-Intelligence Agency (NGA) and National System for Geospatial Intelligence (NSG) partners and members, and customers external to the NSG, to access and exploit standardized data products. HRE data replaces the current non-standard High Resolution Terrain Elevation/Information (HRTE/HRTI) products and also replaces non-standard products referred to as DTED level 3 thru 6.
• LAS format lidar data—This format supports three-dimensional point cloud data and is designed by ASPRS. It can be supported directly by a mosaic dataset, or by creating a LAS dataset.

Irregular elevation data

Elevation data is typically stored in a raster (grid) format. However, data managers need to be aware of data stored in irregular formats. One example is a triangular interpolated network (TIN). This irregular format is often used for storing elevation data, especially in the case of an organization that collects and maintains its own elevation data, since this retains the original data (for example, accurate elevation point samples in 3D). Another format is a terrain dataset (mentioned above). This can be visualized as a TIN. For more information, see Displaying terrain datasets in ArcGIS.