multisource 3-d fusion developer’s guide guide.pdfmultisource 3-d fusion developer’s guide...

Multisource 3-D Fusion Developer’s Guide

Submitted By: David Streutker, PhD Harris Corporation Space and Intelligence Systems 12975 Worldgate Dr. Herndon, VA 20170

THIS INFORMATION IS EAR99 CONTROLLED THIS INFORMATION IS CONTROLLED BY THE U.S. DEPARTMENT OF COMMERCE EXPORT ADMINISTRATION REGULATIONS 15 CFR 730-774, EAR99 AND CAN NOT BE EXPORTED FROM THE UNITED STATES OR SHARED WITH A FOREIGN PERSON WITHOUT PRIOR APPROVAL FROM THE UNITED STATES GOVERNMENT. Drafted: January 16, 2017

Page ii

Date

This document is EAR99 controlled. Use or disclosure of this information is subject to the restrictions on the Title Page of this document

Table of Contents

1.0 Introduction ....................................................................................................................................... 1

1.1 Requirements .............................................................................................................................. 1 1.2 Setup ............................................................................................................................................ 1 1.3 References................................................................................................................................... 1

2.0 General Use ....................................................................................................................................... 1 2.1 Overview ...................................................................................................................................... 1

2.1.1 Software Architecture ............................................................................................................ 1 2.2 File Investigation and Input/Output .............................................................................................. 1

2.2.1 Object Creation ..................................................................................................................... 1 2.2.2 Supported Formats................................................................................................................ 2 2.2.3 Header Information................................................................................................................ 3 2.2.4 File Information ...................................................................................................................... 4 2.2.5 Reading Data ........................................................................................................................ 6 2.2.6 Writing Data ........................................................................................................................... 8 2.2.7 Data Standardization ............................................................................................................. 9 2.2.8 File Manipulation ................................................................................................................. 10

2.3 Basic File Analysis ..................................................................................................................... 11 2.3.1 Object Creation ................................................................................................................... 11 2.3.2 File Point Spacing ............................................................................................................... 11 2.3.3 File Boundaries ................................................................................................................... 12

2.4 Advanced File Analysis .............................................................................................................. 14 2.4.1 Object Creation ................................................................................................................... 14 2.4.2 Partition Information ............................................................................................................ 14 2.4.3 File Point Spacing ............................................................................................................... 15 2.4.4 File Boundaries ................................................................................................................... 16 2.4.5 Nearest-Neighbor Search ................................................................................................... 17 2.4.6 Spatial Sampling ................................................................................................................. 17 2.4.7 Clustering ............................................................................................................................ 18

2.5 Error Modeling ........................................................................................................................... 18 2.5.1 Error Model Information ...................................................................................................... 19 2.5.2 Per-Point Adjustment .......................................................................................................... 19 2.5.3 Per-Point Uncertainty .......................................................................................................... 19 2.5.4 Support Limitations.............................................................................................................. 20

3.0 Multi-file Operations........................................................................................................................ 20 3.1 KML Generation ......................................................................................................................... 20 3.2 Registration ................................................................................................................................ 21 3.3 Merge ......................................................................................................................................... 21

3.3.1 Traditional Merge ................................................................................................................ 22 3.3.2 Smart Merge ........................................................................................................................ 22

3.4 Geometric Change Detection (GCD) ......................................................................................... 22 4.0 Acronyms ......................................................................................................................................... 25


1.0 Introduction

This document is intended as a general user guide for the principle software procedures developed under the Multisource 3-D Fusion project.

1.1 Requirements

This software requires IDL 8.4 / ENVI 5.2 to run. The user may start from an IDL session. If a library function is called that requires the use of ENVI functionality (e.g., to provide support for geographic projections), then a headless instance of ENVI will be initiated automatically.

1.2 Setup

The software library (either the source PRO files or a compiled SAV file) must be saved within the user’s path or compiled/restored manually before use. (If the library is saved to an ENVI custom code or extensions directory, it will be compiled automatically upon ENVI startup.)

1.3 References

The user is encouraged to refer to the source code for further documentation and information describing the use of individual functions. Additional functionality exists within the library which is not described in this document.

2.0 General Use

This section provides information regarding the general usage of the point cloud tools library.

