LiDAR Digital Ground Model (DGM) Elevation

Metadata also available as - [Outline]

Frequently-anticipated questions:


What does this data set describe?

    Title: LiDAR Digital Ground Model (DGM) Elevation
    Abstract:
    Last-return LiDAR data edited to remove 90-95% of vegetated and man-made elevated features. Depicts - within limits of operational accuracy, point density and editing efficiencies - a 'bare-earth' interpretation of the earth's surface.Also called Digital Ground Model (DGM), Virtually-Deforested (VDF) Model, or 'Mowed' surface. Data is stored as variably-spaced point text files (ASCII), ArcInfo TIN (Triangulated Irregular Network) format, ArcInfo Lattice Grids, and hillshade TIFF images.
    Supplemental_Information:
    Separate source-specific versions of the dgm elevation data in TIN and ASCII format are maintained only at the idxp7500tile level. Mass point ASCII files are not merged but a merged TIN is created for any idxp7500 tiles where the PSLC and King County data overlap, in addition to separate TIN tiles for each source.

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

  1. How should this data set be cited?

    County, King, 200307, LiDAR Digital Ground Model (DGM) Elevation: King County, King County, WA.

    Online Links:

    • None

    Other_Citation_Details:
    This product is derived from LiDAR elevation model data obtained from the PSLC (Puget Sound LiDAR Consortium) and from the King County ESA/SAO (Endangered Species Act/Sensitive Areas Ordinance) project.

  2. What geographic area does the data set cover?

    West_Bounding_Coordinate: -121.500000
    East_Bounding_Coordinate: -121.100000
    North_Bounding_Coordinate: +47.800000
    South_Bounding_Coordinate: +47.100000

  3. What does it look like?

  4. Does the data set describe conditions during a particular time period?

    Beginning_Date: Nov-2000
    Ending_Date: Feb-2003
    Currentness_Reference: ground condition

  5. What is the general form of this data set?

    Geospatial_Data_Presentation_Form:
    Raster digital data, Tabular digital data, TIN digital data, TIFF and JP2 Hillshade image

  6. How does the data set represent geographic features?

    1. How are geographic features stored in the data set?

      Indirect_Spatial_Reference:
      The DGM elevation data is organized in a standardized tile scheme. The highest resolution tiles as lattices or hillshades are provided in a tiles that approximate the PLSS township-range grid for the projectarea. The tiles are defined by a minimum bounding rectangle (MBR) defined around each township-range, and identified by the township number as t## cocanenated with the range number as r##. A resulting representative tile_id would be t22r04.

      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.

      This is a Point data set. It contains the following vector data types (SDTS terminology):
      • Point

    2. What coordinate system is used to represent geographic features?

      Grid_Coordinate_System_Name: State Plane Coordinate System
      State_Plane_Coordinate_System:
      SPCS_Zone_Identifier: Washington, North
      Lambert_Conformal_Conic:
      Standard_Parallel: 47.500000
      Standard_Parallel: 48.733333
      Longitude_of_Central_Meridian: -120.833333
      Latitude_of_Projection_Origin: 47.000000
      False_Easting: 1640416.666500
      False_Northing: 0.000000

      Planar coordinates are encoded using Row and column
      Abscissae (x-coordinates) are specified to the nearest 0.01
      Ordinates (y-coordinates) are specified to the nearest 0.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.

      Vertical_Coordinate_System_Definition:
      Altitude_System_Definition:
      Altitude_Datum_Name:
      North American Vertical Datum of 1988. Z value is referenced to orthometric elevations derived from National Geodetic Survey Geoid Model, Geoid99.
      Altitude_Resolution: 0.01
      Altitude_Distance_Units: Feet
      Altitude_Encoding_Method: Attribute values

  7. How does the data set describe geographic features?

    Entity_and_Attribute_Overview:
    The elevation data are stored as ArcInfo TINs, floating integer grid lattices, TIFF images and as variably-spaced point files in ASCII format. There are not attributes tables attached to any of the data formats. The only encoded value beyond the easting and northing spatial coordinates is the elevation value. The ASCII files containing the variably-spaced points includes a unique integer identifier for each point.
    Entity_and_Attribute_Detail_Citation: None


Who produced the data set?

  1. Who are the originators of the data set? (may include formal authors, digital compilers, and editors)

  2. Who also contributed to the data set?

  3. To whom should users address questions about the data?

    Michael Leathers
    King County Geographic Information Center,
    GIS Data Coordinator
    201 S Jackson St, Suite 706
    Seattle, WA 98104
    USA

    206-263-4867 (voice)


