To be useful, the millions or even billions of 3D points generated by a variety of active and passive sensors need to be stored, organised, combined, georeferenced, measured and analysed, and these tasks all require software. That the storage of billions of 3D points is an issue in itself is shown in the article by M. Kodde (Page 16).The LAS storage format, initially developed for airborne Lidar, has become a de facto standard. The more generic E57 format based on XML supports meta data, 2D imagery and a broad pallet of point attributes. Nevertheless, proprietary formats are often preferred as they are optimised for system-specific outputs.
A point cloud is a set of data points represented in a preferred coordinate system. Initially, the data is unorganised; software is designed to organise the unorganised and to extract information from it. Processing software may be general purpose and handle point clouds from a diversity of sensors, or it may be dedicated to specific outputs such as data acquired by terrestrial laser scanners (TLSs), airborne Lidar, mobile mapping systems (MMSs) or sonar. Manufacturers of point cloud-generating sensors have recognised that clients need to process the outputs of their sensors, and have complemented their hardware with proprietary software for managing, georeferencing, visualising, editing and exporting the outputs to dedicated software. Some software builders have spotted potential in offering tools for creating a broad pallet of end products from a particular sensor type such as Lidar, possibly combined with pixel data, from pixel data alone or sonar. Other packages stem from the other end of the spectrum, i.e. the application domains. For example, constructors who were used to a certain CAD system started to appreciate TLS point clouds and asked vendors to add modules for processing them. Some manufacturers discovered new opportunities along the way and built dedicated modules on top of one or more base modules aimed at, for example, the mining industry or 3D models of crash sites. This development process is far from complete, and new tools are being added all the time. However, a generic package which can handle all types of sensor output and generate all types of end product does not exist, because each package has its own peculiarities. Therefore, before purchasing software, it is not only important to look at the functionalities of the software, but also advisable to examine its design ideas, any current or planned extensions, its ability to join modules into one workflow, and interoperability with other software and services provided. On page 26 I present a survey on software aimed at the creation of DEMs or DSMs and products derived from these. This follows on from the first part in the series (published in the June issue) which focused on functionalities.
Make your inbox more interesting.Add some geo.
Keep abreast of news, developments and technological advancement in the geomatics industry.Sign up for free