2.1 Overview

The software delivered in this library consists of command-line tools. It is expected that the user be familiar with IDL programming techniques. Significant effort was made to design these tools to support investigation and analysis of large datasets, including data partitioning strategies and out-of-core processing methods.

2.1.1 Software Architecture

The functions and procedures that make up this library are largely object-oriented, making use of both static and instance methods. The parent object classes for working with point cloud files are XLSpcFile and XLSpcTree. Each file format has a corresponding I/O class, such as XLSioLAS and XLSioBPF.

2.2 File Investigation and Input/Output

Several general functions are provided within a class of objects for the user to investigate the properties of a point cloud file and perform I/O.

2.2.1 Object Creation

File input/output methods are provided by the XLSioFrmt family of object classes. The XLSioFrmt superclass provides a common I/O framework which is inherited by format-specific


child classes such as XLSioLAS and XLSioBPF. An object instance can be created from a file using the following command: ENVI> file = 'C:\Lidar Data\Serpent Mound Model LAS Data.las' ENVI> lasObj = obj_new('XLSioLAS', file) ENVI> help, lasObj LASOBJ OBJREF = <ObjHeapVar227827(XLSIOLAS)>

A static factory method is provided for the creation of an I/O object without prior knowledge of format type: ENVI> frmtObj = XLSioFrmt->Open(file) ENVI> help, frmtObj FRMTOBJ OBJREF = <ObjHeapVar228175(XLSIOLAS)>

2.2.2 Supported Formats

The current version of this library is written to support multiple file formats. The format support is abstracted, allowing support for individual format types to be added or removed as required. To determine the format support of the currently compiled installation, use the following static method: ENVI> print, XLSioFrmt->Formats() BPF FXYZI LAS NITF NTF PLY UPC

The default behavior of the method above lists the support for reading files. Set the /write keyword to determine supported formats for writing. ENVI> print, XLSioFrmt->Formats(/write) BPF LAS

The library expects data that are in the UTM projection or that otherwise use meters as units of horizontal and vertical distance. Levels of format support are detailed in the following table:

Table 1: Levels of format support within the point cloud tools

BPF1 FXYZI LAS LAZ2 NTF3 PLY UPC

Header Read Y Y Y Y Y Y Y

Wideband Data Read Y Y Y N Y Y4 Y

Random Access Read Y Y Y N Y Y4 Y

File Write v3 N v1.2 N N N N

1 Compressed and/or byte-interleaved files are not currently supported.

2 LAZ files are treated internally as LAS files with compression.

3 Files larger than 1 GB are not currently supported.

4 ASCII-formatted files not currently supported.


When possible, format types are determined through the use of internal descriptors or magic numbers. Each format class has a static method for testing files: ENVI> print, XLSioLAS->Test(file) 1

2.2.3 Header Information

Most point cloud file formats include a header which contains general information about the file. This information can be read as text using the Info() function: ENVI> print, frmtObj->Info(), /implied_print ============ HEADER INFO ================ Signature: LASF Global Encoding: 0 File Source: 0 Project ID - GUID data 1: 0 Project ID - GUID data 2: 0 Project ID - GUID data 3: 0 Project ID - GUID data 4: 0, 0, 0, 0, 0, 0, 0, 0 Version: 1.0 System ID: Software ID: TerraScan Creation Date: N/A <...> This function has also been wrapped in a simple GUI, which can be called as follows: ENVI> DialogHead

This produces a dialog box which allows the user to navigate to and select one or more point cloud files. (Only files in the supported point cloud formats will be displayed.) Once the user selects a file, a window is generated with the header information:


2.2.4 File Information

As with the header, there are also functions that provide general information about the file. Both from the command line: ENVI> print, frmtObj->XLSioFrmt::Info(), /implied_print Path: C:\Lidar Data\Serpent Mound Model LAS Data.las ============= FILE INFO ================= File Format Type: LAS File Format Version: 1.0 Number of Points: 3265110 Data Offset (bytes): 759 Bytes per point: 28 Data Type: Binary (little endian) Interleaving: By point


========== PROJECTION INFO ============== Name: UTM Zone: 17 Datum: WGS-84 Units: Meters ============ FILE EXTENTS =============== Min: 289020.900000, 4320942.610000, 166.780000 Max: 290106.020000, 4323641.570000, 215.480000 As well as again with a GUI: ENVI> DialogFile

