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


Can I run OPALS under Linux?

Currently, OPALS is provided for MS Windows (XP, Vista, 7) only. However, a Linux version of OPALS is foreseen. For further information, please contact the OPALS team.


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 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 million) or to decrease the number of processing threads (parameter -nbthreads). If both options fail it is recommended to reimport 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 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 parallelisation may differ widely. Generally it can be said: the more complex task the better. However, we try to continuously improve the parallelisation 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).

roi+grid_s.png
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.

zcod_points+pixels.png
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.

zcod_pixels_center-corner.png
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 respectiv output of opalsShade.

als-poi+grid.png
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)


zcod-cen+corn.png
Fig.5(a,b): (a) opalsZColor using -limit center (=default);
(b) opalsZColor using -limit corner


shad-cen+corn.png
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?

For representing the terrain of a country or the entire world, not a single file can be used. Instead, the representation is 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 this 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.

The limits by the user:
You can specify your own limits using the -limit parameter and the values (xmin,ymin,xmax,ymax); e.g.

opalsGrid -inFile myfile.odm -gridSize 2 -limit (1721.1,338220.2,1780.3,338250.4)

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 myfile.odm -gridSize 2 -limit round(1721.1,338220.2,1780.3,338250.4)

which effectively will use the values (1722,338220,1780,338250).

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 mygrid.tif -limit corner (1720,338220,1780,338250)

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

opalsZColor -infile mygrid.tif -limit corner=round(1721.1,338220.2,1780.3,338250.4)

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 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 z<0

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

-filter "z<0"
-filter "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 not 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 collapes 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.