County, King, 200307, LiDAR Digital Ground Model Contour Isolines: King County, King County, WA.Online Links:
- None
This MBR is defined by right angle corners and four orthogonal bounds that are adjusted to the nearest 100 foot State Plane Zone 5061, HPGN position. This results in a series of overlapping tiles that fully encompass all sections within that township. The tiling scheme is defined by the spatial index called idxptrmbr (index polygons for township- range, minimum bounding rectangle). Tiles have only been created for those townships where sufficient LiDAR data was available for contouring.
Planar coordinates are encoded using Row and column
Abscissae (x-coordinates) are specified to the nearest .01
Ordinates (y-coordinates) are specified to the nearest .01
Planar coordinates are specified in Survey feet
The horizontal datum used is North American Datum of 1983, 1991 Adjustment (HPGN).
The ellipsoid used is GRS 80.
The semi-major axis of the ellipsoid used is 20925604.4720406.
The flattening of the ellipsoid used is 1/298.26.
All tiles were contoured using a 5-foot interval argument. Depending on range of values for tile, display set may be a subset of full isoline set.
| Value | Definition |
|---|---|
| 0 | Isoline is neither a multiple of 5 or 10 |
| 5 | Isoline is a multiple of 5, does not exist in tiles with 010 extension as 5-foot interval does not exist |
| 10 | Isoline is a multiple of 10 (and also of 5) |
| Value | Definition |
|---|---|
| 0 | Zero feet elevation contour |
| 1 | Beside the zero contour, represents a contour that is not a factor of 20 (feet) or 100 (feet) |
| 20 | Contour is a multiple of 20 (feet) |
| 100 | Contour is multiple of 100, representing a cumulative aggregate of 20. |
| 500 | Contour is multiple of 500, representing a cumulative aggregate of 20s. |
| 1000 | Contour is multiple of 1000, representing a cumulative aggregate of 20s. |
| Value | Definition |
|---|---|
| 0 | Zero elevation contour |
| 1 | Beside the zero contour, represents a contour that is not a multiple of 40 (feet) or 200 (feet) |
| 40 | Contour is a multiple of 40(feet) |
| 200 | Contour is multiple of 200, representing a cumulative aggregate of 40s. |
| 1000 | Elevation value is multiple of 1000, representing a cumulative aggregate of 40s |
| Value | Definition |
|---|---|
| 0 | Zero value contour |
| 1 | Beside the zero contour, represents a contour that is not a multiple of 50 (feet). |
| 50 | Contour is a multiple of 50(feet) |
| 100 | Contour is multiple of 100, representing a cumulative aggregate of 50s. |
| 500 | Elevation value is multiple of 500, representing a cumulative aggregate of 50s |
| 1000 | Elevation value is multiple of 1000, representing a cumulative aggregate of 50s |
| Value | Definition |
|---|---|
| 0 | Zero value contour |
| 1 | Beside the zero contour, represents a contour that is not a multiple of 100 (feet). |
| 100 | Contour is a multiple of 100 (feet) |
| 500 | Elevation value is multiple of 500, representing a cumulative aggregate of 50s |
| 1000 | Elevation value is multiple of 1000, representing a cumulative aggregate of 100s |
Integer value defining township and range of tile; i.e., T22R04 would be 2204
Michael Leathers
King County Geographic Information Center,
GIS Data Coordinator
201 S Jackson St, Suite 706
Seattle, WA 98104
USA
206-263-4867 (voice)
The contour interval represents a best compromise between the vertical and horizontal accuracy of the source data and the need for a general use cartographic and analysis product. At the contour interval indicated for a given tile the data provide a reasonable depiction of the general shape of the land useful for determining general landform, slope, and elevation. As, by nature, LiDAR data contain some percent of non-ground points, the contours cannot be considered absolute or without error. The index contour attributes allow the data to be reselected or symbolized to display less detail for smaller scale areas.
King County ESA/SAO contract wi, Boulder, CO, 2003, King County ESA/SAO Lowland LiDAR Project (Phase I) and King County ESA/SAO Upland LiDAR Project (Phase 2): 3di Technologies, Boulder, CO.
Puget Sound LiDAR Consortium, 2002, Puget Sound LiDAR Consortium LIDAR Elevation Data <http://duff.geology.washington.edu/data/raster/lidar/>: Puget Sound Regional Council, Seattle, WA.
LiDAR data processing was used to produce the x,y,z elevation points using vendor proprietary lidar data processing software. Within this integrated process an atmospheric correction was made, which is especially important in regions of relatively low elevation.
Data by flight line was combined in a merge process that eliminates redundant points. Data was also clipped into more manageable one km x one km bounds. Noise or anomalous returns were filtered from all data during this processing step. No additional point removal, interpolation or data smoothing was performed.The data was quality checked using commercial software, Spectra Precision TerraModel and TerraVista.
In order to produce a ground surface DEM, vegetation removal was performed on the last return elevation points data by identifying the laser returns from above ground vegetation. This proprietary algorithm is capable of removing between 90-95% of the trees and most other prominent above ground vegetation from the data. The data was triangulated into contours and any remaining vegetation or manmade structures and buildings were identified visually and interactively removed from the data. The data was triangulated again, contoured and visualized to see the effect of the additional elevation point removal and for any final edits that might be necessary.
All elevation data was processed on a point by point basis for ellipsoid to orthometric height conversion using the National Geodetic Survey (NGS) Geoid Model, GEOID99. Datum and coordinate system conversion from WGS84 to the Washington State Plane coordinate system was performed using U.S. Army Corps of Engineers CorpsCon software algorithms.
Bare-Earth (DGM) point data was transferred to media for delivery to Client in a comma/space delimited ASCII file of format easting,northing,elevation value.
After receipt from 3di Technologies, the data media was cataloged, and the media contents were logged. The ASCII files were retiled into the King County idxp7500 tiling scheme. This resulted in creation of larger files where several 1 x 1 km 3di tiles were appended and clipped to form one 7500 ft x 7500 King County tile. The ASCII records were also appended with a integer identifier resulting in a final record format of identifier, easting, northing, and elevation value.
Digital Ground Model (bare-earth) .gen files were built for input to the TIN creation function. The .gen files included all points of the subject tile plus a 100-foot buffer of all adjacent tiles. The composite ASCII .gen file was AWKed to create an output file of form: 1,easting, northing, elevation. The constant value of 1 is used to indicate that all points should be treated as Masspoints during the tinning process.
The retiled ASCII point files were built into TINs using ArcInfo CREATETIN command with no (0.0) proximity tolerance.
Mutiple idxp7500 DGM TINs comprise a single idxptrmbr (township-range) tile. Each of these TINs was converted to a ArcInfo lattice using the TINLATTICE command. Each of these lattices has an actual extent of 7700 feet in both x and y (where there is data for the full extent) due to the 100 foot buffer established during TIN creation.
Depending on the orientation of the township-range tile bound to the underlying idxp7500 grid, between 15 and 25 individual lattices are created which are then MERGED in GRID to create a composite lattice.
Any negative values in the resulting composite lattice are set to NULL. This is done to eliminate potential erroneous values and potentially confusing statistics. This tends to eliminate negative values associated with water features, as well as other spurious values.
A 3x3 focalmean filter is executed against all NULL values to infill any inliers that have now been converted to NULL with an elevation approximation based on adjacent values. The 100 foot overlap of the input lattices reduces the possiblity of creating strong null value edges between tiles so this 3x3 filter is considered as filling only localized NULL 'holes' in the data.
The original unaltered values of any given data point can be found in the underlying TIN or ASCII point file if access to the unmassaged data is necessary.
A NULL editmask delineating the open water of the Puget Sound and all areas beyond the project area buffer elsewhere was applied to mask out all remaining 'out-of-bounds' elevation values. This is done mainly to help 'clean-up' the water areas but also cleaned up along the edge of the project area.
The boundary used along the shoreline was designed to be conservative to avoid clipping any valid nearshore elevation values.
The underlying TINs and ASCII point files can be used to recover, if necessary, any points removed by this edit.
The composite lattice created by merging the individual 7700 tiles extends beyond the extent of the township-range tile. The composite lattice is clipped to the bounds of the township-range tile using the GRID GRIDCLIP function.
The resulting clipped lattice is defined with projection information using the PROJECTDEFINE command.
All township-range tiles including the subject tile and adjacent neighbors are assembled into a composite lattice using the GRID MERGE command. The resulting composite lattice is clipped to the extent of the subject tile buffered to 3500 feet. This is done to reduce the size of the lattice to be contoured while providing a generous buffer extent to minimize all edge effects during contouring and to maximize the consistency of contour generation between adjacent tiles.
ArcInfo FILTER command with low option and 2 interations is used to smooth the DGM data in preparation for contouring. Pre-production testing was performed to determine the amount of smoothing of the base lattice, as well as factors for weeding, generalization and splining of the vectors themselves. Though other combinations of parameters and generation sequence could be tested, the result of the current suite of parameters generates a reasonable user product for the stated intent.
The underlying TINs may be used to generate contours that more closely interpret the 'raw' elevation data. Alternatively the ASCII point data may be used.
ArcInfo LATTICECONTOUR command is used with a weed tolerance of 2 feet, zero base elevation and with a contour interval of 5 feet. All township-range tiles will be generated with a 5 foot contour interval regardless of the final production display provided. Tiles in areas of very rapid relief change may be provided at contour intervals greater than 5 feet, but the a standard generation parameters will ensure coincidence of isolines from any subsets generated.
ArcEdit is used to spline the contour vectors using a GRAIN tolerance of 5 feet and the DEFAULT SPLINEMETHOD.
ArcInfo GENERALIZE command with the BENDSIMPLIFY option and a tolerance of 8 feet was used to remove some of the vertices of the splined vectors, perserving their shape while attempting to reduce file size. In practice this step does not seem to have a significant effect on reducing file size but was kept in the processing sequence as it does not appear to have a detrimental effect on the cartographic quality of the contours.
Inspection of resulting contours for test areas indicated that the resultant contours up to this step contained a large number of small closed contour loops. Though many of these features may be valid interpretations of the topography as represented by the DGM points, they tended to detract significantly from the cartographic quality of the product while not adding substantially to the usefulness or accuracy of the topographic interpretation.
Node topology was constructed on the contour vectors and all vectors where tnode# = fnode# and length < 100 feet were removed.
The completed contours were defined with projection information, clipped to the actual bounds of the township-range tile and renamed to reflect the identifier of the tile and the contour interval represented.
A look-up table containing the elevation-index level relationship, created previously, was joined to the contour coverage .aat table.
The resulting coverage was converted to a production shape file.
To faciliate use of the contour data by CAD software both vector and attribute conversion was done. The contour coverage aat was appended with the ArcInfo attributes that correlate with the CAD drawing file items, i.e., dxf-layer, dxf-color, etc.
The following attribute value correlations were created in attempt to mirror most of the ArcInfo attribute information to an AutoCad element.
elevation calculated to dxf-elevation
idx_minor calculated to dxf-color
'OTHER CONTOURS' moved to dxf-layer where idx_minor = 1
'20 FT INDEX CTR' moved to dxf-layer where idx_20ft ne 1
'40 FT INDEX CTR' moved to dxf-layer where idx_40ft ne 1
'50 FT INDEX CTR' moved to dxf-layer where idx_50ft ne 1
'100 FT INDEX CTR' moved to dxf-layer where idx_100ft ne 1
The original coverage aat attributes are dropped preserving only the CAD attributes.
Exporting the ArcInfo coverage to a single dxf file using the ARCDXF command results in a file larger than acceptable for AutoCAD DXF to DWG conversion. The coverage is reselected to create to smaller files based on the idx_minor and each of these files is read into AutoCAD and the two files are combined into a single DWG file.
Unnecessary shapefile attributes created during shapefile to coverage conversion and reconversion were removed. TILE_ID attribute was added and populated with twnshp-rge integer value (i.e., Twnshp 26 Range 05 would be 2605) to assist in identifying arcs for tile by tile replacement in future.
Edited shapefiles were saved out to final pre-edgematch version of shapefile.
Tiles were edgematched in ArcMap using the Spatial Adjustment toolbar. Snapping options were set: Snapping tolerance and mapunits.
Within the Adjustment Toolbar the EDGESNAP method was chosen, Adjust Data - all features. Target and Source were chosen and attributes were used to ensure correct links were created. One link per destination point and Prevent duplicate link options were checked.
Extensive QC was performed along edges and at corners to ensure that edgematching was successful; no dangles were left and that contour values matched. Some minor adjustments were required so that tiles with 10-foot contours only matched successfully with tiles that had five and 10 foot contours.
The edgematched tiles were imported into the SDE Geodatabase as reg_ctr005_line. A few tiles had a very few arcs that did not convert but the extent of the drop-outs was not determined.
A Python script was created to clip out the PLSS township tiles from the seamless GDB. The extent of each tile exactly matches the extent of that named township. Except for the TILE_ID and SDE length attribute the schema of these tiles is identical to that of the original dgm_contour shapefiles.
Updates to this seamless contour set will lag behind updates to the dgm_contour set.
Batch file gisimage\images\ElevMaint\ctr27500\dxf_clip.bat is built in Excel to build all 1266 tiles because of software memory issues.
For CTR.SHP files, drop the following system-generated attributes left-over from legacy ArcInfo processing: FNODE_ TNODE_ LPOLY_ RPOLY_ LENGTH (no user value information) CLPCTR_ CLPCTR_ID
For CTR.SHP files, add the following attribute to make this dataset consistent with the schema for the CTRNEAT.SHP files: TILE_ID - contains the integer value of the township-range (i.e., 2204) that tile covers
For CTRNEAT.SHP drop the following attribute: SHAPE_len (no user value information)
With completion of these schema changes the schema for both the CTR and CTRNEAT data sets will be identical: FID Shape TILE_ID ELEVATION IDX_MINOR IDX_20FT IDX_40FT IDX_50FT IDX_100FT
This consistency will make the integration of any tiles with improved or enhanced data easier for insertion into the SDE Featureclass REG_CTR005_LINE
Elevation attributes are derived from the LATTICECONTOUR function within ArcInfo and are accurate relative to the vertical accuracy of the underlying bare-earth dgm data.
The contours were generated from ArcInfo lattice grids based on 6-foot center to center posting. Horizontal accuracy will be approximately 1/2 of the posting distance or about 3 feet in areas where point density is high (equivalent to 5-7 feet point spacing). Where point density is considerably reduced due to poorer to-ground penetration rates, the horizontal accuracy will be reduced proportionally and may be only accurate to 10-15 feet and locally accuracy will be even poorer.
Areas of built-up manmade features do not have any 'bare-earth' points and any elevation interpretation, including contour delineation, is created by interpolation from the nearest bare-earth points outside the built-up area. In these cases the contour interpretation may accurately reflect the amount of overall slope change but cannot accurately depict the area covered by the built-up feature.
The elevation attribute, provided in integer feet, represents an interpretation of the tinned elevation values interpolated to a six-foot centered lattice. Limited testing has indicated that the contours represent LiDAR elevation values within 1/5 of the contour interval though in areas of steep terrain and dense vegetation canopy the contour elevation value should be considered accurate to only 1/2 the contour interval. Locally the contour interpretation of the ground elevation will be poorer, especially in areas of dense vegetation (particularly dense understory vegetation) and areas of steep slope.
The contour interpretation is directly related to the vertical accuracy of the underlying bare-earth digital ground model from which it is created. Vertical accuracy of the bare-earth data varies considerably. Quality Assessment evaluation of vertical accuracy indicate that, as a whole, the data exhibits a RMSE (Root Mean Square Error) of 30 cm or less in areas without vegetation canopy or dense subcanopy. This is equivalent to a National Standard for Spatial Data Accuracy (NSSDA) of 58.8 cm at the 95% confidence interval (1.96 x RMSEz). In areas of dense vegetation canopy, but where some bare-earth penetration is available, the data generally has less than 60 cm RMSE, equivalent to 117.6 cm NSSDA Accuracy.
Better accuracies are obtained in many areas, but poorer accuracies are also prevalent due to low penetration rates, incomplete vegetation and elevated feature removal, errant points due to multiple reflection travel paths and other edge-effects. Water and areas immediately adjacent to open water areas are always suspect due to the inability to obtain good returns from these surfaces.
Contours cover the entirety of each tile to the extent that LiDAR data is available for that area. No gaps occur within the contour lines.
Processing routines were adjusted and/or contour interval increased to mininimze, though not necessarily, eliminate all crossing contours, especially in areas of steep relief. All contours are labeled. Contours were created on a tile by tile basis, using a buffer of adjacent data to minimize edge effects and to have contours overlay as closely as possible. However township tiles have not been butt-joined and edge-matched.
As stated in the Abstract not all tiles contain five-foot contours. This restriction is dependent on the tile's extent (i.e., amount of relief) and whether the tile has elevation ranges less than 1000 feet.
For tile-based data stored in the Spatial Data Warehouse, the following image shows all tiles with with five-foot contours (either above or below 1000 feet) and then the only tiles with five-foot contours above 1000 feet.
<http://www.metrokc.gov/gis/sdc/raster/elevation/images/FiveFootContourDistribution.jpg>
One copy of the tiles has been modified for storage in the SDE Geodatabase. These tiles have been clipped to a midline neatline between townships and edgematched. All 5-foot contours above 1000 feet have been removed for all tiles so that no dangling arcs will occur. These tiles will have five foot contours only if there are elevations less than 1000 feet within the tile's extent.
Are there legal restrictions on access or use of the data?
- Access_Constraints:
- A cooperative data sharing arrangement between the Puget Sound LiDAR Consortium and King County is allows certain formats of the LiDAR data to be distributed with out license or restriction. Certain processing and data handling charges for necessary cost recovery may apply. Access to raw mass point files is by special request and request evaluation only.
- Use_Constraints:
- These contours are based upon LiDAR returns which inherently contain some "non ground-surface" values. In addition, the contours were smoothed, as outlined in the Process Section, to create a more traditional cartographic product. As such, these contours represent only the general shape of the land and do not meet the definition of topography per chapter 18.43 of the Revised Code of Washington. These contours do not depict the topography relative to any particular property. Any use of this information without additional verification by competent professionals is inappropriate.
Dennis Higgins
King County GIS Center, Client Services,
Manager, Client Services Division
201 S Jackson St, Suite 706
Seattle, WA 98104
USA
206-263-4523 (voice)
LiDAR Digital Ground Model Contour Isolines
King County disclaims any warranty of use of any digital product or data beyond that for which it was designed.
| Data format: | ArcInfo Shapefile, Autocad DWG file |
|---|---|
| Network links: |
\\gisdw\kclib\plibrary3\idxptrmbr\dgm_contour |
| Media you can order: |
CD-R, DVD+R
(format CD: Read-only, DVD: DVD+R read-only)
|
Contact KCGIS Client Services <http://www.metrokc.gov/gis/services/> for cost of reproduction and delivery
Michael Leathers
King County GIS Center,
GIS Data Coordinator
201 S Jackson St, Suite 706
Seattle, WA 98104
USA
206-263-4863 (voice)
mike.leathers@metrokc.gov