After which the user specifies a file as before, and the file information is displayed in a window:

While header information is likely to differ from format to format, the information presented via XLSioFrmt::Info() and DialogFile is common to all point cloud files. Programmatic access to header and metadata information is via object properties: ENVI> help, frmtObj.header


** Structure LASHEADER2, 22 tags, length=232, data length=227: SIGNATURE BYTE Array[4] FILESOURCE UINT 0 ENCODING UINT 0 GUID1 ULONG 0 GUID2 UINT 0 GUID3 UINT 0 GUID4 BYTE Array[8] VERSION BYTE Array[2] SYSTEM BYTE Array[32] SOFTWARE BYTE Array[32] <...> ENVI> help, frmtObj.vrList[0].base ** Structure LASRECORD, 6 tags, length=60, data length=58: SIGNATURE UINT 43707 USERID BYTE Array[16] RECORDID UINT 34735 RECORDLENGTH UINT 72 DESCRIPTION BYTE Array[32] DATA POINTER <PtrHeapVar228178>

Projection information is read via the Projection() function. Projections are handled using the standard ENVI format structure. ENVI> help, frmtObj->Projection() ** Structure ENVI_PROJ_STRUCT, 9 tags, length=208, data length=186: NAME STRING 'UTM' TYPE INT 2 PARAMS DOUBLE Array[15] UNITS INT 0 DATUM STRING 'WGS-84' <...>

2.2.5 Reading Data

The data bands or fields available within a file can be accessed via the object’s bands property: ENVI> print, frmtObj.bands GPS_TIME CLASS INT XYZ ANGLE RETURN SOURCE USER

The Read() function method allows for a number of options for reading point cloud data from a file. The simplest is to read the entire data set: ENVI> data = frmtObj->Read() ENVI> help, data DATA DICTIONARY <ID=228945 NELEMENTS=8>

By default, data are read as a dictionary data type, where each key-value pair corresponds to a field of wideband data. The only field required in all point cloud files is 'XYZ', which contains a 3×N array of the coordinate data. The existence of all other fields depends on the contents of the file or the format type.


ENVI> print, data->Keys() GPS_TIME CLASS INT XYZ ANGLE RETURN SOURCE USER

ENVI> help, data.xyz, data.gps_time <Expression> DOUBLE = Array[3, 3265110] <Expression> DOUBLE = Array[3265110]

Data returned by Read() are in “absolute” units, in that they have all internal offsets and scaling factors applied. Setting the /native keyword returns the data in the native format stored within the file, without applying scaling, offsets, or type conversion. Native data are returned as a structure data type. ENVI> data = frmtObj->Read(/native) ENVI> help, data, /structure ** Structure <29cf1640>, 8 tags, length=32, data length=28, refs=3: XYZ LONG Array[3] INT UINT 260 RETURN BYTE 48 CLASS BYTE 2 ANGLE BYTE 0 USER BYTE 0 SOURCE UINT 32760 TIME DOUBLE 499450.81

Reading a segment of the data can be performed by using the range keyword: ENVI> data = frmtObj->Read(range=[1000,1999]) ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 1000]

Reading a set of specific points can be performed by using the index keyword: ENVI> data = frmtObj->Read(index=[1,3,5,1000]) ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 4]

Use of the index keyword and the nPoints object property provides a convenient method by which to randomly sample the point cloud data: ENVI> help, frmtObj.nPoints <Expression> ULONG = 3265110 ENVI> data = frmtObj->Read(index=randomu(seed,1000)*frmtObj.nPoints) ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 1000]

The /native keyword can be combined with either range or index as well: ENVI> data = frmtObj->Read(/native, range=[0,4999]) ENVI> help, data DATA STRUCT = -> <Anonymous> Array[5000]


Reading by index or range can also be accomplished through the use of the bracket notation: ENVI> data = frmtObj[1000:1999] ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 1000]

ENVI> data = frmtObj[[1,2,5,1000]] ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 4] ENVI> data = frmtObj[0:-1] ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 3265110]

