Building a DTM in ArcMap and parameters used
Let’s discuss building a DEM from digitized elevation contours of the topographic map using ArcGIS.
Our task
We obtained digitized elevation contours of topographic plans of 1: 1000 scale covering Kharkiv Lesopark (“forest park”) and some surrounding areas. We were eager to create a digital elevation model based on these materials. During the task we got familiar with available methods and tools of DEM creation, selected and learned some of them. This experience is partly described in the article.
Source contours
Why?
Let’s digress a bit and discuss why we wanted to have a DEM and for what territory we made it.
The answer to the first part can be found, for example, in posts about DEM at our blog: 1, 2, 3.
In our case, we wanted to benefit from the topo maps we obtained and practise in DEM creation, to create hillshaded terrain and to use it on the map.
The territory for processing is fairly small, about 81 km2, and measuring up to 9×15 km at its widest, but it has very irregular shape. It covers Kharkiv forest park, Sarzhyn Yar park and some surrounding areas.
Extent overlaid on the OSM
Our area of interest has weakly rugged flat terrain, the absolute elevation excess reaches about 110 meters, the deepest valleys – up to 80 meters. Most of the territory is occupied by flat watershed plains. If we consider, for example, DEMs with global coverage (STRM, ASTER GDEM), they do not provide sufficient detail to be used in that territory and to be viewed at maximum zoom levels (18-19, 1:2300 ~ 1:1130). We just needed to display hillshaded terrain as an integral part of the map even at the largest zoom levels to achieve the effect user’s immersing in the map even in this flat area. Input data with a vertical dissection of 2 m allowed us to build a detailed model.
Choosing the Tool
Actually, we had to choose between ArcGIS and open applications – QGIS/GRASS/SAGA. Although we desired to cope with the task by only using open software, unfortunately, we failed to do so. The choice was made in favor of ArcGIS, because free/open programs, despite their full functionality, are quite complex for beginners. Reference materials are often incomplete (though I have to note that GRASS GIS has a nice page dedicated exclusively to the creation of DTM from contour lines), sometimes it happens that the description of a module in GRASS-wiki very sparingly describes the purpose of the program and covers only part of the parameters, leaving the rest for people with experience in programming / academic backgrounds or with a developed intuition.
Therefore, with the ArcMap Advanced licence available, it was decided to use that program, which in turn has a well-structured help information. Also, availability of a special Topo to Raster tool contributed to the choice of ArcGIS. According to developers, it is designed specifically to work with topographical input data to create hydrologically correct elevation models. Seems to be just what we need!
Topo to Raster Comparison with other instruments
So the very first factors to play in favor of Topo to Raster were the user-friendly interface and detailed documentation. ESRI provides two help pages for your module: A general description of the parameters and “how it works“.
Apart from the documentation, a vast variety of possible input data – as compared to other tools – benefits the choice of Topo to Raster. In fact, in our case it was only contours and a boundary of the processing area. The latter can be set using GRASS tools as well, but is not that simple. And here we simply choose a freeform extent shape-file and specify that this is the limit of the processing area – and Topo to Raster does the rest. Incidentally, this is a very important thing when building DEM. If you create DTM for any specific real-world objects (such as our Forest Park), quite often the shape won’t be rectangular. An option to specify the extent of irregular shape often means a significant saving of computing time. Other interpolation tools in ArcMap, by the way, lack this excellent option of setting an arbitrary extent as input. Well, after a little tinkering, you probably can specify the extent in this Environment settings, but you’ll might agree that Topo to Raster makes it easier.
Our ROI outline
To sum up, it should be noted that apart from the already mentioned contours and region of interest boundaries, Topo to Raster takes point elevation, streams, lakes, coastlines, cliffs, and areas of exclusion as input. In our peculiar case we just had contours and the extent, but the material for adding other elements of terrain – through digitization – remains at our fingertips…
The difficulties of creating DEM from contours
When it may start to seem that this post will be all about praising the tool that has been mentioned for 7 times already, it is worth saying why we got so obsessed with it. Actually, we can go straightforward: because we had to create DEM from contours.
Let’s discuss it a little bit.
Although contours, perhaps, are the most familiar way of terrain representation for reader’s understanding, which is familiar to most of us from topographic maps and intuitive shading on physical maps, still it is not optimal for computer processing. This idea is not my own, it is repeated many times on the internet; that’s at least on the mentioned page on principles of Topo to Raster operation in the section on the use of contours. Let’s try to develop this thought.
The thing is that DEM creation is a process of interpolation. And interpolation, you know, it likes it more to have inputs of a uniform spatial distribution (ideally – a regular network structure). Judge for yourself: given some regular grid, with just a simple linear function we can derive intermediate values, then add the desired smoothing – and voila! we have a nice smooth surface. Instead, contours are a type of input with very uneven spatial distribution. The problem, as stated on the mentioned page, is the lack of data between contours. Roughly speaking, we have a line that represents a set of points which are, pardon the tautology, along a certain line …and between them – nothing, emptiness! Interpolation algorithm, whichever we would pick (one can start reading about them here) tend to think that input values have great power, great weight in the calculations and they have to – they definitely will – be reflected in the final result.
What’s this about? We want to say that DEMs created from contour lines will unfortunately display these lines or will have some other kind of distortions, or “artifacts.” One can have a good look at different kinds of DEM artifacts on the already mentioned GRASS-wiki page. Yes, unfortunately, Topo to Raster also creates a model that is not devoid of artifacts, but by far this terrain model looks very realistic and correct. Artifacts of our model are “ribs” that show where input contours had been.
Artefacts with contours overlaid
Also, sometimes there are non-systematic artifacts caused by some distortions in the input data.
Casual drains
More specific / suitable for interpolation algorithms than contours
… are points! In an ideal world, we would carry out a LiDAR survey and go on with point clouds processing… But even with no such resources we should pay attention to point datasets. Essentially, because it is points that most of the conventional interpolation algorithms work with. For IDW, Kriging, Spline and others, ESRI’s help stated it is “input point datasets”. And GRASS-wiki page informs us that many of the interpolation algorithms, described there, require input vector contours to be rasterized. Thus we get the raster cells which definitely are not tied linear objects.
So, can we get point data from topographic maps in order to use a less specific tool when we don’t have a licence to use Topo to Raster – the answer is Yes.
As this Japanese manual says, we can only digitize peaks, depressions and the inflection points of elevation contours. It is also possible to use, for example, GPS-measurements of point elevation. …or wait until ordering a LiDAR survey becomes as easy as ordering sushi delivery. Using point data we can pick less specific interpolation methods, which can produce quite a rough model though, if they are not designed specifically for topographic information.
But the point elevation data is suitable for our Topo to Raster, too. As noted certain elevation points on the topographic map can also be selectively digitized and set as input. But you can also, and this, perhaps, may seem a bit strange, take our contours and convert them to points! This idea may evolve after reading tools review on GRASS-wiki, where such an operation is required for many of the tools. Lines can be converted to points, for example, using QGIS tool Extract Nodes (Vector-> Geometry Tools->Extract Nodes).
Tool illustration
Next we offer these contours converted to points to Topo to Raster… and get the result that is slightly different from the processing of contour lines. In general, this is the same DEM, which has almost the same heights (height values for each specific cell may be slightly different) and all the same forms of relief, but it has different artifacts.
Artefacts of point model
This DEM displays planes better, as they don’t have such obvious “ribs”; softer and generally in somewhat less detail it shows steep sections, and instead of “ribs” it has “drops” which sometimes create a sort of “orange peel”. Obviously, the “drops” and their clusters are a consequence of uneven data – same as in the case with lines. Yet, in our opinion, such an experiment makes sense, as we have seen that in some aspects this model has its advantages.
Practical work with Topo to Raster
Let’s examine in detail the practical work with Topo to Raster: input data and model parameters that allowed us to build the most detailed model.
Input data with drop-down type selection
Input data have been already discussed. In addition to the contours, we can opt for the processing area extent and contours converted into points. Perhaps we could make use of digitized cliffs and lakes, but so far managed with contours only. There is greater choice regarding processing options. More detail on them below.
Parameters section
Model processing parameters
There is a variety of them:
cell_size – cell size (spatial resolution of the resulting model),
extent – extent (if not file with area of interest is given),
margin – margins (distance to interpolate beyond the input extent),
minimum_z_value – a user-defined minimum elevation value,
maximum_z_value – a user-defined maximum elevation value,
maximum_iterations – a maximum number of iterations (a maximum number of times instrument passes over the interpolation surface) and other…
13 parameters in total, all are available for studying on the aforementioned tool’s page. It has to be mentioned that almost all of the parameters are optional – apart from the input data. Still they need user’s attention, as, for example, by default, spatial resolution is calculated as the least of the input dataset’s height or width dimensions – in the units used in the dataset’s coordinate system – divided by 250. So you may guess how rough will be the model with no properly set cell_size parameter.
Also available are eight optional output data sets. These are mainly data sets that can be used to assess the quality of the output DEM, and a file with parameters which can be edited and re-used in further work or serve as a reminder of settings used for one or another DEM version.
Optional outputs
But let’s get back to the model creation parameters and discuss which ones were of the the greatest interest, how they were modified and influenced the output.
cell_size. Because of the relatively small size of the territory and relatively small elevation excess it seemed logical to make a very detailed model. Most attempts were performed for the spatial resolution of 1, 2, 3, 4 and 10 m. The higher the resolution, the more details thr DEM contains, but at the same time – more visible distortion. Also, cell size, of course, affects the speed of DEM creation and used memory volume (Topo to Raster is a memory-intensive process). DEM with a resolution of ~3 m seemed to be optimal. Later it was stretched to 1.5 m resolution with no significant loss of quality (using Resample tool, Bilinear method).
Different resolutions
Units of measurement are important when setting the cell_size parameter. If we use the geographic coordinate system (e.g., WGS 84), the cell size value is calculated in degrees, and if the projected coordinate system (e.g., UTM Zone 37N) – in meters. So if working with input data in WGS 84, we set the resolution of 1, we get the cell size of 1°, which, I venture to suggest, in the case of our territory will look like… probably one pixel. To convert from degrees to meters, unit conversion factor must be used. It can be taken from the below table (approximate):
Units conversion factor
| From | To | ||
| Feet | Meters | Degrees | |
| Feet | 1 | 0.3048 | 0.000003 |
| Meters | 3.28084 | 1 | 0.00001 |
(see here)
…or calculated more precisely using a formula for WGS84.
Discretisation error factor (discrete_error_factor). This parameter is used to adjust the smoothing effect. Interest in it was caused by expectations that higher values will overcome ribbing in the model. Some smoothing could actually be observed, but high values of the parameter resulted in the generation of strange “bulges”. Eventually, the values of 1 (default) and 2 proved to be the best for our model.
Illustration of bulges
Primary type of input data (data_type). This parameter appeared to be interesting because when processing contours converted to points with this parameter left with its default value of CONTOUR, then the output looks somewhat better than when seemingly logical SPOT was used.
Contour vs. Spot
The remaining parameters either didn’t make an obvious effect on the output, or were too difficult to understand what kind of impact they actually have.
So, here I tried to talk about the issues faced when creating a DEM using contour lines. I hope this was useful! In case I have missed anything, or there is a better way of doing things, feel free to correct me!
