GIS Data Catalog

Some upland project area tiles processed on the Windows OS with an unix awk emulation command failed to properly enumerate a unique id for each record for the ascii files containing the raw elevation data in the 7500 tiles.

In other instances ascii files still contained a constant value of '1' in the ascii record, a holdover from the Arc Info Tin generation process that was not properly enumerated to a unique sequential id.

Finally a review of the Ascii files indicated that some tiles still contained a final record containing the value 'end', again a requirement of the TIN generation process that was not removed.

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

One file ag24_dsmps.asc failed to process till termination.

Limited visual inspection of the file did not indicated any anomalies.

The original file was formatted properly, in that it had unique integer id values.

This file was left in original form.

King County DSM Process Step 4: 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 absence of an overlapping data buffer when merging adjacent cells resulted often resulted in a one-cell wide NULL edge-effect in the merged tiles.

The focal filter in-filled these gaps.

Though this edited the data more than was done in the DGM case, the effect is still relatively insignificant compared to the data extent.

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.

King County DSM Process Step 3: Mutiple idxp7500 DSM TINs comprise a single idxptrmbr (township-range) tile.

Each of these TINs was converted to a ArcInfo lattice using the TINLATTICE command with a 6 (six) foot posting for the township level tiles.

Unlike the DGM TINs the DSM TINs have bounds exactly coinciding with the idxp7500 tile, thus have extents in x and y of 7500 feet.

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.

King County DSM Process Step 7: 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.

King County DSM Process Step 2: Digital Surface Model (DSM) .gen files were built for input to the TIN creation function.

The .gen files included all points of the subject tile with no buffer of any 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.

King County DSM Process Step 6: 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.

King County DSM Process Step 1: 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.

The Puget Sound LiDAR Consortium data included an All-return file that stores points from all LiDAR returns plus operational and timestamp parameters.

In the ASCII record was also the RetNo item which was used to extract the first-return records only.

King County DSM Process Step 5: 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.

Vendor DSM Production Step 4: First-return point data was transferred to media for delivery to Client in a comma/space delimited ASCII file of format easting,northing,intensity-value.

Vendor DSM Production Step 2: 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.

Vendor DSM Production Step 3: 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.

Vendor DSM Production Step 1: 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.