Why was the data set created?

Comparable in purpose and use to the USGS Digital Elevation Model (DEM) data but generally of a higher level of accuracy and sample density. Useful for a range of analytical and cartographic projects including flood hazard evaluation, geologic mapping, hydrologic modeling, slope and aspect determination, and line-of-sight calculations. These data was processed through an extensive series of quality control steps by both the vendors and clients; however, they are still considered an interpretation or model of the earth's surface rather than an absolute point-to-point measure. Further, the data are not without error due to incomplete editing, absence of sufficient point density, and other 'blunder' or erroneous points. Finally, due to changing ground and vegetative conditions the quality and accuracy of the data vary considerably with areas of steep relief and/or dense vegetation exhibiting poorer quality than open flat areas. This is due to a large variance in the number of points from area to area that are considered 'to-ground' values combined with the variance in absolute horizontal and positional accuracy of given points. Users must make careful review of the fitness of these data for their particular use. For many purposes a site- and use-specific field survey will be necessary. In particular, derivation of contours, whether from the raw ascii points or a derived surface (i.e., lattice or tin), should be approached with caution due to the high variability of the data. Contours generated at an interval finer than 5-feet may not meet necessary accuracy requirements for specific environmental or building purposes needs and do not take the place of a first-order ground survey.


How was the data set created?

  1. From what previous works were the data drawn?

    3di (source 1 of 2)
    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.

    Other_Citation_Details:
    The King County ESA/SAO project is comprised of two separate project areas (phases). Phase I (lowland phase) includes the portion of western King County and southern Snohomish County that completes that portion of the County not covered by the PSLC project. The second phase (upland phase) includes the remainder of the County.
    Type_of_Source_Media:
    CD-R and DVD+R containing x,y,z LiDAR elevation records and x,y,intensity_value records.
    Source_Contribution:
    All first, last and bare-earth ascii elevation files, as well as first and last return intensity data.

    PSLC (source 2 of 2)
    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.

    Other_Citation_Details:
    The Puget Sound LiDAR Consortium serves as a central clearinghouse for LiDAR elevation data acquired for large portions of the Puget Sound lowlands including Vashon Island and urban/suburban areas of King County. The PSLC is coordinated through the Puget Sound Regional Council. A cooperative agreement between the Consortium and King County is working to make all the LiDAR data, regardless of original source, publicly available.
    Type_of_Source_Media:
    King County received the PSLC contribution to merge with its ESA/SAO 3di data through several preliminary CD/DVD media deliveries for testing and cross-check with the 3di data. Final, complete delivery was made to King County on portable harddrive.
    Source_Contribution:
    All-return ASCII files, and bare-earth ASCII files and ArcInfo format digital elevation models.

  2. How were the data generated, processed, and modified?

    Date: 2002 (process 1 of 15)
    Vendor DGM 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.

    Date: 2002 (process 2 of 15)
    Vendor DGM 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.

    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.

    Date: 2002 (process 3 of 15)
    Vendor DGM 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.

    Date: 2002 (process 4 of 15)
    Vendor DGM Production Step 4:

    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.

    Date: 2003 (process 5 of 15)
    King County DGM 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.

    Date: 2003 (process 6 of 15)
    King County DGM Process Step 2:

    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.

    Date: 2003 (process 7 of 15)
    King County DGM Process Step 3:

    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.

    Date: 2003 (process 8 of 15)
    King County DGM 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 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.

    Date: 2003 (process 9 of 15)
    King County DGM 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.

    Date: 2003 (process 10 of 15)
    King County DGM 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.

    Date: 2003 (process 11 of 15)
    King County DGM 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.

    Date: Apr-2004 (process 12 of 15)
    Review of version 1 township-range tiles indicated substantial edge effects at the boundary where one 7500 tin overlapped an adjacent 7500 tin. Though systemic this did not occur along all boundaries. The 100 foot overlap built into the tin extent was designed to reduce edge effects when lattices derived from the tins were merged. However there continued to be an effect at the edge of the 100 ft lattices possibly due to how the lattice was calculated at the edge.

    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.

    Date: Mar-2005 (process 13 of 15)
    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 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.

    Date: Jun-2006 (process 14 of 15)
    Add Bathemetry data for Puget Sound, Lake Washington, Lake Sammamish. Indentify which idxp7500 tiles that have bathymetry data to be processed and build tinlist.

    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.

    Date: Jul-2007 (process 15 of 15)
    Added USGS 10m DEM data to tiles at the outer edge of the current data set. Two types of tiles were produced - tiles completely comprised of USGS elevation points and tiles that are a merge between the lidar elevation data and the USGS points. Only ASCII tiles were created. The USGS elevation data was not integrated into TINs, Hillshades or any higher-level products. 197 GS tiles were produced. The USGS DEM was clipped to the tile boundary, resampled to 12 foot, and exported as ID,X,Y,Elevation, where ID is a unique serial ID. For the JS tiles (170), both the existing lidar and new USGS point datasets were converted to coverages (USGS first to Lattice, then to point, Lidar first to TIN then to point). Using x_dgmasc.shp, which defines the extent of the lidar data, the USGS points that fell within the lidar extent were erased and the lidar points were clipped to the boundary to create a well-defined neat line. The two resulting coverages were unloaded to delimited files X,Y,Z and then appended. The appended file was then AWKed to create ID,X,Y,Z to create tileabb_dgmjs.asc The completed file was TINNed and hillshaded for quality control inspection. Finally, both the complete GS and JS tiles were zipped and placed in the SDW library.

  3. What similar or related data should the user be aware of?


