Inserts or updates ODM attributes by combining existing attributes and/or grid models.
AddInfo constitutes a very general and flexible tool for creating new or updating existing point attributes by combining point attributes and/or grid models (grid values interpolated at the point locations).
The main feature of the OPALS Data Manager (ODM), besides the high performance spatial indexing, is the capability of storing arbitrary attributes (c.f. OPALS Software Concept). The attributes either stem from the analysis of the sensor data (e.g. amplitude, echo width, nr. of echos per laser pulse), but may also be a result of data processing. For the latter, the modules Module Normals and Module EchoRatio serve as examples. In contrast, the Module AddInfo provides a generic way of creating new or updating existing attributes by freely combining the attributes of a specific data point and its nearest neighbours with additional raster layers.
The additional attributes can be used in subsequent modules either for customized data selection via filters or even as basic information to control the model output (e.g. for data segmentation).
Among the potential applications of Module AddInfo are:
The main input for Module AddInfo are the ODM to operate on (inFile), the attribute assignment formula ( attribute), and a list of (optional) grid models involved in deriving the attribute values (gridModel). Additionally, Module Addinfo also provides access to the nearest neighbour (nn) points while iterating through the entire point cloud. The nn points are queried by specifying the number of neighbour points (neighbours) limited by a maximum search radius (searchRadius) and the general search and selection mode (searchMode, selMode). Please refer to Module Normals for a detailed description of the different search parameters.
The attribute names can be chosen from the list of predefined attributes with a fixed semantic and data type (c.f. ODM predefined attributes). User-defined attributes can be generated too, in which case (i) the name must be preceeded with an underscore and (ii) the data type must be provided in parentheses (e.g. attribute _myFloatAttrib(float)). A list of all supported attributes as well as more information concerning user-defined attributes can be found here. If no data type is assigned to a user-defined attribute, the type is estimated from the respective formula.
Additionally, one or two filter strings can be specified to select a subset of ODM data points (parameter filter). Please refer to Filters for a detailled description of available filters and their syntax). The first filter is interpreted as 'processing filter' and restricts the set of points for which additional attributes are to be calculated. The second filter serves as 'neighbourhood filter' and afftects the set of points returned in local neighbourhood queries. If only one (processing) filter is specified, the same filter is used as neighbourhood filter. If, however, the neighbourhood queries should consider all ODM points, the "Pass" filter or an empty filter (i.e. " " from within the commandline or "" in Python) must be used. Please note, that neighbourhood filters are only considered if spatial queries are activated (i.e. neighbours and/or searchRadius specified).
If grid models are involved in the formula, the respective grid values at the ODM data point locations are interpolated using either bilinear (default) or nearest neighbour resampling.
For the assignment of additional ODM attributes the Generic filter syntax is used. Besides attribute based data selection, generic filters also allow assigning new attributes as the result of an arbitrary algebraic combination of other point attributes, the attributes of neighbouring points and/or raster layers. A simple example for assigning an estimate of the signal intensity as the product of the full waveform attriibutes Amplitude and EchoWidth is:
Please note, that _Intensity is a user-defined attribute (indicated by the preceeding underscore) for which a corresponding type (i.e. 4-byte integer number) has to be specified in parentheses. If the type specification is omitted, the respective type is automatically estimated by the generic filter. Thus, we can also write:
... in which case the corresponding type would be estimated as "float" as the both attributes on the right hand side (Amplitude, EchoWidth) are of float type.
A more complex example, assigning the LAS vegetation class identifier (medium vegetation=4) to all echoes with an echo ratio less than 75%, using the ternary conditional operator is:
This example illustrates conditional attribute assignments (if..then..else). The Classification
attribute is set to 4
if EchoRatio < 75
, else the attribute is unchanged (i.e. the old attribute value is re-assigned and in case the attribute does not yet exist, it is not inserted at all). This example also shows the operator precedence: First, the condition on the right hand side is evaluated (potentially including the original attribute value) and only then the new value is assigned. For a detailed description of the operator precedences within generic filters, please refer to here.
Generic filters also allow to query the existence" of a respective attribute. This is especially use full if the derivation of an attribute depends on the existence of certain other attributes. The follwoing example creates a boolean smoothness indicator depending on the existence of standard deviation of the normal vector estimation.
The above example returns true
(i.e. point is located in a smooth environment) only if the attribute SigmaNormalFit
exists and is less than 10cm.
Generic filters allow for assignement of multiple attributes in a single (filter) string. Therefore, the individual attribute assignments have to be separated by a semicolon (;).
In the above example:
NormalizedZ
and the user-defined attribute _relativeheight
are added to the ODMz
) is for deriving a point attribute (the 3D point coordinates can be accessed as: x, y, z
)r[0]
refers to the first and r[1]
to the second input grid/raster model (i.e.: r[0]=DTM, r[1]=DSM)_dist2nn
is calculated using a predefined generic filter function operating on two points of the nn point set.The formulae can use all available information of the data point (coordinates and existing point attributes), its nearest neighbours as well as all values of the input grid models at the location of the data point. The following well-known variable names can be used in the formulae:
Variable name | Description |
x | x-coordinate (Easting) of data point |
y | y-coordinate (Northing) of data point |
z | z-coordinate (Height) of data point |
r[i] | pixel value of i-th input raster/grid model (index starting with 0) |
n[i] | i-th nearest neighbour point (index 0 starting with 0, referring to the current data point itself |
invalid | general void indicator |
Furthermore, all existing point attributes can be used by their respective names.
Possible values: nearestNeighbour ... nearest neighbour bilinear ........... bi-linear interpolationMethod to be used for interpolating grid values at the data point locations.
The examples presented in this section rely on the on the data sets strip21.laz and strip11.laz located in the directory $OPALS_ROOT/demo/
of the OPALS distribution. As a prerequisite, please import the LAS file into an ODM and derive a surface model using the following commands:
The first example shows how to derive the relative height of a data point with respect to a surface model.
For each point, the formula (attribute) calculates the difference between the point elevation (z) and the respective grid value of the specified surface (r[0]) at the planimetric position of the data point (x,y). The result is stored in the predefined attribute" NormalizedZ using the inherent data type float.
Please note, that the NormalizedZ attribute is only set, if a grid value exists at the x,y location of the data point, otherwise no such attribute is appended to the point.
After the (successful) execution of the above command, the new attribute is available for all subsequent operations based on the ODM. E.g. a histogram of all object heights can be derived by...
... resulting in the following output (excerpt).
CountData: 371682 CountUsed: 370607 Min: -78.066 Max: 18.413 Mean: 0.293 Median: 0.001 Std: 1.651 Rms: 1.677 SigmaMad: 0.057 Skewness: 0.598
This example shows how to combine/join information from distinct datasets stored in the same ODM. strip2111.odm contains laser echos of both strip21 and strip11. For each echo, the strip number is stored in the attribute PointSourcdId. This information is used in the subsequent command to process all points from strip21 (by specifying a first=processing filter) and calculate the elevation difference to the closest point of strip11 (by using a second=neighbourhood filter).