The District of Columbia Digital Elevation Model (Environmental Systems Research Institute [ESRI] Grid format) represents an elevation map of the District of Columbia coastal zone created for the purposes of analyzing vulnerability to rising sea level. The domain of the data includes all of the District of Columbia, but the primary focus of the analytical approach and quality control has focused on land below the 10 foot contour. This data set has been derived from National Capital Planning Commission and District of Columbia Department of Public Works Ground Elevation Data. In addition, the analysis created a supplemental contour representing the elevation of spring high water (SHW), which is generally between 1.5 and 3 feet above NGVD29 in the District of Columbia. We defined the horizontal position of that contour using polygon tidal wetlands data from the US Fish and Wildlife Service National Wetlands Inventory (NWI). We defined the vertical position of the supplemental contour by creating a "tidal elevation surface" using the National Ocean Service's (NOS) estimated tide ranges, the NOS estimated sea level trends, the NOS published benchmark sheets and the National Geodetic Survey North American Vertical Datum Conversion Utility (VERTCON) program to convert the Mean Tide Level (MTL) relative to NAVD88 to a NGVD29. All elevation information was converted to a common vertical reference (usually NGVD29) and the DEM was generated from that input data using ESRI's interpolation algorithm TOPOGRID (within ArcGIS workstation GRID extension). We converted the absolute elevation estimates (usually NGVD29) into elevations relative to SHW using the "tidal elevation surface". For purposes of this data set, SHW is the upper boundary of tidal wetlands (including vegetated wetlands and intertidal beaches). Elevation is expressed in cm. The zip file associated with this data set should include: 1. README_DC_Elevation.doc, which provides a brief overview of the relationship between this dataset and related data 2. InterpolationMethods_MEMO.doc 3. MD_Data_Quality.jpg 4. DEM_LidarComparisonTable.doc 5. DEM_Comparison_with_DLG_11_quads.xls 6. Institute_of_Geography_DLG.xls 7. Titus_and_Wang_2008.pdf
The District of Columbia Digital Elevation Model provides a base map layer for assessing the possible influences of potential sea level rise on coast regions. We recommend against using this data to create maps with scales greater than 1:100,000, regardless of the level of vertical precision portrayed. Moreover, if the purpose of using this data is to create graphical depictions of risk with contour intervals of 50-100 cm, we recommend a considerably smaller scale unless the audience is likely to understand the limitations of the data.
Elevations relative to year 2000.
ground condition
None
Mailcode 6207J
Jue Wang, GIS Practice, ICF Consulting, Inc.
The underlying data used in the creation of this layer may contain errors or omissions. The accuracy of this data set generally corresponds to the source data used in the layer development. See "DC_Data_Quality.jpg" for an index of the source data used (that accompanied this data set in the zip file.) See the sections on Positional Accuracy for more detailed information. Additional consideration: The vertical values and their associated positions were generated using the interpolation function "TOPOGRID" within the ESRI GRID module. TOPOGRID uses input elevation data such as contours and elevation point data along with supplemental information such as stream networks, lakes (of known elevation), and bounding areas to generate a hydrologically-correct DEM. Each state DEM was generated using TOPOGRID but the specific parameters were unique to the data sets available and issues related to each state. There are known issues relating to the interpolation algorithm TOPOGRID. TOPOGRID Plateau Problem. The TOPOGRID function generates disproportionately large areas with the same value of the input contour lines, e.g., if we have 5 and 10 foot contour lines, there would be substantially more areas with values between 4 to 6 and 9 to 11, than 6 to 9 feet. At the upper tips of narrow valleys, the cell values tend to be the same as the bounding contours so the valleys become plateaus. The TOPOGRID function within the ESRI GRID module tends to calculate a trend from neighboring contour lines. As a result, TOPOGRID frequently creates areas of erroneous depressions on the plains adjacent to steep slopes, often substantially below the contours between which those depressions lay. It also creates plateaus along contours, which can be problematic because they overstate the amount of land barely above the wetlands and right at the first contour, while understating the amount of land halfway between the wetlands and the first contour. To address these problems, we processed the areas above and below the first contour separately. However, this caused another problem. In narrow valleys in the area below the first contour, the output DEM values were similar or identical to those of the bounding contour lines due to the lack of elevation information that TOPOGRID needs to calculate trend. The most problematic regions occurred where there was a stream valley below the first contour (e.g. between two parallel 5 foot contours), neither open water nor tidal wetlands along most of the length of the valley, but open water or tidal wetlands at one end of the valley (e.g. a typical non-tidal stream flowing into tidal waters). In some cases, the trend from the wetlands or open water at the mouth toward the bounding first contour would provide values even higher than that first contour farther up the valley. And in general, TOPOGRID would be more likely to assume a flat area between the contours, than to characterize it as a valley. We did not use stream data in constructing the DEM for the District of Columbia. (See comparable DEMs for Delaware, Maryland, New York and North Carolina, where stream data was available.). Evaluation of other interpolation methods. Several interpolation methods were evaluated before the TOPOGRID function was selected. Specifically, Spline, Inverse Distance Weighting (IDW), and Triangulated Irregular Network (TIN) methods were evaluated and compared to the TOPOGRID function. Statistics and graphical examples of cross sections specific to each interpolation method are presented in the accompanying "InterpolationMethods_MEMO.doc" memo included in the zip file associated with this data set.
Vertical values were rounded to nearest whole cm. See the sections on Positional Accuracy (Horizontal and Vertical).
Refer to the Titus and Wang 2008 technical report that documents this study for information on the publication date for data and procedures used in the development of this layer. See the sections on Positional Accuracy (Horizontal and Vertical) for additional information. Note that the discussions presented in the accuracy reports refer to contour intervals in multiple units (meters and feet). This was done purposefully to reflect the actual contour intervals used by USGS over the years and which vary on a quadrangle by quadrangle basis.
This elevation data set generally corresponds to that of the source data used in the layer development. See the sections on Positional Accuracy (Horizontal and Vertical) for additional information. The vertical values and their associated positions were generated using the interpolation function "TOPOGRID" within the ESRI GRID module. TOPOGRID uses input elevation data such as contours and elevation point data along with supplemental information such as stream networks, lakes (of known elevation), and bounding areas to generate a hydrologically correct DEM. Each state DEM was generated using TOPOGRID but the specific parameters were unique to the data sets available and issues related to each state. The specifics to each state DEM are described under positional accuracy section of the metadata and in process steps. There are known issues relating to the interpolation algorithm TOPOGRID. TOPOGRID Plateau Problem. The TOPOGRID function generates disproportionately large areas with the same value of the input contour lines, e.g., if we have 5 and 10 foot contour lines, there would be substantially more areas with values between 4 to 6 and 9 to 11, than 6 to 9 feet. At the upper tips of narrow valleys, the cell values tend to be the same as the bounding contours so the valleys become plateaus. The TOPOGRID function within the ESRI GRID module tends to calculate a trend from neighboring contour lines. As a result, TOPOGRID frequently creates areas of erroneous depressions on the plains adjacent to steep slopes, often substantially below the contours between which those depressions lie. It also creates plateaus along contours, which can be problematic because they overstate the amount of land barely above the wetlands and right at the first contour, while understating the amount of land halfway between the wetlands and the first contour. To address these problems, we processed the areas above and below the first contour separately. However, this caused another problem. In narrow valleys in the area below the first contour, the output DEM values were similar or identical to those of the bounding contour lines due to the lack of elevation information that TOPOGRID needs to calculate trend. The most problematic regions occurred where there was a stream valley below the first contour (e.g. between two parallel 5 foot contours), no open water or tidal wetlands along most of the length of the valley, but open water or tidal wetlands at one end of the valley (e.g. a typical nontidal stream flowing into tidal waters). In some cases, the trend from the wetlands or open water at the mouth toward the bounding first contour, would provide values even higher than that first contour farther up the valley. And in general, TOPOGRID would be more likely to assume a flat area between the contours, than to characterize it as a valley. Omissions: Neither stream networks nor lake features were used as inputs into the TOPOGRID function in creation of this data set. The absence of a hydrologic network explains a significant proportion of the greatest errors in the vicinity of non-tidal streams at elevations below the first contour. TOPOGRID infers stream valleys above the first contour by the pattern of a valley without the stream data. The decision to split the data into land below and above the first contour (discussed in process step #4 "Interpolation of Digital Elevation Model ") had the effect of increasing the potential errors resulting from the absence of stream data. However, the magnitude of any errors induced by this problem was limited by the "first contour truncating" (also discussed in process step #4). The net effect was to put back some of the plateaus eliminated by dividing the data, but not all of those plateaus. Moreover, errors introduced by the omission of non-tidal streams were absent in areas where tidal streams or tidal wetlands were present, which served the same function. Other Issues: In addition to excluding streams, the decision to process 3 elevation areas separately within TOPOGRID (as described in the process step #4 - "Interpolation of Digital Elevation Model") and then combine them into a single DEM removes the algorithm from its theoretical underpinning, because it separates each elevation zone from the context of the overall environment that TOPOGRID uses to generate a hydrologically-correct DEM. Because the objective of this DEM is to estimate elevations of lands close to sea level, rather than characterize drainage correctly, the ad hoc response to the TOPOGRID plateau problem is not as unreasonable as would have been the case were this data to be used for analyzing hydrology. Nevertheless, the inclusion of an accurate stream network, modification of the tolerance values and other parameters within TOPOGRID, and inclusion of additional vertical data in areas of known errors (determined through the use of diagnostic outputs within the TOPOGRID function), probably could have substantially diminished the plateau problem in the vicinity of the first topographic contour. Because the plateau problem around the edge of tidal wetlands was often caused largely by the relative complexity of the wetland supplemental contour compared with other contours, and because the tidal wetlands and open water data which we used in effect provide the stream data, the case for dividing the data as we did is probably greater along the wetland boundary than along the first contour. Also see the sections on Positional Accuracy (Horizontal and Vertical) and process steps.
The source data generally were 1:1000 scale. Therefore our use of 30 meter cells deteriorated the horizontal accuracy. Assuming that 90% of well defined points are within 30 meters of the indicated location would imply a scale of 1:60,000 under National Map Accuracy Standards. (That assumption may be conservative because 100% of the points in a 30 meter cell are less than 21.2 meters of the center of the cell. If the input map has 1:24,000 scale (well defined points within 12.2 meters) and errors are random, then more than 90% of the points will be within 24.5 meters of the indicated location, which would imply a scale of 1:50,000.) However, our interpolation program may further deteriorate the horizontal accuracy. Under some circumstances, the horizontal error appears to be as great as the width of a cell. Given that the diagonal in this case would be 42.4 m, if errors are random, then the scale might be as poor as 1:86,000 in areas where those 1-cell errors are common . Neither stream networks nor lake features were used as inputs into the TOPOGRID function in creation of this data set for reasons discussed in the completeness report. The addition of a hydrologic network would increase the accuracy of the resulting DEM.
In the event the horizontal error is as great as the width of a cell, the diagonal would be 42.4 m.
The vertical accuracy of this data set generally corresponds to that of the source data (described below) used in the layer development, plus errors induced through the various processing steps. The most important processing errors probably concern the procedures used to interpolate between contours, which do not necessarily correspond to the actual geometry of the land surfaces. Therefore, points that are near a contour have greater accuracy than points that are farther away from a contour. In order to assess the vertical accuracy of DEMs generated by ICF Consulting, Russ Jones of Stratus Consulting Inc. compared DEMs with LIDAR data in two areas: 1) an area south of Rock Hall along the eastern shore of Maryland, and 2) portions of North Carolina. Table 1 within DEM_LidarComparisonTable.doc summarizes the comparison. The analysis suggests a Root Mean Square (RMS) discrepancy between LIDAR and this DEM approximately one-half of the input contour interval in cases where the contour interval was 1 meter, 5 feet, or 2 meters. In areas where the USGS contour interval was 20 feet and we used MD DNR data for supplemental contours, the mean discrepancy (LIDAR-DEM) was -2.4 feet with a RMS discrepancy of 6 feet for DEM observations less than 10 feet. The error was much less (mean -1.1 feet, RMS 3.9 feet) for DEM values between 10 and 20 feet NGVD29. Most of the errors appear to be centered in Caroline County, where the Maryland DNR data incorrectly showed a large area below 5 feet NGVD29. If the LIDAR comparison is applicable to the District of Columbia, one would expect an RMS error of approximately 50 cm (i.e. similar to the areas in the Eastern Shore of Maryland where the DEM also relied on input DLG's with a one-meter contour interval). Jones also provided histograms showing the relationship between input contour intervals and the DEM values, for 11 USGS 7.5' topographical quadrangles in the study area from New York to North Carolina, none of which were in the District of Columbia. The technical paper by Titus and Wang (2008, listed in the citation section above) analyzes the results of that comparison. Note that this comparison was conducted on the initial DEM generated with TOPOGRID. As a result of this analysis, the minimum and maximum elevation limits were constrained to ensure that the resulting elevations were in accordance with the input data. (See "First-contour truncating" in the process step on interpolation of Digital Elevation Model). Two quads in Maryland.were particularly problematic: Broomes and South River. For South River, the DEM underestimates the amount of land below 5 ft by 50%. However, it is within 5% and 1% for the areas between 5- 10 and 10-15 ft, respectively. This error appears to have resulted because the land is sufficiently steep that particular cells will have more than one contour crossing them. The DEM assigns an average elevation to the cell. Assuming that the contours cross the centers of cells randomly, one would normally expect that the amount of higher and lower ground being "averaged in" would approximately offset each other, so that the DEM should find the same amount of land within a given elevation range as the input DLG's. Indeed, this appears to be the case for land at 10-15 ft. For land below 5 ft, however, there is higher ground but no lower ground to be "averaged in." Therefore, an upward bias is created for the lowest areas. Such an upward bias in the lowest contour range could have been avoided with an algorithm that calculated elevations for points rather than cells or using a much smaller cell size. Doing so, however, would have increased the costs of this study several fold. The net impact was that the DEM, in effect, estimated the 5-ft contour to be approximately 7.3 ft above the vertical datum for South River. The Broomes quad had a similar upward bias, effectively treating the 5-ft contour as a 5.8-ft contour. The experience with those two quads in Maryland should serve as a caution that in the District of Columbia, our results may be less accurate in areas with slopes steep enough to have two contours within 30 meters (e.g. slopes greater than 6% with 5-ft contours, or 12% with 10ft contours), especially in the area above the lowest contour. However, the availability of a one-meter contour interval substantially mitigates this concern. The results of the "11 quadrangle" analysis are shown in DEM_Comparison_with_DLG_11_quads.xls., which is included in the zip file distributed with this dataset.
See vertical accuracy report.
Elevation contours. Source contours are 1 meter interval.
Spatial coordinates and elevations of MTL relative to mean lower low water (MLLW), the elevation of MLLW relative to several benchmarks nearby, and the elevations of these benchmarks above NAVD88 for 1 tide gauge in the District of Columbia and 1 nearby tide gauge in Maryland.
Horizontal location, and spring high tide ranges for more than 9 tide gauges in and around the District of Columbia.
Horizontal location of upper and lower limits of tidal wetlands. See README_DC_Elevation.doc (distributed in the zip file with this data set), for directions on how to download the Coastal Wetlands Data . See also J.G. Titus and J. Wang, 2008. "Maps of Lands Close to Sea Level along the Middle Atlantic Coast of the United States: An Elevation Data Set to Use While Waiting for LIDAR." Section 1.1 in: Background Documents Supporting Climate Change Science Program Synthesis and Assessment Product 4.1, J.G. Titus and E.M. Strange (eds.). EPA 430R07004. U.S. EPA, Washington, DC.
Spatial location and estimates of the rate of sea level rise.
Spatial data and attributes. Contours digitized from USGS 7.5 minute Digital Raster Graphics (DRGs). See Institute_of_Geography_DLG.doc, included in the zip file with which this data is distributed, for a list of the 7.5-minute quads where we used the Institute of Geography DLG's.
Process of Input Elevation Data Because there was no vertical datum information associated with the National Capital Planning Commission and District of Columbia Department of Public Works Rooftop Elevation and Ground Elevation dataset, we plotted the data against USGS contour lines and determined that vertical datum to be NAVD88. We projected the dataset into Albers projection and converted the elevation unit from meters to feet.
9300 Lee Highway
Process of Tidal Record: Calculating the Elevation of Spring High Water Supplemental Contour 1) Creation of Mean Tide Level Surface. National Oceanic Service (NOS) tide observation data, i.e., the latitudes and longitudes, the elevations of mean tide level (MTL) above mean lower low water (MLLW), the elevations of MLLW relative to several benchmarks, and the elevations above NAVD88 of these benchmarks of 2 tide gages in the District of Columbia and nearby Maryland were downloaded from the NOS website. The elevations of mean tide level above NAVD88 were calculated and then converted to above NGVD29 using USGS VERTCON program. A point coverage was then created with this data and projected into Albers projection. Using the point coverage as a reference, artificial contour lines were created with consideration of shorelines via heads-up digitizing and then used to interpolate the mean tide level surface using a Triangular Irregular Network (TIN). As the tidal epoch used for the MTL data was 1960-1978, a separate sea level rise rate surface was created by interpolating actual sea level rise data (trend) from the Proudman Oceanographic Laboratory website and was used to adjust the mean tide level to years corresponding to other data sets, such as NWI data, so that the wetland boundary would represent spring high tide for the year the map imagery was taken. 2) Creation of Spring Tide Range Surface. From Table 2 of "Tide Tables 2000, High and Low Water Predictions, East Coast of North and South America including Greenland", the latitudes, longitudes and spring high tide ranges of more than 150 tide gages were obtained and used to create a point coverage. Using the point coverage as a reference, artificial contour lines were created with consideration of shorelines and then used to interpolate the spring high tide range surface with TIN method. 3) Creation of a Spring High Water Level Surface. A spring high water level surface was created by adding half of spring tide range onto mean tide level surface.
Processing Tidal Wetlands: Calculating the Horizontal Position of Spring High Water Supplemental Contour 1. We identified the upper limit of tidal wetland by extracting the boundaries between tidal polygons (consisting of tidal wetland and tidal open water) and non-tidal polygons (consisting of dry land, non-tidal wetland, and non-tidal open water). 2) We used the upper and lower limits of tidal wetlands to generate supplemental contours. We assigned these contours elevations derived from spring high tide level and mean tide level surface grids respectively. The upper wetland boundary was used as a supplemental contour. The lower boundary was used for reporting the area of wetlands but not for elevations, because the project manager decided not to report wetland elevations. See also the metadata accompanying the "Coastal Wetlands Data: District of Columbia" polygon dataset
Interpolation of Digital Elevation Model
1) The study area was divided into lowland and upland.
"Tidal Wetlands" represents the tidal wetlands as classified from the wetland layer.
Lowland represents the area under the 1 meter contour
and upland represents area from 1 meter contour line up
to the political boundary of the District of Columbia.
We are not making the tidal wetland interpolations
available in this dataset due to the lack of a
theoretical justification for believing that
interpolation to have any information content. (At
best, the wetland elevation interpolations might be
used for graphical representations of the impact of sea
level rise.) We will retain a companion dataset with
elevations stored as floating point double precision,
which may be made available for the sole purpose of
evaluating any graphical representations that use
wetland elevations. We provide a gridded (and a
polygon) wetland dataset so that the user can
distinguish tidal wetlands from open water for cells
with no data..
2) The DEMs were interpolated with a predetermined
cellsize of 30 meters for the lowland and upland areas
using contour lines described in Process Step 1
("Process of Input Elevation Data") and supplemental
contours explained in process step 3. A common starting
coordinate was set for all three DEM interpolation
processes to ensure alignment of the separate layers
after processing. The minimum and maximum limits were
set for each process according to the input elevation
data to ensure the resulting elevations were in
accordance with the input data. See "first contour
truncating" (#4) below. The iteration was
set to 40, the horizontal standard error tolerance was
set to 2 to minimize the depression caused by
inappropriate tend calculation, and the drainage
enforcement option was turned on to remove isolated
depressions.
The following represents the options used in TOPOGRID:
topogrid dem_up_ft 30
contour dlg_mtr_alb elev_feet
xyzlimits 1610096.5 # 1907771 # 3.2809
boundary topo_bnd_up
iterations 40
tolerances # 2
enforce on
end
3) The interpolated DEMs were displayed against input
elevation data and visually checked. These visual
checks showed gross errors, but not necessarily
errors in which the amount of low land is over- or
underestimated by 10-40 percent (additionally, see Data
Quality, Positional Accuracy section). If obvious
errors such as artificial depressions occurred,
supplemental elevation lines were added by heads-up
digitizing to the input contour lines and the
interpolation was repeated.
4) First-contour truncating. As a result of the comparison
between the initial DEM and the source contours for 11
USGS quadrangles (see vertical accuracy report), we
decided to reset the DEM values to coincide with
source contours. Our general approach was
that whenever TOPOGRID calculated a value equal or
greater than the first contour within the "lowland", we
reset the value to 0.001 lower than the first contour
and whenever TOPOGRID calculated a value equal or less
than the first contour within the upland, we reset the
value to 0.001 greater than the first contour. Given
the rounding of this integer dataset, all such values
are effectively rounded to the bounding contour value
between upland and lowland. Although this approach
leaves us with some plateaus, we have fewer plateaus
than we had when we did not divide the data; and
dividing the data left us with fewer cases of upland
values being outside of their appropriate ranges.
5) To be consistent with the other states, we converted
the DEMs into NGVD29. We generated a point coverage
with 130 randomly distributed points over the entire
study area and calculated the difference values between
the two data sets for each point using National Geodetic
Survey North American Vertical Datum Conversion Utility
(VERTCON) program. We projected the coverage into
Albers projection and interpolated a grid of 30 meter
resolution by TOPOGRID. We then used this grid to
convert the DEM from NAVD88 to NGVD29.
6) The DEMs of upland and lowland were eventually
merged into the final DEM with the MERGE function
within the ESRI GRID module.
Internal feature number.
ESRI
Elevation
Interpolated from input data sets
Count of cells with common elevation
ESRI
Elevations generated from input data sets (contours and spot elevations) and interpolated into a raster DEM and rounded to nearest cm.
See process steps.
USEPA (6207-J)
1200 Pennsylvania Ave. NW
Although this data was created under the direction of the EPA, no warranty expressed or implied is made regarding the accuracy or utility of the data. Neither EPA nor the data developers shall be held liable for any use of the data and information described and/or contained herein.
1881 9th St. Suite 201 (Jones)