A 1.331Mb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE
I have been the chair of the LAS Working Group (LWG) of the American Society for Photogrammetry and Remote Sensing (ASPRS) since the inception of LAS in 1999. This ubiquitous format has slowly evolved over the years (it is now in its fifth incarnation, LAS 1.4) to support new features added to commercial LIDAR collection systems. It has always been focused on kinematic collectors (the sensor is in motion during scanning) rather than static systems such as tripod scanners. In addition to LIDAR, LAS has become the de facto standard for encoding point cloud data from dense image matching such as processing of unmanned aerial systems projects.
Recently a lively discussion has begun regarding what needs to come next for the LAS format. Much of the discussion has centered on supporting non-commercial (at least in this point in time) sensors such as Geiger mode LIDAR or military packaging systems. While these application areas are tremendously interesting, they have no immediate impact on the bread and butter LAS customers–the commercial collectors and users of airborne and mobile laser scanning systems. Thus I thought I would devote this article to a few areas where I know we need new information in our LIDAR storage formats. Here I will discuss only the point flavor of LAS, not the waveform encoding. I’ve also only covered a few of the enhancements needed due to the limited space for this column.
"Ray Direction"— We need the point direction of each point in the file. That is, we need to know the incidence vector for each point. This is needed so that we can tell the "front" side of a ray impact as well as make estimates of radiance values and compute occlusions. With airborne data, we can general assume a top down impact. However, with mobile data, we cannot tell if we do not have the trajectory file associated with the acquisition. Figure 1 gives you an idea of this issue. Here we are looking up from under the road, obviously not the impact direction. This is an obvious example but imagine the case of a street sign in a mobile laser scanning data set.
Point Group Identification–This is the notion of points belonging to the same object. Consider classifying objects such as a roof or a tree. For example, in Figure 2 we see four buildings (one is just partial in the upper right of the figure) with roofs set to the building class (Class 6). We often need to know if points set to the roof class belong to the same building or to different buildings. Our current file format provides a generic "user byte" or an "extra byte" where this sort of information can be tagged but it really needs to be a base part of the specification. This will allow us to add an ontology to our data models.
Another very important use of the idea of group combined with class is to encode breakline vertices directly into the point data. For example, a water body flattening constraint could be introduced directly into the data by adding synthetic points (already supported in LAS) at the constraint boundary and encoding them with a group number to indicate their association and linkage.
Relative Accuracy–There have been discussions over the years regarding adding accuracy attributes to the data files. I think this is very important but it is a very difficult topic on which to converge to consensus. There is a school of thought that says meta information in the file header is adequate since the network accuracy at the file level is uniform (but then there are overlap edges….), some who want metadata per point and so forth. Again, this could currently be encoded with "extra bytes" in LAS 1.4 and this is sometimes done. I am more interested (from an algorithmic point of view) in relative accuracy. I need this information to tune automatic extraction algorithms such as a building roof extractor. Consider the roof segment of Figure 3. This is very noisy data of a roof segment (OK, it is not LIDAR–I used a very poor example from a dense image matching data set). The standard deviation of this segment is 1.7 feet. If I know this relative accuracy going in to the extractor algorithm, I can dramatically improve detection quality. This applies to many different LIDAR-based automate feature extraction algorithms.
So what is my point in all of this? Simply that there are many common applications of LIDAR data that can be improved by adding a bit (pun intended) of information at the point level of our data structures. The problem is that LAS is relatively compact and simple. We always face a trade-off between utility and complexity. Finding the balance is the challenge!
Lewis Graham is the President and CTO of GeoCue Corporation. GeoCue is North America’s largest supplier of LIDAR production and workflow tools and consulting services for airborne and mobile laser scanning.
A 1.331Mb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE