Available with Spatial Analyst license.
The Topo to Raster tool is an interpolation method specifically designed for the creation of hydrologically correct digital elevation models (DEMs). It is based on the ANUDEM program developed by Michael Hutchinson (1988, 1989, 1996, 2000, 2011). See Hutchinson and Dowling (1991) and ANU Fenner School of Environment and Society and Geoscience Australia (2008) for applications of ANUDEM to continent-wide DEM production. Applications of DEMs to environmental modeling are discussed in Hutchinson and Gallant (2000) and Hutchinson (2008). Further developments of ANUDEM are discussed in Hutchinson et al. (2009, 2011). The current version of ANUDEM used in ArcGIS is 5.3.
Topo to Raster interpolates elevation values for a raster while imposing constraints that ensure:
- A connected drainage structure
- Correct representation of ridges and streams from input contour data
As such, it is the only ArcGIS interpolator specifically designed to work intelligently with contour inputs.
The Topo to Raster by File tool is useful for executing the Topo to Raster tool multiple times, since it is often easier to change a single entry in the parameter file and rerun the tool than to repopulate the tool dialog box each time.
The interpolation process
The interpolation procedure has been designed to take advantage of the types of input data commonly available and the known characteristics of elevation surfaces. This method uses an iterative finite difference interpolation technique. It is optimized to have the computational efficiency of local interpolation methods, such as inverse distance weighted (IDW) interpolation, without losing the surface continuity of global interpolation methods, such as Kriging and Spline. It is essentially a discretized thin plate spline technique (Wahba, 1990) for which the roughness penalty has been modified to allow the fitted DEM to follow abrupt changes in terrain, such as streams, ridges and cliffs.
Water is the primary erosive force determining the general shape of most landscapes. For this reason, most landscapes have many hilltops (local maximums) and few sinks (local minimums), resulting in a connected drainage pattern. Topo to Raster uses this knowledge of surfaces and imposes constraints on the interpolation process that results in a connected drainage structure and correct representation of ridges and streams. This imposed drainage condition produces higher accuracy surfaces with less input data. The quantity of input data can be up to an order of magnitude less than that normally required to adequately describe a surface with digitized contours, further minimizing the expense of obtaining reliable DEMs. The global drainage condition also virtually eliminates any need for editing or postprocessing to remove spurious sinks in the generated surface.
The program acts conservatively in removing sinks and will not impose the drainage conditions in locations that would contradict the input elevation data. Such locations normally appear in the diagnostic file as sinks. Use this information to correct data errors, particularly when processing large datasets.
The drainage enforcement process
The purpose of the drainage enforcement process is to remove all sink points in the output DEM that have not been identified as sinks in the input sink feature dataset. The program assumes that all unidentified sinks are errors, since sinks are generally rare in natural landscapes (Goodchild and Mark, 1987).
The drainage enforcement algorithm attempts to clear spurious sinks by modifying the DEM, inferring drainage lines via the lowest saddle point in the drainage area surrounding each spurious sink. It does not attempt to clear real sinks as supplied by the Sink function. Since sink clearance is subject to the elevation tolerance, the program is conservative when attempting to clear spurious sinks. In other words, it does not clear spurious sinks that would contradict input elevation data by more than the value of Tolerance 1.
Drainage enforcement can also be supplemented with the incorporation of stream line data. This is useful when more accurate placement of streams is required. Stream distributaries are modeled by allowing each cell to have up to two downstream directions.
The drainage enforcement can be turned off, in which case the sink clearing process is ignored. This can be useful if you have contour data of something other than elevation (for example, temperature) for which you want to create a surface.
Use of contour data
Contours were originally the most common method for storage and presentation of elevation information. Unfortunately, this method is also the most difficult to properly utilize with general interpolation techniques. The disadvantage lies in the undersampling of information between contours, especially in areas of low relief.
At the beginning of the interpolation process, Topo to Raster uses information inherent in the contours to build an initial generalized drainage model. This is done by identifying the points of local maximum curvature in each contour. A network of curvilinear streams and ridges intersecting these points is then derived using the initial elevation grid (Hutchinson, 1988). The locations of these lines are iteratively updated as the DEM elevations are iteratively updated. This information is used to ensure proper hydrogeomorphic properties of the output DEM and may also be used to verify accuracy of the output DEM.
The contour data points are also used in the interpolation of elevation values at each cell. All contour data are read and generalized. A maximum of 100 data points are read from the contours within each cell, with the average elevation value used as the unique elevation data point for each cell intersecting the contour line data. At each DEM resolution, only one critical point is used for each cell. For this reason, having a contour density with several contours crossing output cells is redundant.
After the general morphology of the surface has been determined, contour data is also used in the interpolation of elevation values at each cell.
When the contour data is used to interpolate elevation information, all contour data is read and generalized. A maximum of 50 data points are read from these contours within each cell. At the final resolution, only one critical point is used for each cell. For this reason, having a contour density with several contours crossing output cells is redundant.
Use of lake data
Lake polygons in earlier versions of Topo to Raster were simple masks that set the elevation of each lake surface to the minimum elevation of all DEM values immediately neighboring the lake. The lake boundary algorithm has been upgraded to enable automatic determination of lake heights that are fully compatible with connecting stream lines and neighboring elevation values.
The revised lake boundary method also treats each lake boundary as a contour with unknown elevation and iteratively estimates the elevation of this contour from the cell values on the lake boundary. At the same time, the elevation of each lake boundary is made to conform to the elevations of any upstream and downstream lakes. The elevation of each lake boundary is also made to be consistent with the neighboring DEM values. Cell values immediately outside the lake are made to lie above the elevation of the lake boundary and cell values on the interior of the lake made to lie below the elevation of the lake boundary.
Lake boundaries are permitted to include islands within lakes, and lakes within islands. All DEM values that lie inside lakes, as determined by the lake boundary polygons, are set to the estimated height of the DEM on the boundary of the lake.
Use of cliff data
Cliff lines permit a complete break in continuity between neighboring cell values on each side of the data cliff lines, as they are encoded into the output raster. Cliff lines must be supplied as directed lines, with the low side of each cliff line on the left and the high side of the cliff line on the right. This permits removal of elevation data points that lie on the wrong side of the cliffs, as they are encoded onto the raster, and better placement of cliffs in relation to streamlines.
It has also been found that the minor shifts in position that are imposed on streams and cliffs as they are incorporated into the raster can lead to spurious interactions between these data. An automated method has therefore been developed to make small adjustments in the placement of both streams and cliff lines in the raster to minimize these spurious interactions.
Use of coastline data
Cells in the final output DEM that lie outside the polygons specified by this polygon feature class are set to an internally determined special value that is less than the user-specified minimum height limit. The result of this is that a complete coastal polygon can be used as input and it will automatically be clipped to the processing extent.
The program uses a multi resolution interpolation method, starting with a coarse raster and working toward the finer, user-specified resolution. At each resolution, drainage conditions are enforced, interpolation is performed, and the number of remaining sinks is recorded in the output diagnostic file.
Processing stream data
The Topo to Raster tool requires that stream network data has all arcs pointing downslope and that there are no polygons (lakes) in the network.
The stream data should be composed of single arcs in a dendritic pattern, with any parallel stream banks, lake polygons, and so on, cleaned up by interactive editing. When editing lake polygons out of the network, a single arc should be placed from the beginning to the end of the impounded area. The arc should follow the path of an historic streambed if one is known or exists. If the elevation of the lake is known, the lake polygon and its elevation can be used as a Contour input.
Creating and mosaicking adjacent rasters
Sometimes it's necessary to create DEMs from adjacent tiles of input data. Normally this happens when input features are derived from a map sheet series or when, due to memory limitations, the input data must be processed in several pieces.
The interpolation process uses input data from surrounding areas to define the morphology and drainage of the surface and interpolate output values. However, the cell values at the edges of any output DEM are not as reliable as in the central area because they are interpolated with one-half as much information.
To make the most accurate predictions at the edges of the area of interest, the extent of the input datasets should be greater than the area of interest. The Margin in cells parameter provides a method for trimming the edges of output DEMs based on a user-specified distance. The edges of overlapping areas should be at least 20 cells wide.
There should be some overlap of input data into the adjacent areas when multiple output DEMs are to be combined into a single raster. Without this overlap, the edges of merged DEMs may not be smooth. The extents of the input datasets from each of the interpolations should have an even larger area than if only an interpolation for a single interpolation were to be done, so as to ensure that the edges can be predicted as accurately as possible.
When the DEMs have been created, they can best be combined using the geoprocessing Mosaic tool with the Blend or Mean options. This function provides options for handling overlapping areas to smooth the transition between datasets.
Every created surface should be evaluated to ensure that the data and parameters supplied to the program resulted in a realistic representation of the surface. There are many ways to evaluate the quality of an output surface, depending on the type of input available to create the surface.
The most common evaluation is to create contours from the new surface with the Contour tool and compare them to the input contour data. It is best to create these new contours at one-half the original contour interval to examine the results between contours. Drawing the original contours and the newly created contours on top of one another can help identify interpolation errors.
Another method of visual comparison is to compare the optional output drainage cover with known streams and ridges. The drainage feature class contains the streams and ridges that were generated by the program during the drainage enforcement process. These streams and ridges should coincide with known streams and ridges in the area. If a stream feature class was used as input, the output streams should almost perfectly overlay the input streams, although they may be slightly more generalized.
A common method for evaluating the quality of a generated surface is to withhold a percentage of the input data from the interpolation process. After generating the surface, the height of these known points can be subtracted from the generated surface to examine how closely the new surface represents the true surface. These differences can be used to calculate a measure of error for the surface, such as the root mean squared (RMS) error.
Topo to Raster has a comprehensive set of procedures for assessing the quality of the fitted DEM, for optimizing DEM resolution, and for detecting errors in the input data.
The optional Output diagnostic file can be used to evaluate how effectively the tolerance settings are clearing sinks in the input data. Decreasing the values of the tolerances can make the program behave more conservatively at clearing sinks.
The Output remaining sink point feature class contains the locations of all remaining spurious sinks. It should be inspected together with the output stream polyline features to check for errors in all input topographic data.
The Output residual point feature class contains the locations of all large elevation data residuals as scaled by the local discretisation error. Large scaled residuals indicate conflicts between input elevation data and stream line data. These may also be associated with poor automatic drainage enforcements. These conflicts can be remedied by providing additional streamline and/or point elevation data after first checking and correcting errors in existing input data. Large unscaled residuals usually indicate input elevation errors.
The Output contour error point feature class contains the locations of points on input contours with significantly biased residuals from the fitted DEM. An ErrorValue of 1 most often indicates the location of points where contours with different elevations are connected, a sure indicator of a contour label error.
The Output stream and cliff error point feature class is an important indicator of stream line and cliff line data quality, particularly of stream direction errors and cliff direction errors, and it should always be inspected.
The feature class has the following codes:
1. True circuit in data streamline network.
2. Circuit in stream network as encoded on the out raster.
3. Circuit in stream network via connecting lakes.
4. Distributaries point.
5. Stream over a cliff (waterfall).
6. Points indicating multiple stream outflows from lakes.
7. Code not used.
8. Points beside cliffs with heights inconsistent with cliff direction.
9. Code not used.
10. Circular distributary removed.
11. Distributary with no inflowing stream.
12. Rasterized distributary in output cell different to where the data stream line distributary occurs.
13. Error processing side conditions—an indicator of very complex streamline data.
The Output stream polyline feature class contains all drainage constraints imposed by Topo to Raster as determined from input stream line data, stream lines and ridge lines inferred from contour data and stream lines obtained by automatic drainage enforcement. These can be inspected to check for location errors in input stream lines and to verify appropriate concordance with constraints associated with input stream lines and automated drainage enforcements. Each type of derived stream line is given a different code. Stream lines that cross cliff lines are indicated by short stream lines of length, one cell with a separate code. The feature class also includes lines flagging large source elevation data clearances via connecting stream lines and lakes that exceed the second elevation tolerance. These can be a useful indicator of source elevation data errors.
The polyline features are coded as follows:
1. Input stream line not over cliff.
2. Input stream line over cliff (waterfall).
3. Drainage enforcement clearing a spurious sink.
4. Stream line determined from contour corner.
5. Ridge line determined from contour corner.
6. Code not used.
7. Data stream line side conditions.
8. Code not used.
9. Line indicating large elevation data clearance.
There is a minor bias in the interpolation algorithm that causes input contours to have a stronger effect on the output surface at the contour. This bias can result in a slight flattening of the output surface as it crosses the contour. This may result in misleading results when calculating the profile curvature of the output surface but is otherwise not noticeable.
Likely causes of problems with Topo to Raster
If you encounter any problems when running Topo to Raster, check the following points for explanations and solutions for the most commonly encountered issues.
- There are insufficient system resources available. The algorithms used in Topo to Raster hold as much information as possible in memory during processing. This allows point, contour, sink, stream, and lake data to be accessed simultaneously. To facilitate processing of large datasets, it is recommended that unnecessary applications be closed before running the tool to free up physical RAM. It is also important to have sufficient amounts of system swap space on disk.
- The contour or point input may be too dense for the output cell size specified. If one output cell covers several input contours or points, the algorithm may not be able to ascertain a value for that cell. To resolve this, try any of the following:
- Decrease the cell size, then resample back to the larger cell size after Topo to Raster.
- Rasterize smaller sections of the input data using the Output extent and Margin in cells. Assemble the resulting component rasters with the Mosaic tool.
- Clip the input data into overlapping sections, and run Topo to Raster separately on each section. Assemble the resulting component rasters with the Mosaic tool.
- The application of a surface interpolator may not be consistent with the input dataset. For example, if there is a sinks input with more points than there would be cells in the output raster, the tool will fail. Densely sampled data sources, such as lidar data, may have similar problems. Using the Do not enforce option may help in this case, but a proper understanding of how the interpolator works is important to prevent misapplication.
ANU Fenner School of Environment and Society and Geoscience Australia, 2008. GEODATA 9 Second DEM and D8 Digital Elevation Model and Flow Direction Grid, User Guide. Geoscience Australia, 43 pp. See: http://www.ga.gov.au/image_cache/GA11644.pdf.
Goodchild, M. F., and D. M. Mark. 1987. The fractal nature of geographic phenomena. Annals of Association of American Geographers. 77 (2): 265–278.
Hutchinson, M. F. 1988. Calculation of hydrologically sound digital elevation models. Paper presented at Third International Symposium on Spatial Data Handling at Sydney, Australia.
Hutchinson, M. F. 1989. A new procedure for gridding elevation and stream line data with automatic removal of spurious pits. Journal of Hydrology, 106: 211–232.
Hutchinson, M. F., and T. I. Dowling. 1991. A continental hydrological assessment of a new grid-based digital elevation model of Australia. Hydrological Processes 5: 45–58.
Hutchinson, M. F. 1993. Development of a continent-wide DEM with applications to terrain and climate analysis. In Environmental Modeling with GIS, ed. M. F. Goodchild et al., 392–399. New York: Oxford University Press.
Hutchinson, M. F. 1996. A locally adaptive approach to the interpolation of digital elevation models. In Proceedings, Third International Conference/Workshop on Integrating GIS and Environmental Modeling. Santa Barbara, CA: National Center for Geographic Information and Analysis. See: http://www.ncgia.ucsb.edu/conf/SANTA_FE_CD-ROM/sf_papers/hutchinson_michael_dem/local.html.
Hutchinson, M.F. 2000. Optimising the degree of data smoothing for locally adaptive finite element bivariate smoothing splines. ANZIAM Journal 42(E): C774–C796.
Hutchinson, M.F. and Gallant, J.C. 2000. Digital elevation models and representation of terrain shape. In: J.P. Wilson and J.C. Gallant (eds) Terrain Analysis. Wiley, New York, pp. 29–50.
Hutchinson, M.F. 2008. Adding the Z-dimension. In: J.P. Wilson and A.S. Fotheringham (eds), Handbook of Geographic Information Science, Blackwell, pp 144–168.
Hutchinson, M.F., Stein, J.A., Stein, J.L. and Xu, T. 2009. Locally adaptive gridding of noisy high resolution topographic data. In Anderssen, R.S., R.D. Braddock and L.T.H. Newham (eds) 18th World IMACS Congress. Modelling and Simulation Society of Australia and New Zealand and International Association for Mathematics and Computers in Simulation, July 2009, pp. 2493–2499. See: http://www.mssanz.org.au/modsim09/F13/hutchinson.pdf.
Hutchinson, M.F., Xu, T. and Stein, J.A. 2011. Recent Progress in the ANUDEM Elevation Gridding Procedure. In: Geomorphometry 2011, edited by T. Hengel, I.S. Evans, J.P. Wilson and M. Gould, pp. 19–22. Redlands, California, USA. See: http://geomorphometry.org/HutchinsonXu2011.
Wahba, G. 1990. Spline models for Observational data. Paper presented at CBMS-NSF Regional Conference Series in Applied Mathematics. Philadelphia: Soc. Ind. Appl. Maths.