How reliable are the data; what problems remain in the data set?

  1. How well have the observations been checked?

    All data products produced from the 'bare-earth' elevation data and described by this metadata are digital tabular, digital TIN or digital raster data. They contain no additional attributes beyond the elevation value assigned to each spatial coordinate location. The ASCII file version of the data contains no header, but is stored as unique identifier, easting, northing, elevation.

  2. How accurate are the geographic locations?

    See the Puget Sound LiDAR Consortium website for details regarding the accuracy of the data from that project, <http://duff.geology.washington.edu/data/raster/lidar/>. The laser produced an approximately 0.9 meter ground spot (footprint). Horizontal accuracy is generally interpreted to be approximately two times the laser footprint, resulting in a horizontal accuracy estimate of about 1.8 meters.

    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.

  3. How accurate are the heights or depths?

    See the Puget Sound LiDAR Consortium website for details regarding the accuracy of the data from that project, <http://duff.geology.washington.edu/data/raster/lidar/>. It does state that vertical accuracies are on the order of 1 foot, though locally the data is of poorer quality.

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

  4. Where are the gaps in the data? What is missing?

    Elevation data will cover the entirety of the PSLC and King County ESA/SAO combined project areas when the King County/3di upland portion is completed. This will include a 100-meter buffer around the ESA/SAO project area which is generally defined by the King County boundary and the WRIA 8 boundary in Snohomish County. In those areas where King County and PSLC data coexist, King County data is used after excluding data within a limited distance from the data boundary. This is done in order to maximize the amount of the more recent King County data in any composite while reducing the possible affect of boundary edge artifacts. The seamline, chosen by heads-up inspection of the data overlap area, was edited to minimize any join effect in merging the data.

    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.

  5. How consistent are the relationships among the observations, including topology?

    All x,y locations, whether as a record in the ASCII text file, as a TIN node or as a lattice posting location, contain an elevation value.

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


How can someone get a copy of the data set?

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 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 data products are based upon LiDAR returns which inherently contain some "non ground-surface" values. You should carefully determine the place-to-place accuracy and fitness of these data for your particular use. For many purposes a site- and use-specific field survey will be necessary.

  1. Who distributes the data set? (Distributor 1 of 1)

    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)

  2. What's the catalog number I need to order this data set?

    ASCII format text files - 'tileabb'_dgmkc.asc for King County/3di data, 'tileabb'_dgmps.asc for Puget Sound LiDAR Consortium data, 'tileabb'_dgmjn.asc for a join between King County and Puget Sound LiDAR Consortium data merged along a common seam line, 'tileabb'_dgmjb.asc for a Lidar tile with integrated (joined)best available bathmetry, where 'tileabb' is the tile identifier from the King County idxp7500 tile scheme. 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.

  3. What legal disclaimers am I supposed to read?

    King County disclaims any warranty of use of any digital product or data beyond that for which it was designed.

  4. How can I download or order the data?


Who wrote the metadata?

Dates:
Last modified: 15-Jul-2003

Metadata author:
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

Metadata standard:
FGDC Content Standards for Digital Geospatial Metadata (FGDC-STD-001-1998)


Generated by mp version 2.7.17 on Fri Apr 18 17:52:07 2008