Random access to single points is provided by the GetPoint() method, which returns only the coordinate triplet (with scaling and offsets applied): ENVI> frmtObj->GetPoint(54321) 289807.26000000001 4321040.9800000004 170.67000000000002

The foreach operation has been overloaded to provide a convenient method for segmented reading or paging through a file. The length of the individual data segments is determined by the step object property. ENVI> help, frmtObj.step <Expression> ULONG = 1048576 ENVI> foreach dataSeg, frmtObj do help, dataSeg.xyz <Expression> DOUBLE = Array[3, 1048576] <Expression> DOUBLE = Array[3, 1048576] <Expression> DOUBLE = Array[3, 1048576] <Expression> DOUBLE = Array[3, 119382]

2.2.6 Writing Data

Writing new files is a two-step process. The first step is to create a new object instance: ENVI> newFile = 'C:\Lidar Data\myNewFile.las' ENVI> newObj = XLSioFrmt->Create(newFile, proj=envi_proj_create(/geographic))

This creates a new, albeit empty, file. ENVI> help, newObj.nPoints <Expression> ULONG = 0

The second step is to write point records to the file. This is performed using the Write method of the new object. Note that the data must be written in a dictionary format, similar to the output of the Read() method. ENVI> newData = dictionary() ENVI> newData['XYZ'] = randomu(seed,3,2000)


ENVI> newObj->Write, newData ENVI> help, newObj.nPoints <Expression> ULONG = 2000

The astute reader will note that the Write method described above simply appends data to an existing file. As such, any existing file can be appended to by using the Write method, assuming the format has write support. Strictly speaking, the creation of the new file occurs in the instantiation of a new object via the Create() static function. The example below randomly samples a file and writes the point to a new file: ENVI> sampPrj = frmtObj->Projection() ENVI> sampObj = XLSioFrmt->Create('C:\Temp\sample.las', proj=sampPrj) ENVI> sampObj->Write, frmtObj->Read(index=randomu(seed,1000)*frmtObj.nPoints) ENVI> obj_destroy, sampObj

The default behavior of the Create() method is to use the file extension of the supplied file name to determine the format. This can be overridden by using the format keyword. ENVI> sampObj = XLSioFrmt->Create('C:\Temp\sample.abc', format='LAS', proj=sampPrj) ENVI> print, XLSioLAS->Test('C:\Temp\sample.abc') 1

The clone keyword can be used to create a new file with metadata properties (projection, scaling, offset, etc.) cloned from another I/O file object. ENVI> sampObj = XLSioFrmt->Create('C:\Temp\sample.abc', clone=frmtObj)

2.2.7 Data Standardization

Given that some formats allow user-defined metadata fields (e.g., BPF, PLY), some effort has been made to standardize certain metadata tags and labels. As was stated above, spatial coordinate data will always have the key 'XYZ', and will always be represented as 64-bit floating point values. Two time formats are recognized: GPS week time will have the key 'GPS_TIME', while Adjusted Standard GPS time will have the key 'ASG_TIME'. Both time formats will also be represented as 64-bit floating point values. If an intensity channel is recognized, it will have the key 'INT' and will be represented by 16-bit unsigned integers. For the purposes of visualization, the following metadata labels are assumed to represent intensity: 'COMPOSITEBAND' 'INTENSITY' 'RELATIVE_INTENSITY' 'RELATIVE_REFLECTANCE_ESTIMATE'


Similarly, recognized color channels will have the keys 'RED', 'GREEN', and 'BLUE'. Color channels will also be represented as 16-bit unsigned integers, and will be scaled to 16-bits when their native representation is 8-bit. (Variants of color name in the metadata labels are also recognized, for example 'COMPOSITERED' and 'DIFFUSE_RED'.) Standardized field names do not apply when data are read using the /native keyword. When the /native keyword is set, names are left as defined in the standard specification or metadata descriptions.

2.2.8 File Manipulation

File manipulation can be performed using the FileConvert routine. This routine is capable of performing several different operations. Consult Table 1 for levels of format support. Permitted input formats are those that have wideband read support, while permitted output formats are those that have write support.

2.2.8.1 Format conversion

Format conversion is performed by simply calling the routine with input and output file names that have different formats: ENVI> FileConvert, 'input.fxyzi', 'output.las'

