PE and RS PUBLIC November 2011 : Page-1075

Figure 1. Surveyed checkpoint locations shown on intensity image de-rived from helicopter-based lidar acquired by Tuck Mapping as part of a multi-source lidar demonstration project conducted for the Texas Depart-ment of Transportation. (Data provided and used with the permission of Tuck Mapping) of deliverable products veriﬁ cation, these tests are performed after-the-fact. Unless there are speciﬁ c interim deliverables deﬁ ned as project milestones, there are no mechanisms for engaging the producer and customer in ”real time” veriﬁ ca-tion of incremental products as data ﬂ ow through the project. These emerging guidelines imply that lidar data must be tested and veriﬁ ed at key project phases by vendors to ensure that data meet eventual delivery guidelines and speciﬁ cations. Speciﬁ cations present a framework for verifying products developed across the lidar project lifecycle process or face the prospect that downstream products will ultimately fail due to ﬂ aws that were not addressed in earlier acquisition, calibration, and processing phases. This article suggests that there is a pressing need for an effective cross-walking that maps lidar data and derived information product guidelines and speciﬁ cations to project data lifecycle phases. As an initial step in that direction, this article proposes a simple cross-walking that identiﬁ es key phases of a typical lidar project life cycle and corresponding veriﬁ cation steps that may be conducted as gateways for assuring that products will meet speciﬁ cations. Additionally, a collection of recent lidar projects is highlighted in summary with a brief description of the projects, technical challenges, and aspects of accuracy or quality characteristics. Some key tests and methods are presented that offer potential to be considered as part of a collection of industry best practices for key phases of lidar data veriﬁ cation. Across the mapping industry, data vendors have made enormous investments in aircraft, lidar instruments, inertial measurement units and GPS navigation systems, as well as project planning and data production processing capabilities. Accompanying these investments in tangible assets, data pro-ducers have made further investments in both their production processes and personnel to develop and adhere to highly techni-cal workﬂ ows, data processing, and internal quality control and assurance for delivering data products which will be acceptable to their customers. Despite the emergence of increasingly thorough guidelines and speciﬁ cations for data and derived products, as well as vendors’ production criteria, there exists a lack of commonly accepted best practices and standardized methods for verifying compliance to speciﬁ cations. Cross-Walking Speciﬁ cations to Lidar Data Project Lifecycle Phases Verifying lidar products as an industry standard practice currently emphasizes testing ﬁ nished end products. This approach can lack rigor if testing focuses only on final delivered products which include uncertainties more ideally addressed in earlier phases of the data product's lifecycle. An approach to lidar data veriﬁ cation is presented which cross-walks guidelines and speciﬁ cations to key phases of a typical lidar project. Four basic phases are proposed for a lidar project in which testing and veriﬁ cation tasks are suggested as starting points to address ”gateway”’ questions that may be answered prior to subsequent tasks in the lidar data project lifecycle. Lidar – The Project Lifecycle Disconnect A fundamental disconnect exists between lidar project data production and product delivery approaches, which inhibits the development of best practices that may be implemented across the project data production lifecycle. Lidar data and derived products are typically delivered at the end of the project; review, veriﬁ cation, and acceptance by customers typically await the delivery of ﬁ nal products. End-of-project delivery and veriﬁ ca-tion approaches do not provide vendors with incentives for verifying, documenting, or delivering incremental products. At the same time, wide variation in the current ”state-of-the-practice” for end-of-project delivery and veriﬁ cation highlights the fact that there are no mutually agreed-upon best practices or commodity software tools for verifying and accepting ﬁ nal products let alone practices and tools which could be accepted as sufﬁ cient, best practices for authoritatively testing incremen-tal products against speciﬁ cations and requirements. New guidelines and speciﬁ cations include unprecedented attention to the accuracy, quality, correctness, compliance, and completeness of lidar point cloud data which include ﬂ ightline swath data, tiled data products, and ﬁ nal classiﬁ ed tiled LAS data. The new speciﬁ cations for lidar data and derived information products require testing of various data products developed during phases of the data project. As part Photogrammetric engineering & remote SenSing Phase 1 – Flight Planning, Operations, and Lidar Data Acquisition Gateway Question: Are ﬂ ight operations complete; have data been collected fully covering the project area without voids within ﬂ ightlines, gaps between ﬂ ightline data swaths, and at the pulse spacing and density speciﬁ ed? Preliminary planning and data acquisition produce data which are converted to LAS ﬁ les. The following tasks are presented as a possible subset for which best practice methods may be developed and addressed during this phase to comply with guidelines and speciﬁ cations: • Collection Area: Determine whether the data sets from ini-tial ﬂ ightlines completely and adequately cover the deﬁ ned project area as well as any designated buffer area. • Overlap: Generate swath boundary ﬁ le polygons. Intersect adjacent boundary ﬁ les and quantify percentage of swath width in the overlap to determine whether adjacent ﬂ ightline swath data sufﬁ ciently overlap (Figure 2). • Spacing and Density: Quantify point cloud spacing and density and determine if data are spaced at sufﬁ cient density to meet project requirements (Figure 2). • Gaps and Voids: Identify gaps in data, voids that must be ﬁ lled, or areas where additional ﬂ ightlines are required. Employ vector boundaries containing holes as well as pulse continued on page 1076 November 2011 1075

Previous Page Next Page

Publication List
Using a screen reader? Click Here