Technology Profile: Getting to the Point
Howard Butler didn’t set out to develop a comprehensive library for LiDAR data. Initially, his objective was much smaller: Develop a way to manage and manipulate LAS files for the Iowa Department of Natural Resources for use in Iowa’s state-wide LiDAR collection effort. “The Iowa DNR needed tools to allow them to manage and manipulate the thousands of LAS files they would be receiving from their contractor,” he explains. “They wanted the capabilities of Martin Isenburg's and Jonathan Shewchuk’s LAStools, but they also wanted the option of programmatically manipulating LAS files using the Python interpreter [a common programming language] and the geoprocessing that Esri’s ArcGIS provides.”
Butler, an experienced open source developer with previous projects, including the GDAL library and MapServer, believed an openly developed library was the best way to implement the required LAS file support. By making the software source code open and freely available, the software could continuously evolve to meet the changing needs of the users over time. Butler just didn’t know how broad that user base would become.
When Butler released the first version of the new LAS library, appropriately called libLAS, in 2008, it included support for reading ASPRS LAS 1.0-1.1 files along with C, C++ and Python application programming interfaces to allow programmers to easily manipulate files as needed. It also included some of the LAStools command-line utilities, such as las2las, which reads and writes LiDAR data in the ASPRS LAS 1.0 and 1.1 formats while modifying its contents; txt2las, which converts ASCII file and uses the 3rd, 4th and 5th entry of each line as the x, y and z coordinate of each point; lasmerge, which reads multiple LIDAR data files in the LAS format and merges them into a single file; and ts2las, which converts TerraSolid .bin files into LAS files. It was a useful resource for the Iowa DNR.
Meanwhile, the U.S. Army Corps of Engineers Cold Regions Research & Engineering Laboratory in Hanover, N.H., was taking interest in the software and supporting a number of additional improvements, such as the ability to work with Oracle point cloud data and handle vertical datum reprojection and description; enhanced spatial indexing; the development of a new Web site; and a nearly complete reengineering of what Butler terms “libLAS’ internals.” Other software developers, including ERDAS and Certainty 3D, also began to come onboard. Each new supporter further improved and strengthened the libLAS framework--and, subsequently, the LAS standard.
“The benefit of a specification is that it brings together all the aspects of LiDAR data that everyone within a certain group or committee has agreed upon,” Butler says. “But someone then has to write software to implement that specification. If you have 10 different types of LiDAR software written to work with this specification, there are potentially 10 different implementations, and it gets really ‘leaky.’ With libLAS, there’s a significant incentive for me to make sure I’m consistent with the work I’m doing with the software and also to be able to read everyone else’s files, even if they don’t meet the letter of the specification. The more people that use this software, the stronger it becomes, and the more it strengthens the specification and all the pieces of software that are using it because it makes their interoperability a known quantity.”
Most of the development work has occurred behind the scenes. Processing software is still needed to manipulate the data and create meaningful deliverables, and that’s where Certainty 3D’s TopoDOT, LizardTech’s LiDAR Compressor, ERDAS’ LPS eATE and other software comes into play. But as LiDAR continues to gain popularity as an efficient means of gathering geospatial data, interoperability among different software becomes increasingly important. From that perspective, a cycle of continuous improvement is imperative. “The goal is for users not to have to think about it,” Butler says.
It’s unclear how the recent approval of ASTM E57 laser scanning data exchange format (as ASTM standard E2761) will affect the LAS format. An open source library for E57 (libE57.org) has already been established and has garnered the support of a number of noteworthy vendors and users, although Butler notes that software with read/write support for E57 has yet to be released.
For now, the LAS file format remains in widespread use, and the challenge of how to easily access and use LAS files remains. Both behind the scenes as a software development tool and on the front lines as an open source LAS library, libLAS is having a ripple effect on LiDAR data accessibility and processing. Butler expects to release the next version of the software in October.
For more information about libLAS, visit www.liblas.org. Additional information about the LAS file format can be found here. More details about ASTM E57 can be found here.