A 944Kb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE
I spent the week of the fourth of July at my lake cottage (a double wide trailer on the magnificent Tennessee River affectionately known as Casa Rio, where the cerveza is always cold) just relaxing. Of course, just relaxing actually meant studying some bathymetric and topographic LIDAR from the Joint Airborne LIDAR Technical Center of Excellence (JALBTCX), the bathymetric LIDAR collaborative center of the Army Corps of Engineers, Naval Oceanographic Service and NOAA. Still, I am able to sit in front of my laptop at the kitchen table with a panoramic view of the river.
Working with these data made me painfully aware of the single biggest mistake that we have made in the definition of the LAS specification; the reduction in available classes from 256 to 32 that occurred at LAS 1.1. The LAS Specification is the file format defined by the American Society for Photogrammetry and Remote Sensing LIDAR Working Group (LWG). There is some irony in this discussion since the original LAS specification (LAS 1.0) was developed by a small group of companies to support data ingest by none other than the Army Corps of Engineers!
LAS is a very simple binary format that consists of a header record, a series of point records and a few optional records for ancillary data such as coordinate system specifications. The heart of the specification is the point data records. Thus far, 11 varieties of Point Data Record Formats (PDRF) have been defined by the LWG. A PDRF specifies fields such as GPS time stamps, red-green-blue fields and so forth. One of the fields present in every PDRF is the Classification field. This field contains a bit limited integer that represents the data class such as Unclassified, Ground, Water, Wire and so forth.
LAS 1.0 was created by a small team of engineers from EnerQuest (who contributed the base file structure), Z/I Imaging (where I was at the time), Optech and Leica. We hammered out the original specification in a few weeks. A year or so later, we convinced the ASPRS to become custodian of the specification (since we wanted it to be fully open) and the LAS Working Group was born.
One of the first things the LWG addressed was the need to create flags on points that would designate an attribute that was orthogonal to Class. There were three main drivers:
Model Key Point (MKP)–this was a point in a surface that could not be thinned without violating an accuracy criteria (see Figure 1)
Withheld Points–These are points that one elects to withhold from the model such as noise points
Synthetic Points–These were points added to the data set that did not originate with the original LIDAR data collect. They were typically photogrammetrically derived "mass" points
By now the LWG was a committee and a debate ensued as to whether to keep the currently two defined PDRFs the same size (20 and 28 bytes) or to add a "flag" byte. For various reasons, the decision was to keep the size the same. This resulted in the Class byte (8 bits) being split with the upper three bits used for these three new flags and the lower five bits used for Class. This reduced the number of possible classes from 256 (0255) to 32 (031), the number of distinct combinations of 5 bits. This was considered a clever approach at the time since no one was using more than 5 or 6 classes and thus we were preventing file bloat. In retrospect, of course, we should have added two more PDRFs. However, there was a strong concern from some committee members to allow LAS 1.1 files to be read by LAS 1.0 readers and this would do the trick. Of course, hindsight is always 20/20!
As time moved forward, the need for more than 32 classes was driven by the shift to LIDAR for the modeling of electric transmission corridors. The desire was to classify a great variety of features from the wires themselves (which were segregated into classes such as Conductor A, Conductor B, Guard, etc.) to fence posts to connectors and, well, you get the idea.
Nearly everyone in North America who classified transmission lines (and some 450,000 linear miles were processed over a three year period) did so with TerraScan (a product from Terrasolid OY of Finland). TerraScan never did implement the classification flags and hence continued to allow 256 classes in the Class field. This really only became a problem with software that was rigidly compliant with the LAS specification.
Finally, with the advent of LAS 1.4 in November of 2011, the LWG added new PDRFs to support (once again) 256 classes and a separate byte for classification flags. A fourth flag bit was added for the USGS to indicate the overlap area between flight lines. With LAS 1.4 we did not modify the existing PDRFs, but added new ones starting with PDRF 6. LAS 1.4, PDRF 6 will shortly become the new standard for delivering LIDAR data. This will, in fact, be the format required by the USGS for the new 3D Elevation Program (3DEP) under the soon to be released version 1.1 USGS LIDAR Specification. While classes above 31 will not normally be required by the USGS, the new attribute flag, "Overlap" will be explicitly required.
It is likely that many software applications will not support LAS 1.4 by the time deliveries are required. So if you must use non-compliant software (usually because of staff training), how are you to deliver according to specification?
When flags bits are not available (as in TerraScan) the classification algorithm simply moves to what we might call a "compound" class. For example, we might use class 2 to represent ground (the ASPRS standard ground designation) and the base class plus 30 to represent the class with the overlap flag. Thus class 32 would represent a ground point that is in the overlap region (you immediately see how much less complex it is just to have class bits!). You can see that this gets pretty complicated if you need to represent a variety of flags (say overlap and model key point).
The scheme we are using for our own customers is rather simple and we recommend this for other software vendors as well. Our desktop LIDAR application, LP360, has fully supported LAS 1.4 since early 2012 (a few months following the approval of LAS 1.4). However, software processing applications are at the middle or backend of production. This means that a lot of data for 3DEP will be processed using software still at (most usually) LAS 1.2.
The first step was to add a tool to promote LAS 1.x to LAS 1.4 with the additional option of moving the renegade classes (applications that treated the flags as if they were the 3 high bits of class) to the full class range in PDRF 6. This is illustrated in Figure 2. Note that we are converting from LAS 1.2 and have set the option to treat the 3 flag bits and the 5 class bits as if they were 8 bits of class. This is the scheme used by TerraScan so we also call this the "TerraScan" format.
The final step to migrate this sort of data to a proper LAS 1.4 deliverable is to move the class back to the proper class and set the requisite flag bit. Most LAS software includes tools to do this sort of operation in a batch process. This operation in LP360 is depicted in Figure 3. Note that the Source Point filter dialog is shown where we have set the source as Class 32, the merged Ground/Overlap indicator (we might call this multiplexing). The destination is set to Class 2, the proper ground class and the destination flag (bit) of Overlap will be set.
My hope is that all software will soon be supporting LAS 1.4, PDRF 6 and above. At this stage, no one should ever specify a LAS delivery below PDRF 6 and all this confusion will be behind us!
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 944Kb PDF of this article as it appeared in the magazine complete with images is available by clicking HERE