The format keyword can be used such that the input file and output file share the same path and base name. The command below will result in an output file named 'input.las'. ENVI> FileConvert, 'input.fxyzi', format='las'

2.2.8.2 Cropping

Two-dimensional spatial cropping can be performed by using the crop keyword. The crop parameter can be a 2×2 array of extents, a 2×N polygon, or an IDLanROI object. ENVI> FileConvert, 'file.las', 'cropped.las', crop=[[0,0],[1000,1000]]

2.2.8.3 Transformation

Spatial transformation is performed by using the matrix keyword to provide a 4×4 transformation matrix. ENVI> t3d, matrix=xForm, /reset, rotate=[5,10,15], translate=[1,2,3] ENVI> FileConvert, 'file.las', 'transform.las', matrix=xform

2.2.8.4 Reprojection

Reprojection is performed by using the proj keyword to provide an ENVI projection structure: ENVI> FileConvert, 'file.las', 'reproject.las', proj=envi_proj_create(/geographic)


2.2.8.5 Combined operations

The operations described above can be combined in a single call to XLS_Convert. The order of precedence of the spatial operations is reprojection, then transformation, and then cropping. Thus the cropping and transformation inputs must be valid in the reprojected coordinate system. The following command converts the file from LAS to BPF and at the same time reprojects, transforms, and crops the point records. ENVI> FileConvert, 'file.las', 'output.bpf', crop=myCrop, matrix=myXform, proj=myProj

2.3 Basic File Analysis

While the XLSioFrmt family of object classes provides strictly input/output capabilities, a single lightweight class called XLSpcFile is available for basic file analysis. The capabilities available in this class are described below.


Instantiation occurs via the typical method: ENVI> fileObj = obj_new('XLSpcFile', file) ENVI> help, fileObj FILEOBJ OBJREF = <ObjHeapVar265914(XLSPCFILE)>

Note that file I/O is now performed via an internal instance of an XLSioFrmt family object, accessed via the io property: ENVI> help, fileObj.io <Expression> OBJREF = <ObjHeapVar266095(XLSIOLAS)>

For example, reading data from XLSpcFile object is performed as: ENVI> data = fileObj.io->Read() ENVI> help, data.xyz <Expression> DOUBLE = Array[3, 3265110]

2.3.2 File Point Spacing

A method for the simple calculation of a file’s point spacing is provided by the Density() function: ENVI> help, fileObj->Density() <Expression> DOUBLE = 0.94709255

The point spacing calculated is two-dimensional, as the square root of the file footprint divided by the number of points. The file footprint is determined by the file extents contained in the file header or metadata – in the case where the extents are not defined, a value of !null is returned.


2.3.3 File Boundaries

The boundary of a file is represented by a two-dimensional polygon and is accessed via the bounds property. For the XLSpcFile object class, the boundary is simply an axis-aligned bounding box determined by the file extents. ENVI> fileObj.bounds 289020.91 4320942.5 290106.03 4320942.5 290106.03 4323641.5 289020.91 4323641.5

A KML of the file boundary can be created using the SaveKML procedure: ENVI> fileObj->SaveKML, 'file.kml'


The boundary polygon is stored as a native IDLanROI object. As such, the native ContainsPoints() method is exposed and can be used to determine whether a coordinate falls within the boundaries of the file: ENVI> fileObj->ContainsPoints([289500,4322000]) 1

The bounds property can be combined with the FileConvert procedure to provide a convenient method to clip one file to the boundaries of another: ENVI> FileConvert, 'input.las', 'cropped.las', crop=fileObj.bounds


2.4 Advanced File Analysis

While the XLSpcFile class is available for basic analysis, the XLSpcTree class provides access to more advanced analysis capabilities. During creation of an XLSpcTree object instance, the entire file is parsed and a data partitioning structure is created. This data partitioning underlies the XLSpcTree object class and allows for improved searching and navigation within the point cloud. (The precision of the partitioning, and thus of the search methods described below, is currently set to 1 mm.) The XLSpcTree class is a subclass of XLSpcFile and thus inherits all of the methods and properties of the XLSpcFile class. (Given that the XLSpcFile objects do not parse the file, the creation of an XLSpcTree object instance takes somewhat longer than that of an XLSpcFile object.)


