Changes between Version 9 and Version 10 of Processing/laguserguide

Timestamp:

Apr 23, 2012, 5:34:53 PM (13 years ago)

Author:

jaho

Comment:

--

Processing/laguserguide

@@ -5 +5 @@
 == System Configuration ==
 
-It is recommended that your system has at least 8GB of RAM for smooth LAG operation. It is also highly recommended that you have an [http://arsf-dan.nerc.ac.uk/trac/wiki/Processing/ssdsetup SSD drive set up] as the quadtree library used by LAG is heavily I/O bound, even more now with LAS 1.3 point format.
+It is recommended that your system has at least 8GB of RAM for smooth LAG operation. It is also highly recommended that you have an [http://arsf-dan.nerc.ac.uk/trac/wiki/Processing/ssdsetup SSD drive set up] as the quadtree library used by LAG is heavily I/O bound, even more now with LAS 1.3 format.
 
 == Opening Files ==
@@ -24 +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^). \\
     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 and bigger memory footprint.
-    For example for big flightlines that cover a vast area (like very long but thin lines, think 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.
+    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.
 * **Points to hold in cache**
-    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 much 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.
+    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.
 * **Ascii files**
     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.
@@ -63 +63 @@
 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 so this conversion should be avoided for the time being. Also latlong files seem to have higher precision than UTM files (up to about a 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 slightly bigger files.
 
-=== Test ===