Loading [MathJax]/extensions/tex2jax.js
Frequently asked questions

Table of Contents

This page contains a list of frequently asked questions. You can send your own OPALS related questions to: opals.nosp@m.@geo.nosp@m..tuwi.nosp@m.en.a.nosp@m.c.at.



How can I contact the OPALS developer team?

Please send an email to: opals@geo.tuwien.ac.at



What is the OPALS licensing policy?

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.



Can I get a test license of OPALS?

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



I am a student and want to use OPALS for my Bachelor/Master/PhD thesis. Can I get a free license?

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.



I want to contribute to the OPALS system by writing new modules or scripts. Can I obtain a free license?

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.



How can I get a short or detailed help on a specific module?

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.



How can I search through the OPALS Help pages? Full text

search is supported when using $OPALS_ROOT/doc/opals.chm, which is a Compiled HTML Help file or use the OPALS web page online.



How can I get rid of write and permission error messages when running any demo example?

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:

  1. re-install OPALS and make sure the the extra demo data option is selected.
  2. copy all demo files to a writable directory (the OPALS setup does exactly the same) and run the demo examples there.
  3. start the opalsShell as administrator which gives you write permissions to all program folders.



What can I do if there is a problem calling the Python bindings?

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 .



Starting PyScripter yields an error: Could not write file "...\remserver.py" and cannot use a remote Python engine. What to do?

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 .



What does the acronym "OPALS" mean?

OPALS stands for Orientation and Processing of Airborne Laser Scanning data.



What can I do if a module stops with the message 'std:exception: bad allocation'?

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).



What to do if a module stops with the message 'std:exception: Unable to load new data tiles. Try to increase the points in memory limit (using parameter -points_in_memory)'?

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).



What to do if a module stops with the message 'import site' failed; use -v for traceback?

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 .



The module output says that multiple threads are running, but the processor load is clearly below the expected value. Why is that?

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.



Is there a difference between grid and raster?

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.



What is the purpose of using the -limit parameter with value center or corner?

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).

Fig.1(a,b): (a) limits of a ROI;
(b) grid points

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.

Fig.2(a,b): (a) color coding of grid points;
(b) color coding of grid using pixels

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.

Fig.3(a,b): (a) opalsZColor using -limit center (=default) (same as Fig.2(b));
(b) opalsZColor using -limit corner

Shading 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.

Fig.4(a,b): (a) a section of ALS points around a tree together with the limits of a ROI;
(b) grid obtained by Module Grid using nearest neighbor interpolation (grid points are grey colored)


Fig.5(a,b): (a) opalsZColor using -limit center (=default);
(b) opalsZColor using -limit corner


Fig.6(a,b): (a) opalsShade using -limit center (=default);
(b) opalsShade using -limit corner

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.



How do I deal with tiles?

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.



How can I specify the output limits?

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.

opalsGrid -inFile strip11.odm -limit "(529634.5,5338605.9,529721.2,5338712.8)"

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.

opalsGrid -inFile strip11.odm -limit "round(529634.5,5338605.9,529721.2,5338712.8)"

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.

opalsZColor -inFile strip11_z.tif -limit "corner(529640,5338610,529720,5338710)"

or in combination with the round parameter; e.g.

opalsZColor -inFile strip11_z.tif -limit "corner=round=(529640.3,5338610.4,529719.6,5338710.3)"

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.



How is the geocoding stored for the output GeoTiff files?

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.



Why does my generic filter result in an error although the string strictly adheres to the filter syntax?

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:

-filter generic[z < 0]

.. is invalid because it contains blanks and the "less than" operator, which is interpreted as the operating system's re-direction command. Thus,...

-filter generic[z<0]

.. is invalid as well. Correct filter strings are:

-filter "generic[z<0]"
-filter "generic[z < 0]"



Can I store a point cloud with more than 7 echoes per laser pulse as LAS 1.1, 1.2 or 1.3?

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.



I copied & pasted examples from the documentation but the result looks different or it doesn't working. What's wrong?

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.



Having loaded a log file in Chrome, why is the browser window empty, displaying nothing?

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.



I received warning message "warning: Invalid CRS definition. Attempt to repair the CRS failed (Corrupt CRS data)."

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

LOCAL_CS["X-Y-Z",UNIT["metre",1,AUTHORITY["EPSG","9001"]]]

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

LOCAL_CS["some string", LOCAL_DATUM["some string followed by any number (this case -1)",-1], UNIT["unit name(metre)",1], AXIS["some axis name", NORTH]]

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



Can I use EPSG codes to transform data from one spatial reference system to another?

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:

opalsTranslate -inFile albis.laz -outFile albis_UTM32.laz -inCRS EPSG:21781 -outCRS EPSG:25832
opalsZColor is the executable file of Module ZColor
Definition: ModuleExecutables.hpp:253
@ helpHtml
open the HTML help specific to this module
opalsTranslate is the executable file of Module Translate
Definition: ModuleExecutables.hpp:238
@ helpChm
open the Compiled HTML Help specific to this module
opalsImport is the executable file of Module Import
Definition: ModuleExecutables.hpp:113
@ outCRS
output coordinate reference system as WKT/proj4 description string or EPSG code (opalsTranslate)
opalsGrid is the executable file of Module Grid
Definition: ModuleExecutables.hpp:93
@ filter
string to be parsed in construction of DM::IFilter (various modules)
@ inCRS
input coordinate reference system as WKT/proj4 description string or EPSG code (opalsTranslate)
@ help
print this usage screen: help on parameters specific to this module