Instantiation also occurs via the typical method: ENVI> treeObj = obj_new('XLSpcTree', file) ENVI> help, treeObj TREEOBJ OBJREF = <ObjHeapVar271793(XLSPCTREE)>

2.4.2 Partition Information

Information about the file and the partitioning can be obtained using the Info() function: ENVI> treeObj->Info() ============= DATA INFO ================= X Min and Max: 289020.90 290106.02 Y Min and Max: 4320942.6 4323641.6 Z Min and Max: 166.78000 215.48000 Approximate Area: 1477803.0 Approximate Density: 2.2094352 Data Centroid: 39.024408° Lat, -83.430865° Lon ============= TREE INFO ================= Internal Datatype: INT Internal Scaling: 1.000000E-003 Internal Offset: 0.000000E+000, 0.000000E+000, -1.638400E+004 Redundant Points: 845 Maximum Rank: 69 Minimum Rank: 11 Indexing Datatype: LONG


The spatial information returned by XLSioFrmt->Info() differs from that returned by XLSioFrmt->Info() in that it is calculated directly from the data records as the file is parsed, and not on what is stored in the file header. As with previous Info() functions, a GUI is also provided: ENVI> DialogTree

Note that while the Info() function provides information for an existing XLSpcTree object instance, DialogTree internally creates a new XLSpcTree instance and incurs the associated overhead.

2.4.3 File Point Spacing

The Density()function of the XLSpcTree object overloads that of the XLSpcFile class and uses the data partitioning structure to provide an estimate of the three-dimensional point spacing: ENVI> help, treeObj->Density() <Expression> DOUBLE = 0.59808026

The 2D point spacing can still be obtained by directly calling the superclass method: ENVI> help, treeObj->XLSpcFile::Density() <Expression> DOUBLE = 0.67275877


2.4.4 File Boundaries

When an XLSpcTree object instance is created and the file parsed, the boundary polygon of the point cloud is updated from a bounding box to a convex hull. ENVI> help, treeObj.bounds <Expression> DOUBLE = Array[2, 64]

As such, the use of boundary-related functions such as SaveKML and ContainsPoints() will reflect a more accurate boundary polygon. ENVI> treeObj->SaveKML, 'C:\Lidar Data\Temp\file.kml'


2.4.5 Nearest-Neighbor Search

2.4.5.1 Single point search

A nearest-neighbor search can be performed by using the SearchSingle() function. The dist keyword returns the distance from the coordinate to its nearest neighbor: ENVI> point = treeObj->Search([289500,4322000,200], dist=dist) ENVI> print, point, dist 1938002 14.203137

The SearchSingle() function returns only an index. If point coordinates are required, they can be subsequently read from the file using GetPoint() or the index keyword to Read() as described earlier: ENVI> point = treeObj-> SearchSingle([289500,4322000,200], dist=dist) ENVI> treeObj.io->GetPoint(point) 289496.28999999998 4322003.8100000005 186.83000000000001

2.4.5.2 Multiple point search

The SearchMulti() function is vectorized and can be used to perform a nearest-neighbor search of multiple points at once. Its usage is analogous to SearchSingle() in that it return an array of indices and distances corresponding to the nearest-neighbor of each input coordinate. For performance reasons, it is recommended that SearchSingle() be used when searching for multiple locations that are scattered throughout the point cloud and not believed to be in close proximity to each other. (SearchSingle() can accept an array of coordinates as input, though the individual searches are performed iteratively.)

2.4.6 Spatial Sampling

The Sample() function provides a method for sampling the point cloud in a three-dimensional and spatially regular manner. Unlike the random sampling example described earlier which simply decimates the point cloud, Sample() returns a set of points which are sampled in a regular geometric manner. ENVI> points = treeObj->Sample(points=1000) ENVI> help, points POINTS LONG = Array[1480]

The regular sampling algorithm traverses the data partition until it reaches the first level that meets or exceeds the sampling request. This is why the statement above returns more points than were requested. The example below spatially samples a file and writes the point to a new file: ENVI> sampObj = XLSioFrmt->Create('C:\Lidar Data\Temp\sample.las', clone=treeObj.io) ENVI> sampObj->Write, treeObj.io->Read(index=treeObj->Sample(points=1000)) ENVI> obj_destroy, sampObj


