DEM LAYER
Hoodsport DEM Background There are two sources of elevation data available for the Hoodsport planning area: United States Geological Survey (USGS) and Department of Natural Resources (DNR). The USGS elevation data is a dem created from the USGS 7.5 minute quad maps (1:24000 scale). Luke, our GIS assistant, converted the USGS dem to a lattice (GRID dem) and then created a USGS contour coverage from it with the latticecontour arc command. The extent of the coverage includes almost 6 Townships and the watersheds of all the streams crossing though the Hoodsport planning area. The DNR elevation data is of a higher resolution than the USGS data but covers a lesser extent. The DNR data is a contour line coverage created using a 1:4800 scale set of aerial photos. The extent of this coverage includes all of the Hoodsport planning area that falls within T24NR03W. A digital elevation model (DEM) was created from the contour line coverage in ArcInfo(GRID) using the command topogrid. Figure 1 is an image showing the extent of the USGS dem and the DNR contour coverage with the project planning area boundary and the Township boundary superimposed.
Figure 1. Image showing the extent of the USGS dem, DNR contour coverage and Hoodsport planning area. Although the process of creating a DEM from a contour coverage is fairly straightforward and is described in detail in Arc help, we did run into a few difficulties. In the next section, I describe the problems we encountered and how they were resolved.
Procedure The DNR contour coverage for the state of Washington is stored as rectangular tiles of auto-cad line-coverages in a large statewide database. The tiles correspond to the public land survey system of rectangular townships (36-square-miles) subdivided into 36 square mile rectangular sections. The individual tiles of data are downloaded, imported into Arc/Info, and then appended using the arcinfo command 'map join'. It was assumed that all the data in the DNR database was in the same projection coordinates (stateplane, south zone), but in fact some of the tiles were in the stateplane north zone coordinate system. This caused some problems as is apparent in the image below.
Figure 2. Error in projection of contour line 'tiles'. Once the error was noticed, the tiles in north-zone coordinates were transformed into south-zone coordinates to match the rest of the tiles. Figure 3 Contour line tiles re-projected to south zone coordinate system. Unfortunately, the two blocks of contour lines overlapped and were not edgemapped. This complicated the creation of the dem. A dem can only be produced by a single contour coverage. Therefore, the two contour blocks needed to be trimmed and joined to each other at the boundary. This must be done by hand and is a relatively time-consuming process. To get a useable dem without taking the time to hand edit the two coverages, a separate dem was created for each of the two blocks and then the two dem(s) were combined using the mosaic GRID function. The mosaic GRID function creates one grid from two or more grids and makes a smooth transition over the overlapping areas (ARC help). The dem displayed as a hillshade in the image below was the result of creating a separate dem for each block of contour lines with the topogrid ARC command and then joining then with the mosaic GRID function.
Figure 4. Dem created with the topogrid ARC command and the mosaic GRID function. The problem with this dem is that the fuzzy areas around the edges are not NODATA cells. They contain interpolated elevation values. Unless a mask is set, GRID creates a rectangular analysis window that contains the extent of the input grid. This works well if the input grid is rectangular but may cause problems with grids that are not. Neither of the two DNR contour blocks were rectangular. The boundary topogrid subcommand allows the user to specify a polygon coverage to represent the outer boundary of the output dem. If a boundary polygon is specified, the cells outside are NODATA. However, in this case no boundary polygon was specified. To correct the problem of 'fuzzy edges' without having to re-create and re-merge the two dems, a boundary polygon was digitized (in Arcview) that followed (roughly) the inside edge of the extent of both contour coverages (see figure 5.)
Figure 5. Digitized boundary polygon. This arcview shapefile was then converted to a grid (option under the Arcview theme menu) and set as the mask grid in GRID with the setmask command. With the mask on, a new dnr_dem was created (called mask_dem) with the grid expression: mask_dem = dnr_dem. The new dem grid is a replicate of the original DNR dem, but it is clipped to the extent of the mask grid. Below in figure 6 is an image of the new mask_dem displayed as a hillshade. As you can see, the fuzzy areas have been replaced with NODATA.
Figure 6. Mask_dem displayed as a hillshade. My first intent was to combine the high-resolution DNR dem with the lower-resolution USGS dem in order to enlarge the extent of our analysis to include the watershed boundaries beyond the planning area without sacrificing the higher resolution of the dnr data. Phil, a GIS instructor, discouraged me in this. He refers to this type of combined data set as "mongrelized". These mongrelized data sets are a problem because once the data sets are combined, the boundary between the precise and less-precise data is erased. It is difficult to specify the accuracy of a mongrelized data set or how much confidence should be placed in the resulting analyses. Not knowing the source of your GIS data or its accuracy is a problem if important decisions must be based on analysis results.
|
