Changes between Version 16 and Version 17 of Processing/laguserguide


Ignore:
Timestamp:
May 30, 2012 3:55:24 PM (7 years ago)
Author:
jaho
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Processing/laguserguide

    v16 v17  
    11= LAG User Guide =
    22
    3 The following guide provides an overview of some of the LAG features and offers hints on how to utilize them for the best processing speed. Some of these are just convenient methods of doing things while other can offer a significant performance boost. Most of the values discussed below have been set up for the optimal performance by default, however different data sets and tasks can benefit from different configurations.
     3The following guide provides an overview of LAG features and offers some hints on how to utilize them for the best processing efficiency. Some of these are just convenient methods of doing things while other can offer a significant performance improvement. Most of the values discussed below have been set up for the optimal performance by default, however different data sets and tasks can benefit from different configurations.
    44
    55== System Configuration ==
     
    1717There are following options on the file opener dialog:
    1818* **Point Skip Number**
    19     This value determines how many points to skip before loading a point into memory. Thus a value of 2 will cause every third point to load, skipping two in between. Point skipping can dramatically improve both loading times and rendering of the data. It is not recommended for processing, but there is no reason not to use it for delivery checking. A value between 1 and 4 will still provide a fairly detailed overview of the flightlines, while offering a significant performance increase.
     19    This value determines how many points to skip before loading a point into memory. Therefore a value of 2 will cause every third point to load, skipping two in between. Point skipping can dramatically improve both loading times and rendering of the data. It should not be used for processing, but there is no reason not to use it for delivery checking. A value between 1 and 4 will still provide a fairly detailed overview of the flightlines, while offering a significant performance increase.
    2020* **Fence**
    2121    Using the fence allows loading selected part of the flighline(s) into LAG. If there's only a small area in the data that you need to see in full detail, it is a good idea to load the whole data using point skipping, then select the area of interest with the fence in the overview window and click refresh on the file opener dialog after checking the //Use Fence// button.
    2222* **Resolution Base and Resolution Depth**
    23     These two values control the construction of the quadtree and directly affect both loading times and rendering speed of the data. Each leaf (point bucket) in the quadtree can have a number of sub-buckets which store points to display at different zoom level. For example when viewing a whole flightline in the overview window there is no need to render every single point or store all the points in memory at once. Thus sub-buckets containing every n-th point are used instead. \\
    24     The Resolution Depth determines the number of sub-buckets for each bucket and Resolution Base determines the number of points at each level by specifying the interval between included points based on the formula of Resolution Base^(Level - 1)^. For example the default values of 5 and 4 create 4 sub-buckets per bucket: one containing every point (5^0^), second containing every 5th point (5^1^), third containing every 25th point (5^2^) and fourth with every 125th point (5^3^). \\
    25     Adjusting these values should be done carefully and based on the density, volume and coverage of the data. Generally increasing the Resolution Base and decreasing Resolution Depth will result in faster loading and quadtree operations (eg. classifying), but less smooth rendering. Creating more and denser sub-buckets may improve the interaction with the GUI but at the cost of slower quadtree.
     23    These two values control the construction of the quadtree and directly affect both loading times and rendering speed of the data. Each leaf (point bucket) in the quadtree can have a number of sub-buckets which store points to display at different zoom levels. For example when viewing a whole flightline in the overview window there is no need to render every single point or store all the points in memory at once. Thus sub-buckets containing every n-th point are used instead. \\
     24    The Resolution Depth determines the number of sub-buckets for each bucket and Resolution Base determines the number of points at each level by specifying the interval between included points based on a formula of Resolution Base^(Level - 1)^. For example the default values of 5 and 4 create 4 sub-buckets per bucket: one containing every point (5^0^), second containing every 5th point (5^1^), third containing every 25th point (5^2^) and fourth with every 125th point (5^3^). \\
     25    Adjusting these values should be done carefully and based on the density, volume and coverage of the data. Generally increasing the Resolution Base and decreasing Resolution Depth will result in faster loading and quadtree operations (eg. classifying), but possibly slower rendering. Creating more and denser sub-buckets may improve GUI responsiveness but at cost of a slower quadtree.
    2626    For example for big flightlines that cover a vast area (like very long but thin lines, eg. 2011 29x London flights) it may be beneficial to create more sparse sub-buckets by increasing the Resolution Base. At the same time you can try to speed up loading times by decreasing the number of resolution levels, so values like 6 4 and 10 3 are worth testing.
    2727* **Points to hold in cache**
    28     This determines the maximum number of points to hold in memory at any given time. Once this number is exceeded the points will be written to the hard drive which is much slower then RAM. This only concerns the quadtree and LAG is going to use some more together with OpenGL buffer and Gtk application. This value should be set roughly to 25% of you total available memory. Setting it too high will result in system memory swapping and setting it too low will result in quadtree uncaching data to hard drive. Note that points stored in memory are roughly 40% bigger then stored in the LAS files, so loading a 1GB file requires 1.4GB buffer.
     28    This determines the maximum number of points to hold in memory at any given time. Once this number is exceeded the points will be written to the hard drive which is much slower then RAM. This only concerns the quadtree and LAG is generally going to need some more that the specified amount. This value should be set roughly to 25% of your total available memory. Setting it too high will result in system memory swapping and setting it too low will result in quadtree uncaching data to hard drive more often. Note that points stored in memory are bigger in size then those stored in the LAS files by roughly 40%, so loading a 1GB file requires 1.4GB buffer.
    2929* **Ascii files**
    30     To load ascii files you need to provide the parse string that gives the order and number of columns in the ascii file and scale factors for x, y and z. The default laslib scale factors for text files are 0.01. Default scale factors we used to use are 0.001, which are also default LAG values.
     30    To load ascii files you need to provide parse string that gives the order and number of columns in the ascii file and scale factors for x, y and z. The default laslib scale factors for text files are 0.01. Default scale factors we used to use are 0.001, which are also default LAG values.
    3131
    3232== Panning ==
     
    5252
    5353* **Full refresh when panning**
    54     By default, when panning, rendered buckets are automatically refreshed every time a mouse button is released which may sometimes be slow. To disable this behaviour you can uncheck //Full refresh when panning// button in advanced options. This will make moving the camera much faster, but you'll have to manually refresh the view (by pressing Z or clicking //Refresh//) once you set the desired perspective.
     54    By default, when panning, rendered buckets are automatically refreshed every time a mouse button is released which may sometimes be slow and possibly unnecessary if you're scrolling through a big area. To disable this behaviour you can uncheck //Full refresh when panning// button in advanced options. This will make moving the camera faster, but you'll have to manually refresh the view (by pressing Z or clicking //Refresh//) once you set the desired perspective.
    5555* **Detail level**
    56     These values determine how many points should be displayed at given zoom level. Eg. the lower the value for the main overview detail level, the faster LAG will start using the sparse sub-buckets to display the data when zooming out. In case of the profile the higher the value, the less detailed the data. Profile main detail level should generally be left at 0, as different values may result in inaccurate visualisation. Profile preview detail level determines how much of profile's points are visible while panning.
     56    These values determine how many points should be displayed at given zoom level. The lower the value for the main overview detail level, the faster LAG will start using the sparse sub-buckets to display the data when zooming out. In case of the profile the higher the value, the less detailed the data. Profile main detail level should generally be left at 0, as different values may result in inaccurate visualisation. Profile preview detail level determines how much of profile's points are visible while panning, fencing etc. Increasing this value should help if using fence seems very slow in case of huge/dense profiles.
    5757
    5858== Waveform Data ==
    59 While 1.3 point format is supported, LAG makes no use of waveform data. You can however open and modify LAS 1.3 files and waveform data will be preserved __as long as you save it to another file__. If you attempt to save it to the same file the waveform part of the data will be lost. Also trying to save 1.3 points loaded by using a fence will not work correctly yet (all waveform data will be copied over).
     59While 1.3 point format is supported, LAG makes no use of waveform data at the moment. You can however open and modify LAS 1.3 files and waveform data will be preserved __as long as you save it to another file__. If you attempt to save it to the same file the waveform part of the data will be lost. Also trying to save 1.3 points loaded by using a fence will not work correctly yet (all waveform data will be copied over).
    6060
    6161== Projections ==
    6262LAG currently supports UTM and latlong (or longlat: x = longitude, y = latitude) projections. By default files in both formats will be displayed using UTM coordinates. You can change it by going to //Tools >> Use latlong coordinates//.
    6363
    64 Latlong is generally a preferred projection because it doesn't require additional zone information. Latlong files can be saved as both latlong and UTM, while UTM files should not be converted, unless they contain projection information in the header's VLR geo keys. Alspp produced UTM files don't contain this information (they do but under wrong GeoKey) so this conversion should be avoided for the time being. Also latlong files seem to have higher precision than UTM files (up to around 10th of a milimeter), which is probably much higher than the actual lidar precision. By default this values are rounded to precision of 1 centimeter when converting latlong to UTM. To prevent precision loss you can select // Use full precision // option on file saver dialog, however this will result in bigger files.
     64Latlong is generally a preferred projection because it doesn't require additional zone information. Latlong files can be saved as both latlong and UTM, while UTM files should not be converted, unless they contain projection information in the header's VLR geo keys. Alspp produced UTM files don't contain this information (they do but under wrong GeoKeys...) so this conversion should be avoided for the time being. Also latlong files seem to have higher precision than UTM files (up to around 10th of a milimeter), which is probably much higher than the actual lidar precision. By default this values are rounded to precision of 1 centimeter when converting latlong to UTM. To prevent precision loss you can select // Use full precision // option on file saver dialog, however this will result in bigger files.
    6565
    6666== Other Options ==
     
    7272    This allows to only display points within given Z values range. When //Slice// option is enabled all operations, like loading a profile and classifying, will only apply to the points with elevation within specified range.
    7373* **Super Zoom**
    74     This option is useful for close points inspection. It makes zooming in and out faster by the factor of 10 and also increases the point size.
     74    This option is useful for close point inspection. It makes zooming in and out faster by the factor of 10 and also increases the point size.
    7575* **Heights**
    7676    Displays average Z values of points loaded into the profile and, in case of multiple flightlines, altitude differences between them in cm.