The time issues associated with processing point clouds are extremely frustrating, but they are not new. And shifting boundaries mean we’re destined to always play the waiting game, according to Huibert-Jan Lekkerkerk, technical editor of GIM International, in his last column.
Although I am a hydrographer by trade, I understand all too well the problems that geospatial surveyors have with point clouds. Hydrography, as you may know, revolves largely around the measurement of depths, that is, “bathymetry”. Since joining this industry in the 1990s, I have been involved in what hydrographers call multibeam bathymetry: the underwater variant of lidar altimetry. The first instrument I used was a Reson 9001 capable of giving 60 depths per measure (‘swathe’) at about 15 swaths per second. In other words, it was producing around 900 depths per second. Today, such systems reach up to 1000 depths per band and 60 tapes per second, for a total of 60,000 depths per second. But back then, even 900 depths per second posed a big problem when it came to processing. A full day of investigations would take about half a day to process using our Pentium 75 processors with 8MB of memory (which at the time were state of the art!). Data transfer was performed using 4-speed CD-ROMs or 500MB portable hard drives.
Although the data was collected as a point cloud, we couldn’t process it that way, so it was meshed using a 1x1m2 grid of bins for example – and even that would sometimes tax the computer. At the turn of the millennium, I had a discussion with a software company who told me that their software could handle large sets of data with no problem. I replied that our project was to take 20 minute readings using a system that provided 256 depths per strip at 40 strips per second. In other words, a small survey would produce over 12 million points that needed to be visualized. Strangely enough, I never heard from this seller again…!
Today, the multibeam echosounder, Lidar or photogrammetry make these figures laughable. We now have the advantage that computers have gotten much faster, combined with cheaper data storage on a much larger scale… and yet the problems are still the same. For example, just a few weeks ago, I asked a student to prepare a presentation on photogrammetry. Since many students at our hydrographic school had returned from their internship explaining how they augmented their hydrographic surveys with drone data to connect the land and water parts, we had just purchased our first class A1 drone with a skinny 12MP camera and a basic GPS / Glonass / Galileo on board. This particular student had carried out many such surveys during his recent internship on a port extension project and had even acquired his drone pilot license. So, to demonstrate the processing workflow, he conducted an investigation at a dock near the college. He took about 140 photographs at 12MP, created ground control points which he surveyed using the college’s RTK system, and began processing his small reading (max. 30 minutes). He ended up with a truly impressive 3D model of around 12 million dots, but only after a considerable wait (albeit less than half a day). The main difference between today and two decades ago is that it didn’t need a state-of-the-art computer, but instead used its own trusty gaming laptop.
Bathymetric point cloud with AI-labeled rocks in red and seabed in blue.
I had arranged for one of my doctoral students to give a guest lecture to the same class. For his current thesis work on using artificial intelligence (AI) to detect rocks in point clouds of multibeam echosounders, he has built software in Python and is currently evaluating the accuracy of his tool. He had obtained a dataset of a few million data points and divided it into a training set and a “regular” set. At the guest lecture, he asked the students to help him verify the accuracy of his software by manually “clicking” on what they believed to be rocks using QPS Qimera hydrographic cloud processing software. . On their regular gaming laptops, it took them about 15 minutes for the entire dataset. He then ran his (unoptimized) software on 10% of the dataset, as that was the maximum his computer could handle at a time. The race lasted about five minutes. In addition to discovering that he has to fill a void of five minutes of class time while watching the status bar slowly advance, he has shown that performing elaborate treatment on a point cloud takes time, even today. hui.
In conclusion, the timing issues associated with point cloud processing have been around for decades, and every time we think we’re about to catch up, the boundaries change again: new sensors, new requirements or new tools. The only solution is to continue to strive for the balance between “acceptable” processing time and customer satisfaction. When it comes to processing point cloud data, it seems like we’re destined to always play the waiting game …
