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.
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 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.
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
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.
