| 46 | | LAG stands for [http://en.wikipedia.org/wiki/LIDAR LiDAR] Analysis GUI. It is a software which provides graphical user interface for processing and visualisation of LiDAR [http://en.wikipedia.org/wiki/Point_cloud point cloud] data. LAG is written in C++ and uses Gtk ([http://www.gtkmm.org/en/ gtkmm]) for its GUI, and [http://www.opengl.org/ OpenGL] for rendering. |
| 47 | | |
| 48 | | === 1.2 What are major components of LAG [=#q1.2] === |
| 49 | | |
| 50 | | LAG consist of the main GUI application and the Lidar Quadtree library used for storing and querying the data. It also uses laslib library for handling LAS files. |
| | 48 | LAG stands for [http://en.wikipedia.org/wiki/LIDAR LiDAR] Analysis GUI. It is a software which provides graphical user interface for processing and visualisation of LiDAR [http://en.wikipedia.org/wiki/Point_cloud point clouds]. LAG is written in C++ and uses Gtk ([http://www.gtkmm.org/en/ gtkmm]) for its GUI, and [http://www.opengl.org/ OpenGL] for rendering. |
| | 49 | |
| | 50 | === 1.2 What are the main components of LAG [=#q1.2] === |
| | 51 | |
| | 52 | LAG consist of the main GUI application and the Lidar Quadtree library used for storing and manipulating the data. It also uses laslib library for handling LAS files. |
| 54 | | The lag has been in development since 2009 and there were at least four different people working on it, each with different coding style, ideas and barely any supervision. It is now much better then it used to be, but it's easy to see that different parts have been written by different people. There also still seems to be a lot of temporary solutions which were never implemented properly, since they worked at the time. // |
| | 56 | The lag has been in development since 2009 and there were at least four different people working on it, each with different coding style, ideas and barely any supervision. It is now much better then it used to be, but it's easy to see that different parts have been written by different people. Some parts of the code contain temporary solutions which were never implemented properly, since they worked at the time. Just because they work though, doesn't mean they are good solutions in terms of efficiency, maintainability etc. There is still a lot of room for improvement. // |
| 58 | | Think before you code. Take users of your classes into consideration and try to design easy to use interfaces. Do some refactoring if you think it's going to make things easier to maintain, and to understand the code better. Use consistent coding style and comments. Try to learn good coding practices before you start writing the code (eg. implementing const correctness from the start is much easier then adding it once everything has been written). Profile your code instead of relying on what seems faster. |
| 59 | | |
| 60 | | === 1.5 Where can I learn good C++? [=#q1.5] === |
| 61 | | |
| 62 | | Whether you already know C++, come from C or are just starting to learn, it is a good idea to familiarise yourself with good programming practice before writing production code. Assuming you already know the basics of the language I highly recommend these two sources: |
| 63 | | |
| 64 | | [http://www.parashift.com/c++-faq-lite/ C++ FAQ] - every C++ programmer should read this at least once. It's well written, to the point and covers a lot of things from OO design to freestore management. |
| | 60 | Think first, code later. Take users of your classes into consideration and try to design easy to use and logical interfaces. Do some refactoring if you think it's going to make things easier to maintain, and to understand the code better. Use consistent coding style and comments. \\ \\ |
| | 61 | Try to learn good coding practices before you start writing the code. It is better to spend some time planning and then writing an implementation, then writing a code that just works and then trying to fix it. For example implementing const correctness from the start is much easier then adding it once everything has been written. \\ \\ |
| | 62 | Profile your code instead of relying on your intuition of what "should be" faster. Use OO principles for the benefit of more robust code (eg. use polymorphism instead of huge blocks of if statements). Use common sense. |
| | 63 | |
| | 64 | === 1.5 Where can I learn some good C++? [=#q1.5] === |
| | 65 | |
| | 66 | Whether you already know C++, come from C or are just starting to learn, it is a good idea to familiarise yourself with good programming practices before writing production code. Assuming you already know the basics of the language I highly recommend these two sources: |
| | 67 | |
| | 68 | [http://www.parashift.com/c++-faq-lite/ C++ FAQ] - every C++ programmer should read. It's well written, to the point and covers a lot of things from OO design to freestore management. |
| 80 | | LAS is a binary, public file format designed to hold LiDAR points data. An alternative to LAS are ASCII files, which are however less efficient in terms of both processing time and file size. \\ |
| 81 | | |
| 82 | | LAS files consist of several parts: Public Header Block, Variable Length Records, Point Records and in format 1.3 and later Waveform Records. \\ |
| 83 | | |
| 84 | | One thing to note about LAS is that point coordinates are stored as scaled integers and are then unscaled upon loading to double values with the use of scale factors and offsets stored in the header. |
| | 86 | LAS is a binary, public file format designed to hold LiDAR points data. One alternative to LAS are ASCII files(.csv or .txt), which are however less efficient in terms of both processing time and file size. \\ \\ |
| | 87 | |
| | 88 | LAS files consist of several parts: Public Header Block, Variable Length Records, Point Records and in format 1.3 and later Waveform Records. \\ \\ |
| | 89 | |
| | 90 | One thing to note about LAS is that point coordinates are stored as scaled integers and are then unscaled upon loading to double values with the use of scale factors and offsets stored in the header. \\ \\ |
| 95 | | There is no official documentation for laslib API, however it is a fairly well written C++ which provides an easy to use interface. The best way to learn laslib is to study the source code of programs included in lastools. |
| 96 | | |
| 97 | | The main classes of our interest are LASreader and LASwriter. A simple program that reads points from a file, filters out points with classification 7 (noise), prints points' coordinates and then saves them to another file may look like this (note there's no error checking or exception handling for simplicity, but you should always include it the real code): |
| | 103 | There is no official documentation for laslib API, however it is a fairly well written C++ which provides an easy to use interface. The best way to learn laslib is to study the source code of programs included in lastools. It is quite powerful and even provides its own tools for spatial indexing (totally undocumented though). \\ \\ |
| | 104 | |
| | 105 | The main classes of our interest are {{{LASreader}}} and {{{LASwriter}}}. A simple program that reads points from a file, filters out points with classification 7 (noise), prints points' coordinates and then saves them to another file may look like this (note there's no error checking or exception handling for simplicity, but you should always include it the real code): |
| 204 | | The Lidar Quadtree library provides a [http://en.wikipedia.org/wiki/Quadtree quadtree] data structure for storing and indexing points. It also contains a caching mechanism for loading and unloading points from memory. |
| 205 | | |
| 206 | | Each node of the quadtree represents a bounding box in x and y coordinates. Whenever a point is inserted into the quadtree it is determined which of the four nodes it falls into and then the same happens for each node recursively until a leaf node is found. Whenever the number of points in a node goes above the maximum capacity specified, the node splits into four. |
| | 213 | The Lidar Quadtree library provides a [http://en.wikipedia.org/wiki/Quadtree quadtree] data structure for storing and indexing points. It also contains a caching mechanism for loading and unloading points from memory. \\ \\ |
| | 214 | |
| | 215 | Each node of the quadtree represents a bounding box in x and y coordinates. Whenever a point is inserted into the quadtree it is determined which of the four nodes it falls into and then the same happens for each node recursively until a leaf node is found. Whenever the number of points in a node goes above the maximum capacity specified on creation of the quadtree, the node splits into four. \\ \\ |
| 229 | | The PointBucket class may hold copies of the same point in several arrays called sub-buckets. There are two parameters which control of how many sub-buckets are created: Resolution Depth and Resolution Base. 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 LAG 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^). // |
| 230 | | The reason for this is rendering of points. 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. Note that you could just pass every-nth point for rendering, but it is really the memory usage and caching issue that sub-buckets solve. // |
| 231 | | Because each resolution level effectively slowers the quadtree (some points need to be inserted n times into n arrays) for applications other then LAG, which make no use of sub-buckets Resolution Depth and Resolution Base should be set to 1. |
| | 238 | The {{{PointBucket}}} class may hold copies of the same point in several arrays called sub-buckets. There are two parameters which control of how many sub-buckets are created: //Resolution Depth// and //Resolution Base//. 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 LAG 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^). \\ \\ |
| | 239 | |
| | 240 | The reason for this is rendering of points. 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. Note that you could just pass every-nth point for rendering, but it is really the memory usage and caching issue that sub-buckets solve. \\ \\ |
| | 241 | |
| | 242 | Because each resolution level effectively slowers the quadtree (some points need to be inserted n times into n arrays) for applications other then LAG, which make no use of sub-buckets, //Resolution Depth// and //Resolution Base// should be set to 1. |
| 244 | | These should be removed at some point together with geoprojectionconverter. They are currently there only for backwards compatibility with other programs that use the quadtree (classify_las). \\ \\ |
| 245 | | |
| 246 | | From design point of view these classes should not be a part of the quadtree which should only serve as a data container. In practice, when these classes were used, making any changes in LAG regarding saving or loading files required alterations to the quadtree which was less then convenient. Now that loading and saving has been moved to separate classes inside LAG it is much more maintainable. Points inspection. \\ |
| | 259 | These should be removed at some point together with {{{geoprojectionconverter}}}. They are currently there only for backwards compatibility with other programs that use the quadtree (classify_las). \\ \\ |
| | 260 | |
| | 261 | From design point of view these classes should not be a part of the quadtree which should only serve as a data container. In practice, when these classes were used, making any changes in LAG regarding saving or loading files required alterations to the quadtree which was less then convenient. Now that loading and saving has been moved to separate classes inside LAG it is much more maintainable. Additionally it allows individual point inspection during loading and saving, which was not possiblebe before. |
| | 262 | |
| | 263 | ---- |