The images below illustrate a comparison between random sampling (on the left) and spatial sampling (on the right). Each sampled point cloud contains the same number of points.

2.4.7 Clustering

The Cluster() function provides a method to perform basic proximity clustering on a point cloud. The function returns an array of cluster IDs for each point, where the individual clusters are separated by at least the input proximity distance. ENVI> clusters = treeObj->Cluster(2.0) ENVI> help, clusters, clusters->Uniq() CLUSTERS LONG = Array[3265110] <Expression> LONG = Array[229]

2.5 Error Modeling

The library includes limited support of point cloud error modeling, as defined in the Generic Point-cloud Model (GPM) and Universal Lidar Error Model (ULEM) specifications. Error model information is obtained through the use of an XLSioGPM object class. Creation of an object of this class requires as input the list of variable length records (LAS) or bundled files (BPF) embedded in point cloud files, as well as the file’s projection. ENVI> file = 'gpm_file.las' ENVI> obj = XLSioFrmt->Open(file) ENVI> gpmObj = obj_new('XLSioGPM', obj.vrList, obj->Projection())


2.5.1 Error Model Information

As with previous classes, error model objects have an Info() function: ENVI> gpmObj->Info() ============== GPM MASTER =============== Version: 1.0 Implementation: GroundSpace Dataset: points_a1_ParwanSite74_tile01_Do Date: 20150101T120101000 Coordinate System: UTM Zone 42N Model Origin: 521122.820000, 3865653.750000, 1449.680000 Model Extent: 1893.800000, 1893.740000, 61.980000 Collection: TestCollectionID Platform: TestPlatformID Sensor: TestSensorID Type: TestSensorType Mode: TestSensorMode <...>

2.5.2 Per-Point Adjustment

GPM allows for per-point spatial adjustments of point records. To compute this, use the modelToGround() function. Setting the native keyword returns the point coordinates in the native coordinate system of the file.) ENVI> point = obj[0] ENVI> print, point.xyz 521285.53 3867000.0 1458.9000 ENVI> adjst = gpm->modelToGround(point, /native) ENVI> print, adjst.xyz 521283.26 3867001.7 1458.7200

2.5.3 Per-Point Uncertainty

Using the covar keyword for the modelToGround() function returns the point covariance matrix, which contains the uncertainty information. ENVI> adjst = gpm->modelToGround(point, /native, covar=covar) ENVI> print, covar 0.60676594 0.026161545 0.016536512 0.026161545 0.60273561 0.013777633 0.016536512 0.013777633 0.15510483

Eigenvalues and eigenvectors of the covariance matrix can be calculated using the native eigenql() function.


2.5.4 Support Limitations

Current error model support is limited to ground-space models with direct storage. Sensor-space models and ground space-models with indirect storage are not supported at this time.

3.0 Multi-file Operations

Several routines in the library are intended to operate on multiple files. They are described below. Unless otherwise noted, the routines described here support all the formats listed in Table 1, even multiple formats within a single execution of a routine. (For instance, the FileICP procedure described below can be used to register an FXYZI file to a BPF file and write the output to an LAS file.)

3.1 KML Generation

A KML file containing the polygon boundaries of one or more files can be generated using the GroupKML procedure: ENVI> GroupKML, ['file1.las', 'file2.las', 'file3.las'], 'group.kml', color=[0,0,255]

The image below shows a KML of the URGENT lidar collection over Ottawa, Canada.


3.2 Registration

Registration or alignment of two point clouds can be performed via the FileICP routine, which implements the Iterative Closest Point (ICP) algorithm: The ICP procedure is called by the following statement: ENVI> FileICP, 'source.las', 'target.las', output='output.las'

In FileICP the source file is spatially transformed through an iterative process until it aligns with the target file. The output keyword provides the option writing out the source file with the alignment transform applied. Additional keywords include matrix, to return the 4×4 transformation matrix, and affine, to change the default alignment method from rigid body (six degrees of freedom) to affine (twelve degrees of freedom).

3.3 Merge

There are two methods available to merge multiple point clouds: traditional merge and smart merge.


3.3.1 Traditional Merge

