At the idxptrmbr (King County township-range) index level the Puget Sound LiDAR Consortium data and the data from the King County ESA/SAO project are mosaiced to produce composite tiles of data products where these projects overlap. Separate source-specific township-range tiles are not produced at this index level.
****************************************************
These following township-range tiles within the King County idxptrmbr index contain data solely from the ESA/SAO (King County/3di) project.
King County Lowland: t28r05,t28r04,t27r06,t27r05,t26r06,t26r05,t22r06,t22r05,t22r04,t21r06, t21r05,t21r04,t21r03,t20r06,t20r05,t19r06
King County Upland: t16r13,t26r12,t26r11,t26r10,t26r09,t25r13,t25r12,t25r11,t25r10,t25r09, t24r14,t24r13,t24r12,t24r11,t24r10,t23r12,t23r11,t23r10,t22r11,t22r10, t21r12,t22r11,t21r10,t21r09,t20r12,t20r11,t20r10,t20r09,t20r08,t19r12, t19r11,t19r10,t19r09,t19r08
Both Lowland and Upland: t26r07,t24r09,t23r09,t22r09,t22r08,t22r07,t21r08,t21r07,t20r07,t19r07
***************************************************
These following township-range tiles within the King County idxptrmbr index contain data solely from the Puget Sound LiDAR Consortium.
t25r03,t24r07,t24r06,t24r05,t24r04,t24r03,t23r02,t22r03,t22r02,t21r02,
******************************************************
These following township-range tiles within the King County idxptrmbr index contain data from both the King County (either lowland or upland) and PSLC project areas.
t27r04 (ag36,ah36,ai36,aj36)
t26r08 (ax31,ay31,az31)
t26r04 (ag36,ah36,ai36,aj36,aj35,aj34,aj33,aj32,ak33,ak32,al32)
t26r03 (ag36)
t25r08 (az31,az30,az29,az28,az27)
t25r07 (at30,au30,av30,aw30,ax30)
t25r06 (ao30,ap30,aq30,ar30,as30,at30)
t25r05 (al32,al31,al30,am30,an30,ao30,ap30)
t25r04 (ak31)
t24r08 (az25,az24,az23,az22)
t23r08 (az23,az22,az21,az20,ay20,ax20)
t23r07 (ax20,aw20,av20,au20,at20,as20)
t23r06 (ao20,ap20,aq20,ar20,as20,at20)
t23r05 (ak20,al20,am20,an20,ao20,ap20)
t23r04 (ag20,ah20,ai20,aj20,ak20)
t23r03 (af20,ae20)
In () are indicated the idxp7500 tiles within that township tile that are 'shared' tiles. ASCII point text files and TINs tiles are created for both datasets at the idxp7500 level with a 'kc' or 'ps' suffix for King County and PLSC, respectively. In addition, a idxp7500 tile in TIN format is created with a 'jn' suffix (for join), representing a seamline/edgematched merger of data from both projects into a single, composite tile. All township-range (idxptrmbr) tile products are created from the 'jn' tiles in any township -range (idxptrmbr) products. Finally tiles with a 'jb' suffix are those where bathymetry data (some times from several sources) has been integrated. Therefore it is possible for a single tile id to be represented by up to 4 tile versions.
In July 2007, the dataset was supplemented with two additional suffix types: GS and JS. These tile types occur only around the edges of the project area data set. They were created to add a buffer of elevation data to the data set for a planned 2007 aerial imagery project. GS tiles are extracts of the best available USGS 10 meter DEM data. JS tiles are a composite tile between the partial Lidar tile and the USGS data. The effective result is that all tiles along the edge of the King County elevation data set are complete tiles, though the quality of data in these edge tiles may be of lower resolution than the lidar elevation data. See the Process Lineage in the Data Quality section for more information.
The actual seamline boundary is not depicted in this metadata. Check with the Point of Contact if this information is required.
This data is provided as version 1.0 data. Subsequent updates, if any, will occur on a tile-by-tile basis at the 7500 foot tiling level. All modifications or edits to the actual elevation records (i.e., x,y,z points) will be done from ascii files. The ascii files will be regenerated as tins and higher order products, such as the township-range lattices and contours, will be rebuilt.
The following spreadsheet will list tile-by-tile metadata reflecting these changes.
"<http://www.metrokc.gov/gis/sdc/raster/elevation/ElevationTileMetadata.xls>"
The data was acquired and received as variably-spaced points. The spacing of the bare-earth point sets varies considerably depending on how much 'to-ground' penetration occurs. In general spacing of the points on an open surface is approximately 5 feet cross-track and approximately 5-7 feet along track. This is true for both the King County and Puget Sound Lidar Consortium data.
The King County project also includes a point density specification. The bare-earth data set was evaluated for the number of points per unit area over a range of surface and cover types. The specification was 1 sample point /30 square meters (0.033 samples/sq meter) in vegetated areas and 1 sample point/ 30 square meters (0.625 samples/square meter) in open areas. Densities varied considerably, but generally meet or exceed the specification requirement.
The three elevation data sets - bare-earth, first-return, and last-return - each contain the same point where the return represents the sole return. This means that on a open, paved surface for example, where no vegetation editing has occurred, each data set will contain the same set of points.
For a description of the point density analysis process see: "<http://www.metrokc.gov/gis/sdc/raster/elevation/AllDeliveryDensityPlot.doc>"
For a summary of the point density analysis results see: "<http://www.metrokc.gov/gis/sdc/raster/elevation/AllDeliveryDensityPlot.xls>"
For a listing of the point density locations and results see: "<http://www.metrokc.gov/gis/sdc/raster/elevation/AllDeliveryDensitySites.xls>"
Some gaps exist in coverage in northern Lake Washington where neither project fully captured the full lake extent. However all shoreline areas are delineated and lattice editing is being performed to fill in this area. LiDAR values from water surfaces should not be considered valid elevations, and this in-fill is done solely to improve cartographic data quality. This area is defined by the southeast portion of idxptrmbr tile t26r04, southwest portion of t26r05, northeast portion of t25r04 and northwest portion of t26r04. Other small gaps in smaller water features also occur and will be similarily in-filled.
The amount of overlap between the PSLC project data and that from the King County project varies considerably. Generally it is greater along the north edge of the PSLC project area and narrowest along the eastern edge. Except for the area mentioned above, where the overlap is zero, overlap ranges from a maximum of 2.5 miles to a minimum of 0.3 miles.
The three elevation data sets - bare-earth, first-return, and last-return - have extents that fully coregister.
For the King County/3di data, horizontal accuracy specification is 1 meter RMSE. This accuracy specification was not tested explicitly during quality assessment procedures. Horizontal accuracy is indirectly evaluated during Vertical Accuracy evaluation as a function of the Z (vertical) value accuracy.
For the King County/3di data 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. Factors such as these can markedly degrade the vertical accuracy locally.
The quality of the vertical control set varied considerably. From all available z-value control sites were selected that met requirements as defined in the project contract. For a summary of the vertical analysis results see: "<http://www.metrokc.gov/gis/sdc/raster/elevation/AllDeliveryVerticalAccuracy.xls>"
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. 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 return point data was transferred to media for delivery to Client in a comma/space delimited ASCII file of format easting,northing,intensity-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.
The composite lattice is input to the ArcInfo HILLSHADE command with AZIMUTH = 315, ALTITUDE = 45 and ALL arguments. The output grid is converted to a TIFF image with world file with the GRIDIMAGE command with NONE for colormap and NO on compression to create a default grey-scale hillshade for general use.
The composite ArcInfo lattice and Hillshade TIF are inspected for completeness and general overall quality and copied to Data Warehouse.
Adjustments were made to the processing routines to clip the lattice generated from the tin to 12 feet outside the tile bounds. This still provided an overlap buffer with adjacent tiles yet substantially improved the quality of the merge.
All dgm ascii files tiled in the 7500 blocks were reprocessed using an updated awk command that was tested to successfully generate a unique serial integer for all records up to the largest ascii file size. A windows version of grep was used with the -v flag to remove all occurrences of 'end' or 'End' from any files where this occurred.
The original warehouse files were unzipped, processed as indicated above and replaced.
A final inspection routine unpacked a copy of the files. A windows version of the unix tail command was used to create a text file of the last 10 records of each file. These were inspected to ensure sequential numbering was present to the end of the file and that the file terminated successfully.
Digitize and replace waterbody outlines of coverage lakebathy using KC2002 2ft JP2 format imagery at scale 1:2500.
Determine each lake in lakebathy surface elevation using lidar and adjust lakebathy contour line elevation values to the lidar.
Append all waterbody Edge Of Water arcs into one coverage for erasing water surface data and EOW hardline for TIN production.
run j:phase2\bathy\mktin_puget.aml , mktin_wash.aml, mktin_sam.aml
Creates new tins using lidar tile tin to points from plibrary3, bathymetry points: reg_ps_bthy (Puget Sound), reg_wl_bthy (Lake Washington), reg_ls_bthy (Lake Sammamish) arcs for hard breakline around the lake.
Build dgm grid, hillshade grid and image.
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).
TINs and Mass Point (variably-spaced) ASCII format files are referenced by the King County idxp7500 tile scheme which is a column-row organization beginning in the southwest corner of the project area with 'aa' for column and 01 for row.
TIN format files - 'tileabb'_gtikc for King County/3di data, 'tileabb'_gtips for Puget Sound LiDAR Consortium data, 'tileabb'_gtijn for a join between King County and Puget Sound LiDAR Consortium data merged along a common seam line, 'tileabb'_gtijb for a Lidar tile with integrated (joined)best available bathmetry, where 'tileabb' is the tile identifier from the King County idxp7500 tile scheme.
ArcInfo lattices (grids) - 'tileabb'_dgm, where 'tileabb' is the tile identifier from the King County township-range (idxptrmbr) tile scheme. Joined ('jn' or 'jb') TINs are used in lieu of project-specific TINs in cases where TINs exist as multiple versions.
TIFF images with world file - 'tileabb'_ghs.tif where 'tileabb' is the tile identifier from the King County township-range (idxptrmbr) tile scheme. A single image is produced for those tiles where both King County and PSLC data exists as the hillshade is derived from the best, merged, composite lattice.
\\gisdw\kclib\plibrary3\idxp7500\dgm_tin - TIN format files 'tileabb'_gtikc for King County/3di data, 'tileabb'_gtips for Puget Sound LiDAR Consortium data, 'tileabb'_gtijn for tiles composed of both King County and Puget Sound LiDAR Consortium data merged along a common seamline, 'tileabb'_gtijb for a Lidar tile with integrated (joined)best available bathmetry
\\gisdw\kclib\plibrary3\idxptrmbr\dgm_elevation - ArcInfo lattices (grids) ('tileabb'_dgm, only a single combined lattice is created at the township-range index level; Joined ('jn' or 'jb') TINs are used in lieu of project-specific TINs in cases where TINs exist as multiple versions.
\\gisdw\kclib\plibrary3\idxptrmbr\dgm_hillshade - TIFF images with world file ('tileabb'_ghs for King County/3di data, 'tileabb'_dgmps for Puget Sound LiDAR Consortium data). Ony a single image is produced for those tiles where both King County and PSLC data exists as the hillshade is derived from the composite lattice.