Technische Universität Wien
Orientation and Processing of Airborne Laser Scanning data
Department of Geodesy and Geoinformation - Research Groups Photogrammetry and Remote Sensing
This page contains a list of frequently asked questions. You can send your own OPALS related questions to: opals@geo.tuwien.ac.at.
Please send an email to: opals@geo.tuwien.ac.at
OPALS aims at providing a complete processing chain for large ALS projects for scientific and commercial users. For testing and small scientific studies, a full featured version of OPALS with a built-in maximum point limit of 1 Mio ALS points is available free of charge. The free version is for private, non-commercial use only. For any other use a license must be obtained.
Yes. If you want to test OPALS for processing LiDAR data, we generally provide a 4-week test license. Just send an email to the OPALS team
Yes. The Vienna University of Technology (TU Wien), Department of Geodesy and Geoinformation (GEO) is willing to support all students working in laser scanning and point cloud processing in their scientific work by providing a full OPALS license for the duration of their thesis subject to the following terms and conditions. Please contact the OPALS team for further information or just send us the filled out and signed proposal.
Yes. GEO appreciates collaborations with external scientific as well as non-scientific institutions. The terms and conditions can be found here. For further information please contact the OPALS team.
Within the opalsShell you can get a short description on the module and its parameters using the help parameter. E.g. for help on Module Import type:
More details can be directly accessed by using the helpChm or the helpHtml parameter, which brings up the full local module documentation in a separate browser windows (The Compiled HTML version (helpChm) also provides a full text search. Also see below)
Alternatively, you can always look on the OPALS web page online. However, there is no parameter for directly getting there. Please note, that the online web page provides different versions (see upper left selection field). Hence, your modules may have a slightly different behaviour than described online.
search is supported when using $OPALS_ROOT/doc/opals.chm, which is a Compiled HTML Help file or use the OPALS web page online.
To run the demo examples, the current user requires write permissions to the $OPALS_ROOT/demo/ directory. If OPALS was installed to the default program folder, normal users do not have write access to these folders under Windows 7, 8, and 10. This is why, the setup under Windows provides an installation option that copies all demo files to an additional directory that is writable by all users. If this install option wasn't selected during setup, you have three choices:
opalsShell as administrator which gives you write permissions to all program folders.
You probably have re-configured OPALS to use an external Python installation. Please check the respective instructions given in sections Configuring an external Python installation on Windows and Python bindings .
On startup, PyScripter tries to create a file in the directory from where it is started. On failure to do so, it gives you the mentioned error message. When clicking Abort, PyScripter still starts, but with its internal Python engine being active. Using PyScripter's internal Python engine to call OPALS modules might lead to abnormal program behaviour. To use the stable remote engine, please make sure that you (the user who is logged on) have write permissions for the directory $OPALS_ROOT/addons/PyScripter/. Re-start PyScripter by double-clicking on $OPALS_ROOT/addons/PyScripter/startPyScripter.bat. After successful start-up, switch on the remote Python engine using menu Run, entry Python Engine, Remote .
OPALS stands for Orientation and Processing of Airborne Laser Scanning data.
The message says that the module ran out of memory. In situations with enough physical memory one can try to decrease the number of processing threads (parameter -nbthreads) or reimporting the data with smaller tile sizes (for further details please refer to Analysing the index statistics of an ODM).
As suggested one can try to increase the number of points kept in memory (default value is 3 millions) or to decrease the number of processing threads (parameter -nbthreads). If both options fail it is recommended to re-import the data with smaller tile size (for further details please refer to Analysing the index statistics of an ODM).
An OPALS command line executable has tried to load the Python interpreter, which failed. You probably have re-configured OPALS to use an external Python installation. Please check the instructions given in sections Configuring an external Python installation on Windows and Python bindings .
Depending on data set and processing module, the efficiency of the parallelization may differ widely. Generally it can be said: the more complex task the better. However, we try to continuously improve the parallelization efficiency also for 'simple' tasks.
In OPALS the terms grid and raster are used synonymously. However, you may observe the effect of using 'center' or 'corner' with the '-limit' parameter.
A digital terrain model (DTM) is used to describe the terrain. A grid or raster can be used to represent the DTM inside a certain region of interest (ROI). Fig.1(a) shows a rectangular ROI with limits (Xmin, Ymin,Xmax,Ymax); see also FAQ on limit specification. Grid and raster are used synonymously. It is a set of regularly distributed 2D points with heights. The points are evenly spaced in X and Y by e.g. a distance s. Thus the grid for the ROI in Fig.1(a) would be given by Fig.1(b).
Note that the border points of the grid lie on the ROI limits. This is naturally required, as for different products (e.g. contour lines) heights need to be computed also at locations in between the grid points using interpolation. Outside the border points (and thus the ROI limits) no interpolation is possible - only extrapolation, which should be avoided in any case, because of unpredictable and unreliable results.
The direct visualization of the height values of the DTM can be achieved using a color coding and would thus be a set of colored points; see Fig.2(a). However, to enhance the perception the colored points are usually replaced by colored pixels; see Fig.2(b). This color coded visualization as a raster image is a direct product of the DTM, because the stored heights are used as they are.
Note that, the centers of the border pixels are lying on the limits. Therefore, the area covered by the pixels exceeds the limits of the ROI by half a column in east and west, and also by half a row in north and south. If only a single ROI is considered, then this exceeding is of no concern, usually. However, the exceeding may be unwanted in case of tiles. Tiles are rectangular ROIs, which are used to partition a larger area like a whole country into smaller parts for easier handling. Neighboring tiles do not overlap but lie gapless side by side. Therefore, also the color coded tiles of the DTM may be wanted to lie gapless side by side. For this purpose the raster image of the color coding should be created inscribed, so that the edges (and corners) of the border pixels lie on the ROI limits.
All OPALS modules provide the -limit parameter to control the location of the border pixels with respect to the input ROI limits. The input ROI limits are defined by the border points of the input file(s). As default (or by using the -limit parameter with value center) the output is generated so that the centers of the output border pixels lie on the input ROI limit;see Fig.3(a). Use the -limit parameter with value corner to place the edges (and corners) of the border output pixels on the input ROI limit (as maybe wanted in the case of tiles);see Fig.3(b). Note that in this latter case an interpolation is required and thus not the originally stored height values are used for the color coding.
opalsZColor using -limit center (=default) (same as Fig.2(b));opalsZColor using -limit cornerShading is another type of visualization. There the surface normal is needed in each point, which requires an interpolation in any case.
In the following figures the effect of the -limit parameter with values center (=default) and corner are demonstrated in another example using color codings (note the smoothing effects for the corner outputs in Fig.5(b) due to interpolation) and shadings. Fig.4(a) shows a section of ALS points around a tree together with the limits of a ROI. Fig.4(b) shows the grid of that ROI obtained from the ALS points using Module Grid with the nearest neighbor interpolation. Fig.5(a) and (b) show the output of opalsZColor using using -limit center (=default) and using -limit corner respectively. Fig.6(a) and (b) show the respective output of opalsShade.
Module Grid using nearest neighbor interpolation (grid points are grey colored)
Observe: If the corner output created in the above example (i.e. Fig.5(b) or Fig.6(b)) would be used as input again for an OPALS module the input limit would be smaller by half a pixel (on all four edges) compared to the original grid used for this example.
Representing the terrain of a country or the entire world in a single file is unfeasible. Instead, the representation is normally distributed over several files of equal size (called tiles). Each tile is defined by its own limits (Xmin, Ymin, Xmax, Ymax). See also FAQ on limit specification.
With respect to these tile limits the output of any OPALS module is per default a grid generated with -limit center in order to prevent extrapolation (see FAQ on -limit center vs. -limit corner). The consequence of this is that neighboring tiles will overlap by one column and one row of grid points. If instead the individual tile outputs should not overlap then use the parameter -limit corner. This, however, should only be done for raster visualizations like zcodings or shadings. Digital height models on the other hand should always be generated as grids with -limit center.
The output of an OPALS module can be a grid or an OPALS data manager file (ODM). The input can be a set of ODMs or a set of input grids. Depending on the types of input and output the limits of the output are derived by different defaults, but can also be defined by the user.
A) input: ODMs, output: grids
The limits by default:
The limits (Xmin_grd, Ymin_grd, Xmax_grd, Ymax_grd) for the output grid with spacing s are derived from the bounding box of the ODM input (Xmin_BB, Ymin_BB, Xmax_BB, Ymax_BB) in the following way:
Xmin_grd = s*round(Xmin_BB/s)
Ymin_grd = s*round(Ymin_BB/s)
Xmax_grd = s*round(Xmax_BB/s)
Ymax_grd = s*round(Ymax_BB/s)
By this default it is guaranteed that all grids computed for the same spacing s can be overlaid without interpolation.
User-defined limits:
You can specify your own limits using the limit parameter and the values (xmin,ymin,xmax,ymax); e.g.
If the given values (xmin,ymin,xmax,ymax) are odd with respect to the output spacing s (like in the example above), then the upper left corner is placed at the user given xmin and ymax, whereas ymin and xmax are adapted to be multiples of s.
If the user limits are uncertain (e.g. taken after manual digitization in a GIS or CAD software), then it may be a good idea to round the limits to multiples of s, in order to overlay different grids with the same grid size s without interpolation. This rounding with respect to s can be evoked using the round parameter; e.g.
which will effectively use the values (529635.0,5338606.0,529721.0,5338713.0).
If the output is a raster image (e.g. a visualization generated using opalsZColor or opalsShade), which should be completely inside the tile limits, then use the corner value; e.g.
or in combination with the round parameter; e.g.
See also the FAQ on -limit center vs. -limit corner.
B) input: grids, output: grids
The limits by default:
If only one input grid is given, then its limits are used for the output grid. If several input grids are given, then the output limit is defined by the intersection of all input limits.
The limits by the user:
The same options as in case A) are possible. Additionally, in case of several input grids, the output limit can also be defined to be the union of all input limits, or the limit of a specific input grid.
C) input: ODMs, output: ODMs
The same options as in case A) are possible, although the specification of corner or center is not taken into account.
D) input: grids, output: ODMs
The same options as in case A) are possible, although the specification of corner or center is not taken into account.
The geocoding is stored in tags in the header of the GeoTiff files; see http://trac.osgeo.org/geotiff/. This information may be inspected with e.g. listgeo or gdalinfo (both are available through the FWTools). If the global parameter create_option is set to TFW=YES, then OPALS additionally writes a tif world file, which is a text file containing the geocoding.
On the command-line, it is mandatory to quote (generic) filter strings if they contain blanks. Furthermore, it is necessary to quote the filter string, if any characters are used which might be misinterpreted by the command line parser as an operating system token (e.g. '<', '>', '|'...).
Example:
.. is invalid because it contains blanks and the "less than" operator, which is interpreted as the operating system's re-direction command. Thus,...
.. is invalid as well. Correct filter strings are:
A generic filter in opalsExport can be applied for this task. LAS 1.1-3 support the point data record formats 0..3, each of which is capable of handling no more than 7 returns per shot. Thus, to obtain a valid LAS file, some echoes need to be suppressed. Preserving the first and last echo is, generally, most important, so that a reasonable strategy is to keep the first 6 and the last echo and skip the rest. The following filter does the job:
-filter "generic[ EchoNumber<7 || EchoNumber==NrOfEchos; NrOfEchos = NrOfEchos>7 ? 7 : NrOfEchos; EchoNumber = EchoNumber>7 ? 7 : EchoNumber]"
Please note, that the above filter is applied to the exported points and, thus, does not change the attributes of the ODM. However, this would be the case when using the filter when reading point data into an ODM via opalsImport.
This should only happen, if you are using Firefox. Unfortunately, Firefox contains a bug that collapses multiple whitespaces when doing copy & paste. Since Python is an indent-oriented language (in opposition to languages using parentheses for grouping), it is necessary to preserve all whitespaces from documentation examples. Therefore it's recommended to use a different browser (Internet Explorer, Chrome, Opera, Safari, etc.) or use $OPALS_ROOT/doc/opals.chm help while testing the examples.
Chrome considers loading a local XML file referenced in a local XSL file as insecure (see e.g. here), even if the XML file is embedded into the XSL file itself, as is the case with OPALS log files. Moreover, instead of reporting an error message in the browser window, Chrome simply displays a blank window. To display OPALS log files, either use a different browser, or start Chrome with the argument –allow-file-access-from-files.
OPALS uses multiple attempts to validate CRS contained within its inputs. Most of the time, this warning is caused by invalid local coordinate reference system such as the following string
based on the BNF syntax of WKT, the minimally valid WKT string for local CRS contains the following nodes inside a LOCAL_CS node: LOCAL_DATUM, UNIT, at least one AXIS node
To resolve this issue, you can override the CRS (e.g. using EPSG code for WGS84 datum) used during module's execution using:
-force_coord_ref_sys -coord_ref_sys EPSG:4326
or using _setCRS.py python utility script to update the CRS of each input file (see Coordinate Reference Systems (CRS))
Yes. OPALS uses GDAL and PROJ for transforming between coordinate reference systems. Both libraries support the use of EPSG codes and the necessary resource files are contained in the OPALS distribution (addons/crs). The following command transforms a LAS file from national swiss reference system to ETRS89/UTM32:
1.8.17