Traditional merge, consisting of appending the point records of one point cloud to another, can be performed using FileConvert with an array of input files. The input files need not be of the same format and/or projection. (If the proj keyword is not set, the output projection will reflect the projection of the first input file.) File conversion and point cloud manipulation operations are performed in the same manner as with a single input file. ENVI> FileConvert, ['file1.las', 'file2.las', 'file3.las'], 'merge.las'

3.3.2 Smart Merge

The smart merge algorithm allows the merging of a source file and a target file in such a way that points from the source file are added to the target file only to fill detected voids. The target file voids are calculated in three dimensions using the nearest-neighbor algorithm. The threshold distance used to establish the presence of a void is based on the point spacing of the target point cloud. (The threshold distance can be set manually through the use of the thresh keyword.) ENVI> SmartMerge, 'source.las', 'target.las', 'merge.las'

The output merge file will have the points colored according to their original file: points from the target file will be colored gray, while points from the source file will be colored blue. The SmartMerge procedure also includes an initial step that aligns the source file to the target file using the FileICP procedure.

3.4 Geometric Change Detection (GCD)

The GCD algorithm is designed to locate change between two overlapping point cloud data sets. The basis of the GCD algorithm is the calculation of nearest-neighbor distances from all points in one dataset to the other, and vice-versa (i.e., in both directions). The amount of change is then determined by the number of points which do not have a corresponding neighbor in the other dataset within a set distance threshold. The basic GCD procedure is called by the following statement: ENVI> FileGCD, 'source.las', 'target.las', matrix=matrix, srcDiff=srcDiff, srcDist=srcDist, srcIndx=srcIndx, tgtDiff=tgtDiff, tgtDist=tgtDist, tgtIndx=tgtIndx The matrix keyword is used to provide an input transformation matrix (such as would be provided by FileICP) that is applied to the source point cloud prior to the nearest-neighbor calculations. The keyword srcDiff returns a 3×Nsource array of 3D distance vectors from each of the source points to their nearest neighbors in the target point cloud, while srcDist returns the corresponding array of Euclidean distances. The keyword srcIndx returns an array of indices of the nearest-neighbor points in the target file corresponding to the points in the source file. The corresponding tgt**** keywords provide similar arrays, but from the target to source, instead of vice versa.


While the FileGCD procedure provides the geometric relationships between the target and source point clouds, the PairGCD procedure wraps the GCD functionality to produce an output file product. ENVI> PairGCD, 'source.las', 'target.las', 'output.las'

The usage of PairGCD is analogous to the usage of the SmartMerge procedure. The output file will have points colored according to whether or not they are determined to have changed, based on correspondence with the comparison point cloud. Correspondence between files is determined by a threshold distance based on each file’s point spacing. (Here, too, the threshold distance can be set manually through the use of the thresh keyword.) Points from the target file that have corresponding points in the source file are colored gray, while points in the target file that do not have corresponding points in the source file are colored blue. The output file is then appended with points from the source file that do not have corresponding points in the target and which are colored red. In this way the output file is colored following the convention, “red is fled, blue is new.” As with SmartMerge, PairGCD includes an initial step that uses FileICP to align the source point cloud with the target point cloud. The image below shows a GCD product created from lidar point clouds collected over Harvey Field in Snohomish, WA.

The PairCluster procedure extends the PairGCD procedure by clustering the detected changed points and exporting a KML of object-level changes. ENVI> PairCluster, 'source.las', 'target.las', 'output.las'


The KML product will have the same base name as the output point cloud object -- 'output.kml' would result from the statement above. The image below shows a close-up of the KML produced by PairCluster using the Snohomish pair.

Each polygon within the KML includes a unique ID as well as estimates of the corresponding object’s mean height and footprint area.


4.0 Acronyms

ASG Adjusted Standard GPS time (defined as standard GPS time minus 1 × 109

seconds) BPF Binary Point File GCD Geometric Change Detection GPM Generic Point-cloud Model GPS Global Positioning Satellite GUI Graphical User Interface FYXZI Floating point X, Y, Z, and Intensity ICP Iterative Closest Point registration KML Keyhole Markup Language NTF National imagery Transmission Format PLY PoLYgon file ULEM Universal Lidar Error Model UPC URGENT Point Cloud file

multisource 3-d fusion developer’s guide guide.pdfmultisource 3-d fusion developer’s guide...

Documents