Energy-Saving Geospatial Data Storage—LiDAR Point Cloud Compression

Abstract

In recent years, the growth of digital data has been unimaginable. This also applies to geospatial data. One of the largest data types is LiDAR point clouds. Their large volumes on disk, both at the acquisition and processing stages, and in the final versions translate into a high demand for disk space and therefore electricity. It is therefore obvious that in order to reduce energy consumption, lower the carbon footprint of the activity and sensitize sustainability in the digitization of the industry, lossless compression of the aforementioned datasets is a good solution. In this article, a new format for point clouds—3DL—is presented, the effectiveness of which is compared with 21 available formats that can contain LiDAR data. A total of 404 processes were carried out to validate the 3DL file format. The validation was based on four LiDAR point clouds stored in LAS files: two files derived from ALS (airborne laser scanning), one in the local coordinate system and the other in PL-2000; and two obtained by TLS (terrestrial laser scanning), also with the same georeferencing (local and national PL-2000). During research, each LAS file was saved 101 different ways in 22 different formats, and the results were then compared in several ways (according to the coordinate system, ALS and TLS data, both types of data within a single coordinate system and the time of processing). The validated solution (3DL) achieved CR (compression rate) results of around 32% for ALS data and around 42% for TLS data, while the best solutions reached 15% for ALS and 34% for TLS. On the other hand, the worst method compressed the file up to 424.92% (ALS_PL2000). This significant reduction in file size contributes to a significant reduction in energy consumption during the storage of LiDAR point clouds, their transmission over the internet and/or during copy/transfer. For all solutions, rankings were developed according to CR and CT (compression time) parameters.

1. Introduction

On one hand, traditional incandescent light bulbs are being replaced by LEDs, resulting in savings in electricity consumption. On the other hand, however, we are seeing an increasing problem with light pollution of the surrounding space [1,2,3]. The same energy saving trends can be seen in transportation [4], industry [5,6], building maintenance [7], heavy industry [8], companies [9] and even at the household level [10,11,12].

The increasing demand for energy is also fuelled by the growing popularity of data centres [13,14,15]. Every packet of data and, ultimately, the information created from it require access to sensors. This applies whether it is in the field of digital twins [16], sea pollution [17] or real estate good governance principle support [18].

In the field of geospatial data, the development of measurement sensors means that we have more and more data with improving quality:

-

Scanners are working ever faster;

-

Point clouds are getting denser;

-

GDSs of orthophotos are getting smaller and smaller;

-

The resolution of remote sensing data is increasing;

-

Two-dimensional datasets are being developed into three-dimensional datasets;

-

Not only individual buildings, but entire towns and cities are being modelled;

-

Areas along roads are being covered with spherical images or LiDAR point clouds, e.g., Google Street View, HERE.

Geospatial data are used in a very wide range of issues including air pollution [19], land consolidation [20,21], building management [22], forestry [23], cadastre [24,25,26], spatial planning [27], BIM [28,29,30] and HBIM [31,32] modelling, smart villages [33,34], smart cities [35], estate valuation [36,37], mining [38,39], environment [40,41], urban greenery [42], geology [43], safety [44], offshore [45], tourism [46] and energy production infrastructure conditions such as wind turbines [47,48,49].

In addition, the above data are multiplied due to the updates performed. Also, the desire to access archive data contributes to the need for more storage space.

Energy is needed for data acquisition, processing and storage. Due to the mobility of the systems acquiring geospatial data, their energy requirements are constantly minimised; however, in terms of processing and storage, energy saving is not a key aspect. Therefore, the issues cited in the title appear to be important to explore and present.

The issue of LiDAR point cloud compression interested the corresponding author more than 10 years ago, as can be seen in the conference programme of the Polish Society for Photogrammetry and Remote Sensing in Poznan [50]. The results of the research presented at the above conference were not published in the form of an article, and the scope of the validation was not very wide, with only 10 formats being checked. The topic was, therefore, taken up again with a wider team of authors, with increased validation (22 formats) and a proposal for a new solution to this problem (3DL format).

The novelty presented in this paper is the 3DL format containing LiDAR data, which implements the authors’ preferred strategy of converting point clouds into smaller-volume files rather than just archiving them.

2. State of the Art

Today, the growth of digital data is enormous. As an indication of the scale of the challenge, Statista [51] reports that approximately 329 million TB of data are created every day. This amounts to approximately 2.3 ZB per week and 120 ZB per year. As information societies, we try to collect all kinds of data. On the one hand, the large volumes of the data collected provide opportunities for analysis, resulting in growth, but on the other hand, it involves risks and poses challenges. The same trend can be observed in the field of geospatial data. Examples include publications on reference datasets [20,52,53], orthophotos [54] and ISOK (an IT system for shielding the country from exceptional threats, mainly flood threats). This growing trend is supported by both the development of measurement units and the capacity to process large datasets.

There is, therefore, a real need for ways of storing digital data that save disk space without losing any of their content or functionality.

Airborne laser scanning (ALS), performed in Poland as part of the ISOK project between 2010 and 2015, may also be a good example [55]. Due to the lack of publicly available information, the authors estimated that during a single scan of 92% of Poland’s area, approximately 125 TB of resulting LiDAR ALS data were collected in the form of LAS files. Bearing in mind that within the framework of subsequent projects, a large portion of point clouds is updated and recipients would like to be able to access both current and archival data, the conversion of LAS collections to more efficient formats seems indispensable. Currently, ALS data in Poland are available at https://mapy.geoportal.gov.pl/imap/Imgp_2.html?gpmap=gp0 if you wish (accessed on 10 November 2024) as LAZ files.

ALS data cover very large areas (e.g., tens or secti square kilometres), but their accuracy and density are not the highest. If the client is interested in a cloud with a point density every few millimetres and the area/object is not too large, then LiDAR TLS (Terrestrial Laser Scanning) measurements should be performed. In addition to topographic applications [56,57], environmental [58,59,60] or forestry [61,62,63] LiDAR data are very often used in architecture or for inventory purposes of various objects [64,65,66,67,68,69,70], to create 3D BIM models of existing objects [71,72,73], mining [74], tourism [75] or 3D cadaster [76].

To speed up data acquisition, mobile laser scanning (MLS) can be used for objects for which the required accuracy is lower. Examples of applications of this technology in various fields are as follows: [77,78,79] urban environment, [80] road extraction, [81] cadastre, [82,83] forestry, [84] mining, [85] tunnelling or the low-cost version [86,87,88].

The smaller volume of LiDAR data reduces not only the need to prepare disk space for their storage, but also the smaller amount of data to be transmitted when visualising the data in the browser versions of programs or when downloading them.

The functionality of the ‘smaller’ files is also not insignificant. If we use a typical archiver to package LAS files, we create a copy of our data in compressed files. These can be stored in any way, anywhere. However, if we want to use them, they must be unpacked. This seemingly obvious example has implications in terms of volume (disk space), time (packing, unpacking and copying time) and energy consumption (see Figure 1). Longer data running times for archiving also mean increased electricity requirements.

Figure 1. Workflow of tasks in the LiDAR point cloud data storage strategy.

Therefore, it would be far better to save/convert LiDAR data into formats that are dedicated to them, and their reduced size does not result in the need for additional steps before reuse. A key question, then, is which data handling strategy will be more effective: LiDAR domain-specific compression algorithms and formats (such as LAZ), or general-purpose compression algorithms (such as ZIP or RAR).

Of course, it is impossible to overlook the role of software manufacturers here, who are essentially influencing the ‘popularity’ of data formats through their implementation in the software they produce (import and export functions). On the other hand, if the newly invented format were ‘revolutionary’ and extremely effective in terms of volume reduction, it would certainly find favour with software providers quite quickly.

On the technical side, lossy or lossless compression can be performed. Lossy can be used in cases where the loss of excess information after decompression is relatively harmless, e.g., video or audio. In the field of geospatial data, lossless compression is far more useful, where the reconstructed data sequence is identical to the source.

To perform lossless compression, various coding algorithms are used that modify the way data are represented to reduce their volume. These algorithms look for repetitions in the input data and replace them with shorter codes. In this way, the repeating patterns can be reconstructed after decompression, restoring the original file. One example of a lossless compression method is the Huffman algorithm. It involves assigning shorter codes to frequently occurring characters in the input data and longer codes for infrequently occurring characters. These codes are assigned in such a way that no interference is created in the decompression process. As a result, frequently used symbols receive short codes and rarely used symbols receive long codes.

The most popular formats offering lossless data compression are ZIP and RAR. In the case of the RAR format, compression algorithms are applied in two stages: compression and encoding. In the compression stage, the LZSS (Lempel–Ziv–Storer–Szymanski) algorithm, which is an adaptive dictionary algorithm, is used. At the encoding stage, Huffman coding is used, which assigns short binary codes to the most frequent symbols.

For the ZIP format, the primary compression algorithm is Deflate, which is a combination of the LZ77 algorithm and Huffman coding. The LZ77 algorithm uses a dictionary to replace repeated data sequences, while Huffman coding assigns short binary codes to the most frequent symbols

As already noted in 2013 in the publication [89], LiDAR data, by virtue of their size, are expensive to store and computationally intensive.

The LAS format was developed by ASPRS in LAS 1.0 in 2003, and with its publicly available description of the format, it has been recognised as the global standard for handling laser scanning data, adopted by manufacturers of scanning equipment, and point cloud processing applications and systems. It is currently being developed to LAS version 1.4.

Despite the development of the LAS format and its efficiency in storing LiDAR data, Martin Isenburg foresaw problems with the gigantic amount of laser scanning data and proposed the LAZ format in November 2011, describing it as follows: ‘As the sampling density of LiDAR increases so does the size of the resulting files. Typical LAS files contain tens to hundreds of millions points today, but soon, billions will be commonplace. The LAZ file format is a completely lossless compression scheme for LiDAR in binary LAS format versions 1.0 to 1.3. Encoding and decoding speeds are around one to three million points per second, and our compressed files are only 7–25% of the original file size. Compression and decompression happen on-the fly in a streaming manner, and random access is supported with a default granularity of 50,000 points. A reference implementation unencumbered by patents or intellectual property concerns is freely available with an LGPL license, making the proposed compression scheme suitable to become part of the LAS standard [90]’. From the 2011 quote above, there has indeed been an increase in the density and speed of LiDAR data acquisition; LAS data compression has been maintained and the format itself has become a common solution in many freeware and commercial software.

It is also worth noting that the purpose of developing the LAZ format was far broader than just reducing the volume of LiDAR files. As you can read in [91], Dr Isenburg was aware of the human impact on the world around him. The goal was not only the technology, but also its potential to improve the condition of our planet, e.g., to reduce the carbon footprint.

Research on the compression of LiDAR data has been carried out by [92], among others. In this study, 7-Zip, RAR, LASZip (LAZ) and the authors’ newly proposed format, LASComp, were tested. A performance analysis of the proposed solution was performed for a set of 13 ALS test files ranging from 97 MB to 930 MB in size. The following average compression ratio values were obtained: 22.4% for 7-Zip, 17.1% for RAR, 13.4% for LASZip (LAZ) and 11.8% for LASComp. However, neither the times required for compression nor the computer on which the calculations were performed are presented. This would certainly have given an overview of the computing power requirements of the solution. Despite the promising results in terms of CR and more than 10 years since the publication of these research results, the authors are not aware of software in which the LASComp format would be implemented.

An interesting approach is presented in the paper [93] where the LiDAR ALS cloud is first classified into trees and non-trees, and then a separate compression is performed for each class. The authors describe it as follows: ‘This paper proposes a new geometry-based LiDAR compression approach that can compress the data significantly while maintaining the geometric accuracy. For example, building boundaries are well preserved. Furthermore, its storage format provides meaningful semantic information and supports multiresolution access. To better evaluate the new geometry based compression method, we also implemented an image based compression scheme based on JPEG2000, i.e., we generate the depth image for 3D tree and building/ground data respectively, compress them by JPEG2000, and compare the imaged based compression with the proposed geometry based compression. Experimental results show that the proposed geometry-based airborne LIDAR compression performs much better than image-based compression. The compression performance is especially significant for building and ground data at lower bit rates’ [93]. After detailed analysis, it turns out that, for example, the edges of buildings are simplified by line fitting and then compress the boundary pixel location and plane parameters by WinZip or arithmetic encoder. As a result, ‘instead of recording all the boundary points, say 100 zigzag points, we only need to record the two end points to reduce the file size significantly without introducing much error’ [93].

The JPEG-2000 Standard was used to perform the compression of LiDAR ALS data also in the work [94]. Admittedly, the study carried out concerned ALS full-waveform (FWD) data, but the results presented are promising.

Interesting summaries and also detailed descriptions of various algorithms for the lossless compression of LiDAR data can be found in the work [95]. Although there is no author summary of the results with the obtained CR or CT (compression time) values, the publication deserves a mention.

Very interesting information and results, especially in the context of the results presented in Chapter 4 of this manuscript, can be found in the publication [96], as methodologically, it is the most convergent with the research presented below. It focuses on comparing only the final LAS files with LiDAR ALS clouds converted to other point cloud storage formats. Checks were made for the following formats: LASzip (LAZ), LASComp, LiDAR Compressor, 7-Zip, WinZip and WinRAR. Key metadata were provided for the seven test files: file size, number of points, density (pts/sq m) and bits per point (bpp). The results were assessed in terms of CR efficiency, calculated as compressed file size/original file size in percent, CT (compression time in seconds) and bits per point. Unfortunately, the hardware parameters of the set on which the conversions were performed were not given, so it is difficult to assess the CT. On the other hand, it is very good that the CT values were given, because despite not knowing the PC specifications, one can see the differences in CT between the formats. Also missing from the paper is information on which settings 7-Zip, WinZip and WinRAR compression was performed and in which specific programs. In terms of the CR, the following average results were achieved: LAZ—16.6%, LASComp—18.4%, LiDAR Compressor—20.8%, 7-Zip—24.1%, WinZip—39.3% and WinRAR—20.2%. Thus, it can be seen that LiDAR-dedicated formats are more efficient than general compression software, with the best of the general ones, WinRAR, achieving a score close to the worst dedicated one, the LiDAR Compressor. In terms of CT, the average times are as follows: LAZ—16.7 s, LASComp—164 s, LiDAR Compressor—44 s, 7-Zip—322 s, WinZip—163 s and WinRAR—48.7 s. For this parameter, the results are more varied, but the fastest is the compression to LAZ. As far as bpp is concerned, the order of the results coincides with CR.

Increasingly, LiDAR data compression issues, in addition to publications directly related to computer science, geoinformatics, photogrammetry, geodesy or heritage documentation, are appearing in robotics, automotive or autonomous vehicle navigation. The specificity of these works is a little different because they focus on data processing reliability, data processing speed and technical–technological aspects, and not, like geospatial works, on the compression of the resulting point clouds themselves or for archiving purposes [97,98].

An example is paper [99], where the authors ‘compare various low-level lossless compression algorithms that could be used in LiDAR sensors for a memory size reduction or improved bandwidth utilisation. The algorithm comparison performed using several factors such as an implementation complexity, compression speed and effectiveness. Finally, a simple, yet effective compression algorithm is proposed that could be beneficial for battery-powered robots, e.g., UAVs, and systems with a high frame rate requirements such as autonomous vehicles’. The algorithms being compared were as follows: DE—Delta Encoding, GRC—Golomb-Rice Compression, SSD—Symmetric Segmented Delta encoding and EDC—Extended Delta Compression. EDC performed the best with CR of 62% and 53%, depending on the test set.

The Delta Encoding algorithm for compressing LiDAR data also appears in the paper [100]. The authors called this solution as ‘RIDDLE (Range Image Deep DeLta Encoding)’ and describe it as ‘a data-driven algorithm to compress range images with predictive neural networks. This method is inspired by the use of Delta Encoding in PNG image compression’. As an evaluation of the effectiveness of the solution, they present a visualisation of reconstructed point clouds, coloured by per point Chamfer distance, for the G-PCC, Draco, PNG and RIDDLE algorithms with compression rates calculated as bits per point and reduced by almost eight times from 32 bpp to 4.02 bpp.

An interesting paper on the compression of LiDAR data in automotive applications is [101]. Compression is performed here using a recurrent neural network and residual blocks to progressively compress one frame’s information from the 3D LiDAR unit. Due to the measurement unit used (Velodyne HDL-32E) and the way the SLAM (Simultaneous Localisation And Mapping) data were assembled, it was possible to compress individual frames rather than the whole file. The effect of compression is described as Bitrate (bpp) and assessed by SNNRMSE (Symmetric Nearest Neighbour Root Mean Squared Error), expressed in cm. JPEG-based, Octree and the author’s RNN-based solution were tested, obtaining results of 2.04 bpp and 15.15 cm SNNRMSE for the RNN-based method, 4.04 bpp and 16.48 cm for the JPEG-based method, and 5.02 bpp and 15.49 cm for Octree compression.

In the paper [102], the quality of compression, i.e., the ratio of file sizes after and before compression, was called the compression factor. During testing, compression was performed using two data-independent methods: TUCKER [103] and P-TUCKER [104] vs. two data-dependent methods: RSTC [105] and SLiC. SLiC is a novel grouped wavelet technique developed by authors for static roadside LiDAR data compression. This method compresses LiDAR data both spatially and temporally using a kd-tree data structure based on Haar wavelet coefficients. The study was carried out on real (UNR and TAMU) and synthetic data. The difference from the previous mentioned publication is the position of the LiDAR data acquisition unit. In the examples cited so far, these were TLS (terrestrial laser scanning) or MLS (mobile laser scanning) clouds from a moving platform. In the case of this publication, the scanning unit is permanently mounted at the survey station. In this way, parts of the environment (buildings, road surfaces or infrastructure) can be considered as reference objects.

A very interesting, comprehensive and summarising paper on LiDAR data compression in automotive was published this year in Sensors [106]. Due to its review nature, it brings together work with results obtained in the field of the following:

-

Coding-based compression methods applied to LiDAR data;

-

Format-based compression methods (LAS and PCD format only);

-

Two-dimensional-based intra-frame compression methods;

-

Two-dimensional-based inter-frame compression methods;

-

Three-dimensional tree-based compression methods;

-

Sparse-tensor-based and point-based methods.

3. Materials and Methods

3.1. Materials

The test files were TLS and ALS data, each with a local and PL-2000 (EPSG:2178) coordinate system (CS), resulting in a total of 4 LiDAR point clouds. A brief overview is provided in Table 1.

Table 1. Overview of LiDAR point clouds in the LAS files used to conducting the research.

Name of File	ALS_LOK	ALS_PL2000	TLS_LOK	TLS_PL2000
Horizontal CS	Local CS	EPSG:2178	Local CS	EPSG:2178
File format	LAS 1.2	LAS 1.2	LAS 1.2	LAS 1.2
Size of file [byte]	540,096,009	540,096,009	623,973,543	623,973,545
Number of points	15,885,170	15,885,170	23,998,971	23,998,971
min X	−600.0000	7,474,400.0000	−135.0189	7,474,864.9811
max X	199.9900	7,475,199.9900	147.8851	7,475,147.8851
min Y	100.0000	5,638,000.0000	−78.8851	5,639,921.1149
max Y	599.9900	5,638,499.9900	186.2284	5,640,186.2284
min H	267.2700	267.2700	115.4018	115.4018
max H	359.5100	359.5100	184.3779	184.3779
min INT	37	37	6425	6425
max INT	4404	4404	65,279	65,279
Line	+	+	+	+
Echo	+	+	+	+
Color (RGB)	+	+	+	+
Time (GPS)	+	+	-	-
Scanner	+	+	+	+
Angle	+	+	+	+
Coords Prec.	0.0001	0.0001	0.0001	0.0001
Span by X	799.9900	799.9900	282.9040	282.9040
Span by Y	499.9900	499.9900	265.1135	265.1135
Span by H	92.2400	92.2400	68.9761	68.9761
Span by INT	4367	4367	58,854	58,854
Bytes per point	34	34	26	26

A visualisation of the above point clouds in colouring by RGB values is shown in Figure 2.

Figure 2. Visualisation by RGB values of the point clouds used for the survey. (A) Top view and (C) Vertical cross-section of an ALS point cloud; (B) top view and (D) vertical cross-section of a TLS point cloud.

The ALS data originated from Kielce City Hall and were acquired in 2019. The commissioning unit was the Office of the Smart City in Kielce City Hall. A point cloud with a nominal density of 20 pts/sq m was delivered with a height error of no more than 0.15 m.

The TLS cloud is one scanposition acquired by a Faro Focus s150 scanner at ‘1/4’ resolution, i.e., points every 6.1 mm @ 10 m from the scanner. In order to obtain complementary datasets, the original ALS point cloud from the PL-1992 CS (EPSG:2180) was transformed to the PL-2000 s7 CS (EPSG:2178), obtaining the ALS_2000 file. A second transformation was then performed on the X and Y coordinates, approximating the data to zero and creating a local CS (ALS_LOK). The TLS point cloud was originally in the local CS (TLS_LOK) and then a transformation was performed along the X and Y coordinates, obtaining the TLS dataset in the PL-2000 s7 CS (TLS_2000). No post-height transformations were performed on any of the clouds. Also, the range of additional data collected such as intensity (INT) or RGB values was not altered.

In terms of the precision of the coordinate recording, the ALS cloud in the original version was recorded to 2 decimal places, while for the study, the ALS clouds were recorded to the same precision as the TLS, i.e., to 4 decimal places, topping up the third and fourth places with zeros. TLS clouds were recorded with precision to four decimal places.

The ALS point cloud has an extent of approximately 800 × 500 m, which, with 15,885,170 points, gives approximately 39.7 pts/sq m. The TLS cloud at approximately 280 × 265 m, with the number of points, 23,998,971, gives approximately 320 pts/sq m. Obviously, due to the data acquisition perspective, these clouds differ from each other in terms of both density and uniformity. A summary of such differences using TLS and MLS clouds as an example is presented in the paper [78]. In this case, ALS clouds, which are sparser but more uniform, are contrasted with TLS clouds, which are heavily saturated with points in close proximity to the scanner, while single points are found at the boundaries of the file range. The above characteristics can be seen very well in Figure 2A,B.

3.2. Hardware, Software and Formats

The computer sets shown in Table 2 were used to carry out the tests. The letter designation of the computer used for every conversion is also included in the Table 3 with the compression results.

Table 2. Hardware units used to preparing conversions.

Unit	A	B	C
CPU	11th Gen Intel® Core™ i5-1135G7 @2.40 GHz 2.42 Ghz (Intel, Santa Clara, CA USA)	AMD Ryzen 5 2600 Six-Core 3.40 GHz (AMD, Santa Clara, CA USA)	Intel(R) Core(TM) i7-7800X CPU @ 3.50 GHz
RAM	8 GB	32 GB	128 GB
OS	Windows 11 Home 64	Windows 10 Pro 64	Windows 10 Pro 64
Type	laptop	PC	PC

During the study, 22 file formats (*.7z, *.bzip2, *.gzip, *.xz, *.zip, *.RAR, *.RAR4, *.pod, *.BIN, *.LAZ, *.TXT, *.E57, *.PCD, *.PN, *.PV, *.PNTS, *.PCD, *.XYZ, *.ASC, *.PTS, *.RPC, *.3DL) were checked in 8 software.

These 22 formats can be divided into 3 groups (see Figure 1):

-

General purpose compression algorithms (*.7z, *.bzip2, *.gzip, *.xz, *.zip, *.RAR, *.RAR4)—group 1 in Figure 1;

-

Compression algorithms specific to the LiDAR domain (*.pod, *.BIN, *.LAZ, *.E57, *.PCD, *.PN, *.PV, *.PNTS, *.PCD, *.PTS, *.RPC, *.3DL)—group 2 in Figure 1;

-

General/universal formats that do not have compression features (*.TXT, *.XYZ, *.ASC)—group 3 in Figure 1.

Most of the conversions were carried out on Set A using the following software: 7-Zip 23.0, WinRAR 6.24 x64, Bentley Pointools PODcreator 02.00.01.00, LAStools 1.0.0.0, CloudCompare 2.13 and FME Workbench 2022.1. Trimble RealWorks 12.1 was used on set B, while set C was used to convert LAS to 3dl. Detailed information about all 101 conversions are in the Table 3 in Section 4.

3.3. New LiDAR Data Format—3DL

This study also examines a new point cloud storage format (*.3dl) developed by 3Deling company under project number POIR.01.01.01-00-1283/17-00 from the Polish agency The National Centre for Research and Development. This proprietary solution developed under project ‘Development of software to optimise the process of creating project documentation based on data obtained as a result of terrestrial laser scanning, with particular emphasis on simplifying access and interpretation possibilities of point clouds, as part of Activity 1.1: R&D projects of enterprises of the Operational Programme Intelligent Development 2014–2020, co-financed by the European Regional Development Fund’. Although it is not yet available in other software besides 3Deling’s in-house software, it will be evaluated on a par with other commercial formats for storing LiDAR data. The conversion to 3DL format is a two-step process: first the *.las to *.pod conversion is performed and then *.pod to *.3dl.

The 3DL format is designed to efficiently store large point clouds. To obtain this efficiency, the points in this format are structured in a set of octrees data structure. This allows for quick access to points from any desired region of the cloud. The main part of the points is placed in leaf level of the octree. Some are also present in the trunk of the octree (level 0) to facilitate a quick draft view of the cloud, as they can be quickly accessed during the opening of the file. To achieve space efficiency, the compression method was used. The coordinates of the points are represented as 2 byte integers, calculated relative to their octree branch position. This way, the size of 3DL files is similar to the size of the pod files.

3.4. Methods

The test files prepared in the LAS format were subjected to compression using different software, into different formats (both listed in Section 3.2), and using different compression methods and grades. For each conversion, the parameters listed below were noted:

-

Software name;

-

The output file format;

-

Compression method;

-

The compression ratio (where different ones were available);

-

Compression time (from file properties);

-

Size of the compressed file;

-

Compression ratio expressed in %.

The compression ratio (CR) was calculated according to Formula (1):

$$\mathrm{CR}={\displaystyle \frac{\mathrm{file}\mathrm{size}\mathrm{after}\mathrm{compression}}{\mathrm{file}\mathrm{size}\mathrm{before}\mathrm{compression}}}\times 100\%$$

(1)

Time was recorded in the properties of each file as the difference between the time it was created and the time it was last modified.

Keeping in mind the two key aspects of this study, i.e., compression rate and compression time, two summaries/rankings were prepared, sorting the individual solutions from the best compressed to the worst compressed, and those that took the least time to perform the conversion to the longest processed. The complete rankings are provided in Table A1 and Table A2 for the compression ratio (CR) in Appendix A, and in Table A3 and Table A4 for the compression time (CT) in Appendix B. Moreover, a full set of information on all 101 conversions can be found in Table 3 in Section 4.

4. Results

In the eight software, conversions to 22 file formats were made for each of the four base LAS files. This gave a total of 404 results, which are shown in Table 3 below.

Table 3. Summary of the results. File size after conversion [in bytes] and compression rate (CR) in % for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000, respectively. Explanations below the table.

Software	Format	Degree of Compression	Compression Method	File Size After Conversion [bytes]	CR [%]	File Size After Conversion [bytes]	CR [%]	File Size After Conversion [bytes]	CR [%]	File Size After Conversion [bytes]	CR [%]	Hardware Unit
				ALS_LOK		ALS_PL2000		TLS_LOK		TLS_PL2000
				540,096,009		540,096,009		623,973,543		623,973,545
7-ZIP	7z	Fastest	LZMA2	183,853,138	34.04%	183,323,163	33.94%	287,664,584	46.10%	272,357,616	43.65%	A
			LZMA	183,312,951	33.94%	182,774,246	33.84%	285,769,978	45.80%	271,351,338	43.49%	A
			PPMd	203,769,786	37.73%	202,009,982	37.40%	245,953,764	39.42%	240,472,124	38.54%	A
			BZip2	223,270,463	41.34%	222,709,486	41.24%	262,281,337	42.03%	247,376,752	39.65%	A
		Fast	LZMA2	186,484,089	34.53%	186,034,629	34.44%	280,523,707	44.96%	270,878,191	43.41%	A
			LZMA	186,641,483	34.56%	186,190,500	34.47%	279,901,194	44.86%	270,716,765	43.39%	A
			PPMd	195,636,293	36.22%	194,180,492	35.95%	232,906,444	37.33%	224,313,535	35.95%	A
			BZip2	210,506,586	38.98%	209,879,182	38.86%	240,660,381	38.57%	230,580,968	36.95%	A
		Normal	LZMA2	160,275,668	29.68%	159,602,649	29.55%	243,765,412	39.07%	236,326,867	37.87%	A
			LZMA	160,153,984	29.65%	159,490,150	29.53%	242,327,364	38.84%	235,862,307	37.80%	A
			PPMd	190,125,420	35.20%	188,852,260	34.97%	227,342,981	36.43%	220,803,334	35.39%	A
			BZip2	208,165,021	38.54%	207,397,594	38.40%	238,120,582	38.16%	228,833,615	36.67%	A
		Maximum	LZMA2	160,243,507	29.67%	159,407,807	29.51%	241,172,710	38.65%	235,481,726	37.74%	A
			LZMA	160,070,590	29.64%	159,550,368	29.54%	240,303,864	38.51%	235,083,569	37.68%	A
			PPMd	187,800,551	34.77%	186,411,561	34.51%	226,328,091	36.27%	220,420,169	35.33%	A
			BZip2	208,137,370	38.54%	207,374,025	38.40%	237,624,119	38.08%	228,271,457	36.58%	A
		Ultra	LZMA2	159,877,328	29.60%	159,448,244	29.52%	239,172,881	38.33%	234,389,715	37.564%	A
			LZMA	160,175,956	29.66%	159,390,352	29.51%	239,039,985	38.31%	234,336,981	37.556%	A
			PPMd	189,726,182	35.13%	188,280,417	34.86%	224,523,525	35.98%	219,035,450	35.10%	A
			BZip2	208,120,217	38.53%	207,358,723	38.39%	237,490,696	38.06%	228,102,478	36.56%	A
	bzip2	BZip2	Fastest	223,270,293	41.34%	222,709,324	41.24%	262,281,191	42.03%	247,376,590	39.65%	A
			Fast	210,506,416	38.98%	209,879,020	38.86%	240,660,235	38.57%	230,580,806	36.95%	A
			Normal	208,164,851	38.54%	207,397,432	38.40%	238,120,436	38.16%	228,833,453	36.67%	A
			Maximum	208,137,200	38.54%	207,373,863	38.40%	237,623,973	38.08%	228,271,295	36.58%	A
			Ultra	208,120,047	38.53%	207,358,561	38.39%	237,490,550	38.06%	228,102,316	36.56%	A
	gzip	deflate	Fastest	242,246,293	44.85%	242,853,849	44.96%	351,633,352	56.35%	324,863,932	52.06%	A
			Normal	227,376,745	42.10%	228,933,501	42.39%	327,601,116	52.50%	304,665,243	48.83%	A
			Maximum	226,737,427	41.98%	228,334,717	42.28%	326,904,830	52.39%	304,002,413	48.72%	A
			Ultra	226,684,785	41.97%	228,289,365	42.27%	326,872,237	52.39%	303,984,848	48.72%	A
	xz	LAZM2	Fastest	183,867,724	34.04%	183,337,752	33.95%	287,681,464	46.10%	272,374,492	43.65%	A
			Fast	186,485,092	34.53%	186,035,636	34.44%	280,524,900	44.96%	270,879,364	43.41%	A
			Normal	160,275,832	29.68%	159,602,824	29.55%	243,765,640	39.07%	236,327,080	37.87%	A
			Maximum	160,243,540	29.67%	159,407,844	29.51%	241,172,768	38.65%	235,481,768	37.74%	A
			Ultra	159,877,216	29.60%	159,448,140	29.52%	239,172,792	38.33%	234,389,612	37.56%	A
	zip	Fastest	deflate	242,246,439	44.85%	242,853,991	44.96%	351,633,487	56.35%	324,864,074	52.06%	A
			deflate64	239,780,146	44.40%	240,034,578	44.44%	343,736,483	55.09%	322,368,465	51.66%	A
			BZip2	223,270,489	41.34%	222,709,512	41.24%	262,281,365	42.03%	247,376,778	39.65%	A
			LZMA	183,312,976	33.94%	182,774,271	33.84%	285,770,021	45.80%	271,351,379	43.49%	A
			PPMd	203,367,199	37.65%	201,395,803	37.29%	245,806,178	39.39%	240,053,742	38.47%	A
		Fast	deflate	242,246,439	44.85%	242,853,991	44.96%	351,633,487	56.35%	324,864,074	52.06%	A
			deflate64	239,780,146	44.40%	240,034,578	44.44%	343,736,483	55.09%	322,368,465	51.66%	A
			BZip2	210,506,612	38.98%	209,879,208	38.86%	240,660,409	38.57%	230,580,994	36.95%	A
			LZMA	186,641,508	34.56%	186,190,526	34.47%	279,901,237	44.86%	270,716,806	43.39%	A
			PPMd	196,704,570	36.42%	195,052,758	36.11%	234,031,036	37.51%	224,686,317	36.01%	A
		Normal	deflate	227,376,891	42.10%	228,933,643	42.39%	327,601,251	52.50%	304,665,385	48.83%	A
			deflate64	221,386,075	40.99%	222,247,617	41.15%	316,486,963	50.72%	298,794,503	47.89%	A
			BZip2	208,165,047	38.54%	207,397,620	38.40%	238,120,610	38.16%	228,833,641	36.67%	A
			LZMA	160,154,010	29.65%	159,490,176	29.53%	242,327,391	38.84%	304,002,555	48.72%	A
			PPMd	190,995,848	35.36%	189,864,697	35.15%	227,860,185	36.52%	220,537,514	35.34%	A
		Maximum	deflate	226,737,573	41.98%	228,334,859	42.28%	326,904,965	52.39%	304,002,555	48.72%	A
			deflate64	220,825,085	40.89%	221,718,157	41.05%	315,802,561	50.61%	298,197,834	47.79%	A
			BZip2	208,137,396	38.54%	207,374,051	38.40%	237,624,147	38.08%	228,271,483	36.58%	A
			LZMA	160,070,616	29.64%	159,550,394	29.54%	240,303,891	38.51%	235,083,594	37.68%	A
			PPMd	185,262,789	34.30%	184,133,350	34.09%	223,065,018	35.75%	217,823,847	34.91%	A
		Ultra	deflate	226,684,931	41.97%	228,289,507	42.27%	326,872,372	52.39%	303,984,990	48.72%	A
			deflate64	220,788,078	40.88%	221,692,570	41.05%	315,801,833	50.61%	298,177,167	47.79%	A
			BZip2	208,120,243	38.53%	207,358,749	38.39%	237,490,724	38.06%	228,102,504	36.56%	A
			LZMA	160,175,982	29.66%	159,390,378	29.51%	239,040,012	38.31%	234,337,006	37.56%	A
			PPMd	190,493,738	35.27%	189,254,440	35.04%	218,230,545	34.97%	212,636,602	34.08%	A
WINRAR	RAR		Fastest	248,632,947	46.03%	250,741,685	46.43%	308,882,765	49.50%	243,294,995	38.99%	A
			Fast	212,058,229	39.26%	212,071,730	39.27%	290,661,576	46.58%	242,338,900	38.84%	A
			Normal	204,240,439	37.82%	204,164,127	37.80%	288,836,516	46.29%	241,845,813	38.76%	A
			Good	204,476,717	37.86%	204,394,795	37.84%	288,191,560	46.19%	241,717,346	38.74%	A
			Best	204,535,539	37.87%	204,453,740	37.86%	287,906,673	46.14%	241,656,155	38.73%	A
	RAR4		Fastest	220,739,130	40.87%	220,962,487	40.91%	337,918,434	54.16%	317,688,959	50.91%	A
			Fast	209,366,617	38.76%	209,285,477	38.75%	295,952,185	47.43%	288,590,520	46.25%	A
			Normal	201,400,391	37.29%	201,315,342	37.27%	291,820,038	46.77%	242,792,560	38.91%	A
			Good	201,603,523	37.33%	201,516,359	37.31%	291,059,647	46.65%	242,610,617	38.88%	A
			Best	201,657,800	37.34%	201,573,129	37.32%	290,754,618	46.60%	242,561,844	38.87%	A
	ZIP		Fastest	237,750,598	44.02%	238,994,689	44.25%	352,152,581	56.44%	326,916,724	52.39%	A
			Fast	237,816,543	44.03%	239,071,430	44.26%	349,483,571	56.01%	325,381,129	52.15%	A
			Normal	238,397,787	44.14%	239,742,068	44.39%	339,856,868	54.47%	317,928,079	50.95%	A
			Good	239,149,513	44.28%	240,517,081	44.53%	338,998,624	54.33%	317,429,342	50.87%	A
			Best	239,643,282	44.37%	241,016,876	44.62%	338,799,956	54.30%	317,338,722	50.86%
BEN PODCR	pod		Precision to 1 mm	175,075,631	32.416%	175,075,839	32.42%	264,353,052	42.37%	264,352,842	42.37%	A
LASTOOLS	BIN		32	381,244,136	70.59%	381,244,136	70.59%	479,979,476	76.92%	479,979,476	76.92%	A
			64	381,244,136	70.59%	381,244,137	70.59%	479,979,477	76.92%	479,979,477	76.92%	A
	LAZ		32	80,739,471	14.95%	80,739,471	14.95%	290,783,953	46.60%	231,193,873	37.05%	A
			64	80,739,471	14.95%	80,739,472	14.95%	290,783,954	46.60%	231,193,874	37.05%	A
	TXT		32	1,006,883,110	186.43%	1,126,156,881	208.51%	1,029,311,815	164.96%	1,275,337,421	204.39%	A
			64	1,006,883,110	186.43%	1,126,156,882	208.51%	1,029,311,816	164.96%	1,275,337,422	204.39%	A
CC	BIN			762,492,977	141.18%	762,492,961	141.18%	767,970,080	123.08%	767,969,989	123.08%	A
	E57			303,128,576	56.12%	303,128,576	56.12%	457,958,400	73.39%	457,958,400	73.39%	A
	LAS			540,096,007	100.00%	540,096,007	100.00%	623,973,543	100.00%	623,973,543	100.00%	A
	PCD			826,029,199	152.94%	826,029,199	152.94%	863,963,233	138.46%	863,963,233	138.46%	A
	PN			381,244,080	70.59%	381,244,080	70.59%	575,975,304	92.31%	575,975,304	92.31%	A
	PV			254,162,720	47.06%	254,162,720	47.06%	383,983,536	61.54%	383,983,536	61.54%	A
	TXT			2,175,726,572	402.84%	2,295,000,343	424.92%	2,082,519,220	333.75%	2,328,913,212	373.24%	A
FME	LAS			540,096,007	100.00%	540,096,007	100.00%	623,973,473	100.00%	623,973,473	100.00%	A
	E57			191,418,368	35.44%	191,418,368	35.44%	289,189,888	46.35%	289,189,888	46.35%	A
	POD			194,778,689	36.06%	194,778,689	36.06%	288,775,701	46.28%	288,775,701	46.28%	A
	PNTS			238,277,666	44.12%	238,277,666	44.12%	359,984,681	57.69%	359,984,681	57.69%	A
	PCD			555,981,321	102.94%	555,981,333	102.94%	647,972,576	103.85%	647,972,585	103.85%	A
	XYZ			518,385,358	95.98%	518,171,363	95.94%	717,143,511	114.93%	951,340,542	152.46%	A
	BIN			444,784,816	82.35%	444,784,816	82.35%	575,975,360	92.31%	575,975,360	92.31%	A
TRW	ASC			341,396,159	63.21%	460,669,930	85.29%	449,596,220	72.05%	695,970,159	111.54%	B
	LAZ			191,352,292	35.43%	168,516,892	31.20%	285,072,896	45.69%	248,006,349	39.75%	B
	POD			291,032,709	53.89%	291,032,709	53.89%	432,896,049	69.38%	432,896,049	69.38%	B
	PTS			765,462,711	141.73%	884,736,482	163.81%	1,049,110,606	168.13%	1,295,504,598	207.62%	B
	RPC			361,845,854	67.00%	361,845,801	67.00%	471,210,401	75.52%	471,190,247	75.51%	B
3DL	3dl	3dl	Precision to 1 mm	174,767,275	32.36%	174,767,275	32.36%	263,998,190	42.31%	263,998,286	42.31%	C

Explanations: Softwares: TRW—TRIMBLE REALWORKS 12.1, CC—CloudCompare 2.13, BEN PODCR—Bentley PODCreator 02.00.01.00. Formats: CC BIN—CC entities, CC E57—E57 Cloud, CC PCD—PointCloud library Cloud, CC PN—Point + Normal Cloud, CC PV—Point + Value Cloud, CC TXT—ASCII FME E57—ASTM E57, FME PNTS—Cesium 3D point cloud, FME XYZ—Point Cloud txt, FME BIN—Terrascan, TRW LAZ—LAZzip Files 1.2, TRW PTS—PTS Files, TRW RCP—Autodesk ReCap Files.

Table 3. Summary of the results. File size after conversion [in bytes] and compression rate (CR) in % for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000, respectively. Explanations below the table.

Software	Format	Degree of Compression	Compression Method	File Size After Conversion [bytes]	CR [%]	File Size After Conversion [bytes]	CR [%]	File Size After Conversion [bytes]	CR [%]	File Size After Conversion [bytes]	CR [%]	Hardware Unit
				ALS_LOK		ALS_PL2000		TLS_LOK		TLS_PL2000
				540,096,009		540,096,009		623,973,543		623,973,545
7-ZIP	7z	Fastest	LZMA2	183,853,138	34.04%	183,323,163	33.94%	287,664,584	46.10%	272,357,616	43.65%	A
			LZMA	183,312,951	33.94%	182,774,246	33.84%	285,769,978	45.80%	271,351,338	43.49%	A
			PPMd	203,769,786	37.73%	202,009,982	37.40%	245,953,764	39.42%	240,472,124	38.54%	A
			BZip2	223,270,463	41.34%	222,709,486	41.24%	262,281,337	42.03%	247,376,752	39.65%	A
		Fast	LZMA2	186,484,089	34.53%	186,034,629	34.44%	280,523,707	44.96%	270,878,191	43.41%	A
			LZMA	186,641,483	34.56%	186,190,500	34.47%	279,901,194	44.86%	270,716,765	43.39%	A
			PPMd	195,636,293	36.22%	194,180,492	35.95%	232,906,444	37.33%	224,313,535	35.95%	A
			BZip2	210,506,586	38.98%	209,879,182	38.86%	240,660,381	38.57%	230,580,968	36.95%	A
		Normal	LZMA2	160,275,668	29.68%	159,602,649	29.55%	243,765,412	39.07%	236,326,867	37.87%	A
			LZMA	160,153,984	29.65%	159,490,150	29.53%	242,327,364	38.84%	235,862,307	37.80%	A
			PPMd	190,125,420	35.20%	188,852,260	34.97%	227,342,981	36.43%	220,803,334	35.39%	A
			BZip2	208,165,021	38.54%	207,397,594	38.40%	238,120,582	38.16%	228,833,615	36.67%	A
		Maximum	LZMA2	160,243,507	29.67%	159,407,807	29.51%	241,172,710	38.65%	235,481,726	37.74%	A
			LZMA	160,070,590	29.64%	159,550,368	29.54%	240,303,864	38.51%	235,083,569	37.68%	A
			PPMd	187,800,551	34.77%	186,411,561	34.51%	226,328,091	36.27%	220,420,169	35.33%	A
			BZip2	208,137,370	38.54%	207,374,025	38.40%	237,624,119	38.08%	228,271,457	36.58%	A
		Ultra	LZMA2	159,877,328	29.60%	159,448,244	29.52%	239,172,881	38.33%	234,389,715	37.564%	A
			LZMA	160,175,956	29.66%	159,390,352	29.51%	239,039,985	38.31%	234,336,981	37.556%	A
			PPMd	189,726,182	35.13%	188,280,417	34.86%	224,523,525	35.98%	219,035,450	35.10%	A
			BZip2	208,120,217	38.53%	207,358,723	38.39%	237,490,696	38.06%	228,102,478	36.56%	A
	bzip2	BZip2	Fastest	223,270,293	41.34%	222,709,324	41.24%	262,281,191	42.03%	247,376,590	39.65%	A
			Fast	210,506,416	38.98%	209,879,020	38.86%	240,660,235	38.57%	230,580,806	36.95%	A
			Normal	208,164,851	38.54%	207,397,432	38.40%	238,120,436	38.16%	228,833,453	36.67%	A
			Maximum	208,137,200	38.54%	207,373,863	38.40%	237,623,973	38.08%	228,271,295	36.58%	A
			Ultra	208,120,047	38.53%	207,358,561	38.39%	237,490,550	38.06%	228,102,316	36.56%	A
	gzip	deflate	Fastest	242,246,293	44.85%	242,853,849	44.96%	351,633,352	56.35%	324,863,932	52.06%	A
			Normal	227,376,745	42.10%	228,933,501	42.39%	327,601,116	52.50%	304,665,243	48.83%	A
			Maximum	226,737,427	41.98%	228,334,717	42.28%	326,904,830	52.39%	304,002,413	48.72%	A
			Ultra	226,684,785	41.97%	228,289,365	42.27%	326,872,237	52.39%	303,984,848	48.72%	A
	xz	LAZM2	Fastest	183,867,724	34.04%	183,337,752	33.95%	287,681,464	46.10%	272,374,492	43.65%	A
			Fast	186,485,092	34.53%	186,035,636	34.44%	280,524,900	44.96%	270,879,364	43.41%	A
			Normal	160,275,832	29.68%	159,602,824	29.55%	243,765,640	39.07%	236,327,080	37.87%	A
			Maximum	160,243,540	29.67%	159,407,844	29.51%	241,172,768	38.65%	235,481,768	37.74%	A
			Ultra	159,877,216	29.60%	159,448,140	29.52%	239,172,792	38.33%	234,389,612	37.56%	A
	zip	Fastest	deflate	242,246,439	44.85%	242,853,991	44.96%	351,633,487	56.35%	324,864,074	52.06%	A
			deflate64	239,780,146	44.40%	240,034,578	44.44%	343,736,483	55.09%	322,368,465	51.66%	A
			BZip2	223,270,489	41.34%	222,709,512	41.24%	262,281,365	42.03%	247,376,778	39.65%	A
			LZMA	183,312,976	33.94%	182,774,271	33.84%	285,770,021	45.80%	271,351,379	43.49%	A
			PPMd	203,367,199	37.65%	201,395,803	37.29%	245,806,178	39.39%	240,053,742	38.47%	A
		Fast	deflate	242,246,439	44.85%	242,853,991	44.96%	351,633,487	56.35%	324,864,074	52.06%	A
			deflate64	239,780,146	44.40%	240,034,578	44.44%	343,736,483	55.09%	322,368,465	51.66%	A
			BZip2	210,506,612	38.98%	209,879,208	38.86%	240,660,409	38.57%	230,580,994	36.95%	A
			LZMA	186,641,508	34.56%	186,190,526	34.47%	279,901,237	44.86%	270,716,806	43.39%	A
			PPMd	196,704,570	36.42%	195,052,758	36.11%	234,031,036	37.51%	224,686,317	36.01%	A
		Normal	deflate	227,376,891	42.10%	228,933,643	42.39%	327,601,251	52.50%	304,665,385	48.83%	A
			deflate64	221,386,075	40.99%	222,247,617	41.15%	316,486,963	50.72%	298,794,503	47.89%	A
			BZip2	208,165,047	38.54%	207,397,620	38.40%	238,120,610	38.16%	228,833,641	36.67%	A
			LZMA	160,154,010	29.65%	159,490,176	29.53%	242,327,391	38.84%	304,002,555	48.72%	A
			PPMd	190,995,848	35.36%	189,864,697	35.15%	227,860,185	36.52%	220,537,514	35.34%	A
		Maximum	deflate	226,737,573	41.98%	228,334,859	42.28%	326,904,965	52.39%	304,002,555	48.72%	A
			deflate64	220,825,085	40.89%	221,718,157	41.05%	315,802,561	50.61%	298,197,834	47.79%	A
			BZip2	208,137,396	38.54%	207,374,051	38.40%	237,624,147	38.08%	228,271,483	36.58%	A
			LZMA	160,070,616	29.64%	159,550,394	29.54%	240,303,891	38.51%	235,083,594	37.68%	A
			PPMd	185,262,789	34.30%	184,133,350	34.09%	223,065,018	35.75%	217,823,847	34.91%	A
		Ultra	deflate	226,684,931	41.97%	228,289,507	42.27%	326,872,372	52.39%	303,984,990	48.72%	A
			deflate64	220,788,078	40.88%	221,692,570	41.05%	315,801,833	50.61%	298,177,167	47.79%	A
			BZip2	208,120,243	38.53%	207,358,749	38.39%	237,490,724	38.06%	228,102,504	36.56%	A
			LZMA	160,175,982	29.66%	159,390,378	29.51%	239,040,012	38.31%	234,337,006	37.56%	A
			PPMd	190,493,738	35.27%	189,254,440	35.04%	218,230,545	34.97%	212,636,602	34.08%	A
WINRAR	RAR		Fastest	248,632,947	46.03%	250,741,685	46.43%	308,882,765	49.50%	243,294,995	38.99%	A
			Fast	212,058,229	39.26%	212,071,730	39.27%	290,661,576	46.58%	242,338,900	38.84%	A
			Normal	204,240,439	37.82%	204,164,127	37.80%	288,836,516	46.29%	241,845,813	38.76%	A
			Good	204,476,717	37.86%	204,394,795	37.84%	288,191,560	46.19%	241,717,346	38.74%	A
			Best	204,535,539	37.87%	204,453,740	37.86%	287,906,673	46.14%	241,656,155	38.73%	A
	RAR4		Fastest	220,739,130	40.87%	220,962,487	40.91%	337,918,434	54.16%	317,688,959	50.91%	A
			Fast	209,366,617	38.76%	209,285,477	38.75%	295,952,185	47.43%	288,590,520	46.25%	A
			Normal	201,400,391	37.29%	201,315,342	37.27%	291,820,038	46.77%	242,792,560	38.91%	A
			Good	201,603,523	37.33%	201,516,359	37.31%	291,059,647	46.65%	242,610,617	38.88%	A
			Best	201,657,800	37.34%	201,573,129	37.32%	290,754,618	46.60%	242,561,844	38.87%	A
	ZIP		Fastest	237,750,598	44.02%	238,994,689	44.25%	352,152,581	56.44%	326,916,724	52.39%	A
			Fast	237,816,543	44.03%	239,071,430	44.26%	349,483,571	56.01%	325,381,129	52.15%	A
			Normal	238,397,787	44.14%	239,742,068	44.39%	339,856,868	54.47%	317,928,079	50.95%	A
			Good	239,149,513	44.28%	240,517,081	44.53%	338,998,624	54.33%	317,429,342	50.87%	A
			Best	239,643,282	44.37%	241,016,876	44.62%	338,799,956	54.30%	317,338,722	50.86%
BEN PODCR	pod		Precision to 1 mm	175,075,631	32.416%	175,075,839	32.42%	264,353,052	42.37%	264,352,842	42.37%	A
LASTOOLS	BIN		32	381,244,136	70.59%	381,244,136	70.59%	479,979,476	76.92%	479,979,476	76.92%	A
			64	381,244,136	70.59%	381,244,137	70.59%	479,979,477	76.92%	479,979,477	76.92%	A
	LAZ		32	80,739,471	14.95%	80,739,471	14.95%	290,783,953	46.60%	231,193,873	37.05%	A
			64	80,739,471	14.95%	80,739,472	14.95%	290,783,954	46.60%	231,193,874	37.05%	A
	TXT		32	1,006,883,110	186.43%	1,126,156,881	208.51%	1,029,311,815	164.96%	1,275,337,421	204.39%	A
			64	1,006,883,110	186.43%	1,126,156,882	208.51%	1,029,311,816	164.96%	1,275,337,422	204.39%	A
CC	BIN			762,492,977	141.18%	762,492,961	141.18%	767,970,080	123.08%	767,969,989	123.08%	A
	E57			303,128,576	56.12%	303,128,576	56.12%	457,958,400	73.39%	457,958,400	73.39%	A
	LAS			540,096,007	100.00%	540,096,007	100.00%	623,973,543	100.00%	623,973,543	100.00%	A
	PCD			826,029,199	152.94%	826,029,199	152.94%	863,963,233	138.46%	863,963,233	138.46%	A
	PN			381,244,080	70.59%	381,244,080	70.59%	575,975,304	92.31%	575,975,304	92.31%	A
	PV			254,162,720	47.06%	254,162,720	47.06%	383,983,536	61.54%	383,983,536	61.54%	A
	TXT			2,175,726,572	402.84%	2,295,000,343	424.92%	2,082,519,220	333.75%	2,328,913,212	373.24%	A
FME	LAS			540,096,007	100.00%	540,096,007	100.00%	623,973,473	100.00%	623,973,473	100.00%	A
	E57			191,418,368	35.44%	191,418,368	35.44%	289,189,888	46.35%	289,189,888	46.35%	A
	POD			194,778,689	36.06%	194,778,689	36.06%	288,775,701	46.28%	288,775,701	46.28%	A
	PNTS			238,277,666	44.12%	238,277,666	44.12%	359,984,681	57.69%	359,984,681	57.69%	A
	PCD			555,981,321	102.94%	555,981,333	102.94%	647,972,576	103.85%	647,972,585	103.85%	A
	XYZ			518,385,358	95.98%	518,171,363	95.94%	717,143,511	114.93%	951,340,542	152.46%	A
	BIN			444,784,816	82.35%	444,784,816	82.35%	575,975,360	92.31%	575,975,360	92.31%	A
TRW	ASC			341,396,159	63.21%	460,669,930	85.29%	449,596,220	72.05%	695,970,159	111.54%	B
	LAZ			191,352,292	35.43%	168,516,892	31.20%	285,072,896	45.69%	248,006,349	39.75%	B
	POD			291,032,709	53.89%	291,032,709	53.89%	432,896,049	69.38%	432,896,049	69.38%	B
	PTS			765,462,711	141.73%	884,736,482	163.81%	1,049,110,606	168.13%	1,295,504,598	207.62%	B
	RPC			361,845,854	67.00%	361,845,801	67.00%	471,210,401	75.52%	471,190,247	75.51%	B
3DL	3dl	3dl	Precision to 1 mm	174,767,275	32.36%	174,767,275	32.36%	263,998,190	42.31%	263,998,286	42.31%	C

Explanations: Softwares: TRW—TRIMBLE REALWORKS 12.1, CC—CloudCompare 2.13, BEN PODCR—Bentley PODCreator 02.00.01.00. Formats: CC BIN—CC entities, CC E57—E57 Cloud, CC PCD—PointCloud library Cloud, CC PN—Point + Normal Cloud, CC PV—Point + Value Cloud, CC TXT—ASCII FME E57—ASTM E57, FME PNTS—Cesium 3D point cloud, FME XYZ—Point Cloud txt, FME BIN—Terrascan, TRW LAZ—LAZzip Files 1.2, TRW PTS—PTS Files, TRW RCP—Autodesk ReCap Files.

As described in the Methodology (Section 3.4), the key aspects of the studies conducted were the compression ratio (CR) and the time taken to perform the compression itself (CT). A detailed ranking of the results is presented in Appendix A, Table A1 and Table A2 for CR, and Appendix B, Table A3 and Table A4 for CT. A summary of the results, with the best and worst values, and their discussion are presented below.

Table 4 shows brief statistics characterizing the results obtained in terms of the compression rate and compression time.

Table 4. Statistics characterizing the results obtained in terms of the compression rate (CR) and compression time (CT) for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

	ALS_LOK		ALS_PL2000		TLS_LOK		TLS_PL2000
	CR [%]	CT [s]	CR [%]	CT [s]	CR [%]	CT [s]	CR [%]	CT [s]
min.	14.95%	1.0	14.95%	1.0	34.97%	1.0	34.08%	1.0
max.	402.84%	2655.0	424.92%	2521.0	333.75%	15,604.0	373.24%	10,149.0
avg.	51.71%	87.6	52.74%	85.7	57.97%	227.6	58.18%	172.5
median	38.54%	26.0	38.40%	25.0	46.28%	29.0	43.39%	31.0
std. dev.	46.71%	270.8	50.27%	257.5	39.11%	1548.0	46.96%	1006.5

With the best compression ratios, a significant reduction in the volume of the input files is achieved. For ALS data, this is almost a sevenfold volume reduction (from 100% to 14.95%), while for TLS data, it is almost three times. The best CRs for ALS data are also almost three times better than the mean and more than two times smaller than the median. For the TLS data, the differences are smaller and the best CRs are less than two times smaller than the mean values and only 50% lower than the median.

The other extreme of the results, i.e., the worst CRs are more than 4 times larger than the ALS input data and 3–4 times larger for the TLS data. Even greater variation between the min. and max. is achieved for CT from 1 s in the fastest version (for all input files) to more than 40 min for the ALS data, and 260 min and 169 min for the TLS data.

Table 5, Table 6, Table 7 and Table 8 were prepared to highlight the best and worst results for both CR and CT, with the best (Table 5) and worst (Table 6) solutions for CR, and the fastest (Table 7) and slowest (Table 8) solutions for CT selected for each.

Table 5. Top 10 solutions for the CR chosen from Table A1 and Table A2 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method			CR	Software	Format and Method			CR	Software	Format and Method			CR	Software	Format and Method			CR
1	LASTOOLS	LAZ		32	14.95%	LASTOOLS	LAZ		32	14.95%	7-ZIP	zip	Ultra	PPMd	34.97%	7-ZIP	zip	Ultra	PPMd	34.08%
2	LASTOOLS	LAZ		64	14.95%	LASTOOLS	LAZ		64	14.95%	7-ZIP	zip	max	PPMd	35.75%	7-ZIP	zip	max	PPMd	34.91%
3	7-ZIP	xz	LAZM2	Ultra	29.60%	7-ZIP	7z	Ultra	LZMA	29.51%	7-ZIP	7z	Ultra	PPMd	35.98%	7-ZIP	7z	Ultra	PPMd	35.10%
4	7-ZIP	7z	Ultra	LZMA2	29.60%	7-ZIP	zip	Ultra	LZMA	29.51%	7-ZIP	7z	Max	PPMd	36.27%	7-ZIP	7z	max	PPMd	35.33%
5	7-ZIP	7z	Max	LZMA	29.64%	7-ZIP	7z	Max	LZMA2	29.51%	7-ZIP	7z	Normal	PPMd	36.43%	7-ZIP	zip	Normal	PPMd	35.34%
6	7-ZIP	zip	Max	LZMA	29.64%	7-ZIP	xz	LAZM2	Max	29.51%	7-ZIP	zip	Normal	PPMd	36.52%	7-ZIP	7z	Normal	PPMd	35.39%
7	7-ZIP	7z	Normal	LZMA	29.65%	7-ZIP	xz	LAZM2	Ultra	29.52%	7-ZIP	7z	Fast	PPMd	37.33%	7-ZIP	7z	Fast	PPMd	35.95%
8	7-ZIP	zip	Normal	LZMA	29.65%	7-ZIP	7z	Ultra	LZMA2	29.52%	7-ZIP	zip	Fast	PPMd	37.51%	7-ZIP	zip	Fast	PPMd	36.01%
9	7-ZIP	zip	Ultra	LZMA	29.66%	7-ZIP	7z	Normal	LZMA	29.53%	7-ZIP	bzip2	BZip2	Ultra	38.06%	7-ZIP	bzip2	BZip2	Ultra	36.56%
10	7-ZIP	zip	Ultra	LZMA	29.66%	7-ZIP	zip	Normal	LZMA	29.53%	7-ZIP	7z	Ultra	BZip2	38.06%	7-ZIP	7z	Ultra	BZip2	36.56%

The most effective in terms of file size reduction for ALS data was the LAZ format with a conversion performed in LASTOOLS 1.0.0.0 software with almost seven times the file size reduction. It is also worth noting that the ‘next’ solution (3rd place, 7-ZIP 23.0 software) is twice as bad, with a CR of 30%. For TLS data, the first two places went to ZIP format files prepared in 7-ZIP software, while the remaining places were also taken by 7-ZIP solutions for other formats. The differences in CR within the TOP 10 for TLS data are no greater than 2–3%. It is noteworthy that out of the 40 results in Table 5, 36 places were taken by the results from 7-ZIP software, i.e., software from the ‘general’ group. This demonstrates the high flexibility of the compression capabilities of generic file-volume-reduction algorithms. The LAZ from the LASTOOLS result, on the other hand, demonstrates the high degree of sophistication of the developed algorithm.

Table 6. Worst 10 solutions for the CR chosen from Table A1 and Table A2 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method		CR	Software	Format and Method		CR	Software	Format and Method		CR	Software	Format and Method		CR
92	FME	XYZ	TXT	95.98%	FME	XYZ	TXT	95.94%	FME	LAS		100.00%	CC	LAS		100.00%
93	CC	LAS		100.00%	CC	LAS		100.00%	CC	LAS		100.00%	FME	PCD		103.85%
94	FME	LAS		100.00%	FME	LAS		100.00%	FME	PCD		103.85%	TRW	ASC		111.54%
95	FME	PCD		102.94%	FME	PCD		102.94%	FME	XYZ	TXT	114.93%	CC	BIN		123.08%
96	CC	BIN		141.18%	CC	BIN		141.18%	CC	BIN		123.08%	CC	PCD		138.46%
97	TRW	PTS		141.73%	CC	PCD		152.94%	CC	PCD		138.46%	FME	XYZ	TXT	152.46%
98	CC	PCD		152.94%	TRW	PTS		163.81%	LASTOOLS	TXT	32	164.96%	LASTOOLS	TXT	32	204.39%
99	LASTOOLS	TXT	32	186.43%	LASTOOLS	TXT	32	208.51%	LASTOOLS	TXT	64	164.96%	LASTOOLS	TXT	64	204.39%
100	LASTOOLS	TXT	64	186.43%	LASTOOLS	TXT	64	208.51%	TRW	PTS		168.13%	TRW	PTS		207.62%
101	CC	TXT		402.84%	CC	TXT		424.92%	CC	TXT		333.75%	CC	TXT		373.24%

Table 6. Worst 10 solutions for the CR chosen from Table A1 and Table A2 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method		CR	Software	Format and Method		CR	Software	Format and Method		CR	Software	Format and Method		CR
92	FME	XYZ	TXT	95.98%	FME	XYZ	TXT	95.94%	FME	LAS		100.00%	CC	LAS		100.00%
93	CC	LAS		100.00%	CC	LAS		100.00%	CC	LAS		100.00%	FME	PCD		103.85%
94	FME	LAS		100.00%	FME	LAS		100.00%	FME	PCD		103.85%	TRW	ASC		111.54%
95	FME	PCD		102.94%	FME	PCD		102.94%	FME	XYZ	TXT	114.93%	CC	BIN		123.08%
96	CC	BIN		141.18%	CC	BIN		141.18%	CC	BIN		123.08%	CC	PCD		138.46%
97	TRW	PTS		141.73%	CC	PCD		152.94%	CC	PCD		138.46%	FME	XYZ	TXT	152.46%
98	CC	PCD		152.94%	TRW	PTS		163.81%	LASTOOLS	TXT	32	164.96%	LASTOOLS	TXT	32	204.39%
99	LASTOOLS	TXT	32	186.43%	LASTOOLS	TXT	32	208.51%	LASTOOLS	TXT	64	164.96%	LASTOOLS	TXT	64	204.39%
100	LASTOOLS	TXT	64	186.43%	LASTOOLS	TXT	64	208.51%	TRW	PTS		168.13%	TRW	PTS		207.62%
101	CC	TXT		402.84%	CC	TXT		424.92%	CC	TXT		333.75%	CC	TXT		373.24%

In terms of the least CR-efficient results presented in Table 6, in principle, almost all (except *.TXT from FME) failed to do their job, i.e., they did not compress the data from the input files. This refers to 31 solutions out of the 40 presented in Table 6. As expected, the worst format for storing LiDAR data, whether ALS or TLS and regardless of the conversion software, turned out to be *.TXT (12 out of 31 results). In addition, *.TXT from CloudCompare is almost double or more than double the size of *.TXT from LASTOOLS, depending on the underlying file. Due to the internal design (a text file with an added line about the number of points in the file), the *.PTS format also appears in this comparison. The same can be said for the *.XYZ, *.ASC and *.PCD formats.

Additionally, the CloudCompare 2.13 and FME Workbench 2022.1 software were checked for reading and writing the *.LAS format. Before and after writing, the file sizes are identical, which means that the above-mentioned software did not ‘cut’ anything from the data, nor did it add anything ‘from itself’ to the new files.

Table 7. Top 10 solutions for the CT chosen from Table A3 and Table A4 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method		Time	Software	Format and Method		Time	Software	Format and Method		Time	Software	Format and Method		Time
1	CC	PV		1	CC	BIN		1	CC	BIN		1	FME	PCD		1
2	FME	LAS		1	CC	PN		1	CC	PN		1	CC	PN		2
3	FME	E57		1	FME	LAS		1	FME	LAS		1	CC	PV		2
4	FME	PNTS		1	FME	PCD		1	FME	PCD		1	FME	LAS		2
5	FME	PCD		1	LASTOOLS	BIN	32	2	LASTOOLS	BIN	32	2	FME	BIN	Terrascan	2
6	LASTOOLS	BIN	32	2	LASTOOLS	BIN	64	2	LASTOOLS	BIN	64	2	LASTOOLS	BIN	32	3
7	LASTOOLS	BIN	64	2	CC	PV		2	CC	PV		2	LASTOOLS	BIN	64	3
8	CC	BIN		2	FME	BIN		2	FME	E57		3	FME	E57		3
9	CC	PN		2	WINRAR	RAR4	Fastest	3	FME	BIN	Terrascan	3	CC	BIN		4
10	FME	BIN		2	FME	E57		3	WINRAR	RAR4	Fastest	4	WINRAR	RAR	Fastest	5

Table 7. Top 10 solutions for the CT chosen from Table A3 and Table A4 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method		Time	Software	Format and Method		Time	Software	Format and Method		Time	Software	Format and Method		Time
1	CC	PV		1	CC	BIN		1	CC	BIN		1	FME	PCD		1
2	FME	LAS		1	CC	PN		1	CC	PN		1	CC	PN		2
3	FME	E57		1	FME	LAS		1	FME	LAS		1	CC	PV		2
4	FME	PNTS		1	FME	PCD		1	FME	PCD		1	FME	LAS		2
5	FME	PCD		1	LASTOOLS	BIN	32	2	LASTOOLS	BIN	32	2	FME	BIN	Terrascan	2
6	LASTOOLS	BIN	32	2	LASTOOLS	BIN	64	2	LASTOOLS	BIN	64	2	LASTOOLS	BIN	32	3
7	LASTOOLS	BIN	64	2	CC	PV		2	CC	PV		2	LASTOOLS	BIN	64	3
8	CC	BIN		2	FME	BIN		2	FME	E57		3	FME	E57		3
9	CC	PN		2	WINRAR	RAR4	Fastest	3	FME	BIN	Terrascan	3	CC	BIN		4
10	FME	BIN		2	FME	E57		3	WINRAR	RAR4	Fastest	4	WINRAR	RAR	Fastest	5

As far as CT is concerned, the top 10 fastest conversions are very close in terms of the time for ALS data—1 to 2–3 s and only close for TLS data—1 to 4–5 s. Among the formats, BIN dominates here (16 out of 40 results), and among the software, FME (17 out of 40 results). In only two cases, the last places in the top 10 for TLS data were taken by generic solutions (RAR4 from WINRAR), the rest being formats dedicated to LiDAR data.

Table 8. Worst 10 solutions for the CT chosen from Table A3 and Table A4 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method			Time	Software	Format and Method			Time	Software	Format and Method			Time	Software	Format and Method			Time
92	7-ZIP	xz	LAZM2	Ultra	197	7-ZIP	7z	Ultra	LZMA	197	7-ZIP	zip	max	LZMA	229	7-ZIP	zip	Ultra	PPMd	243
93	7-ZIP	zip	Ultra	LZMA	200	7-ZIP	zip	Ultra	LZMA	197	7-ZIP	7z	Ultra	LZMA	271	7-ZIP	7z	Ultra	LZMA2	258
94	7-ZIP	7z	Ultra	LZMA2	201	7-ZIP	7z	Ultra	LZMA2	199	7-ZIP	xz	LAZM2	Ultra	275	7-ZIP	xz	LAZM2	Ultra	258
95	7-ZIP	zip	max	PPMd	225	7-ZIP	zip	max	PPMd	222	7-ZIP	7z	Ultra	LZMA2	276	7-ZIP	7z	Ultra	LZMA	262
96	7-ZIP	gzip	deflate	Ultra	249	7-ZIP	gzip	deflate	Ultra	245	7-ZIP	gzip	deflate	Ultra	296	7-ZIP	zip	Ultra	LZMA	263
97	7-ZIP	zip	Ultra	deflate	249	7-ZIP	zip	Ultra	deflate	245	7-ZIP	zip	Ultra	PPMd	311	7-ZIP	zip	Ultra	deflate	306
98	7-ZIP	zip	Ultra	PPMd	250	7-ZIP	zip	Ultra	PPMd	251	7-ZIP	zip	Ultra	LZMA	330	7-ZIP	gzip	deflate	Ultra	307
99	7-ZIP	zip	Ultra	deflate64	275	7-ZIP	zip	Ultra	deflate64	266	7-ZIP	zip	Ultra	deflate	348	7-ZIP	zip	Ultra	deflate64	329
100	TRW	POD			514	TRW	POD			492	7-ZIP	zip	Ultra	deflate64	352	TRW	LAZ			403
101	TRW	RPC			2655	TRW	RPC			2521	TRW	RPC			15,604	TRW	RPC			10,149

Table 8. Worst 10 solutions for the CT chosen from Table A3 and Table A4 for all four base files: ALS_LOK, ALS_PL2000, TLS_LOK and TLS_PL2000.

Rank	Software	Format and Method			Time	Software	Format and Method			Time	Software	Format and Method			Time	Software	Format and Method			Time
92	7-ZIP	xz	LAZM2	Ultra	197	7-ZIP	7z	Ultra	LZMA	197	7-ZIP	zip	max	LZMA	229	7-ZIP	zip	Ultra	PPMd	243
93	7-ZIP	zip	Ultra	LZMA	200	7-ZIP	zip	Ultra	LZMA	197	7-ZIP	7z	Ultra	LZMA	271	7-ZIP	7z	Ultra	LZMA2	258
94	7-ZIP	7z	Ultra	LZMA2	201	7-ZIP	7z	Ultra	LZMA2	199	7-ZIP	xz	LAZM2	Ultra	275	7-ZIP	xz	LAZM2	Ultra	258
95	7-ZIP	zip	max	PPMd	225	7-ZIP	zip	max	PPMd	222	7-ZIP	7z	Ultra	LZMA2	276	7-ZIP	7z	Ultra	LZMA	262
96	7-ZIP	gzip	deflate	Ultra	249	7-ZIP	gzip	deflate	Ultra	245	7-ZIP	gzip	deflate	Ultra	296	7-ZIP	zip	Ultra	LZMA	263
97	7-ZIP	zip	Ultra	deflate	249	7-ZIP	zip	Ultra	deflate	245	7-ZIP	zip	Ultra	PPMd	311	7-ZIP	zip	Ultra	deflate	306
98	7-ZIP	zip	Ultra	PPMd	250	7-ZIP	zip	Ultra	PPMd	251	7-ZIP	zip	Ultra	LZMA	330	7-ZIP	gzip	deflate	Ultra	307
99	7-ZIP	zip	Ultra	deflate64	275	7-ZIP	zip	Ultra	deflate64	266	7-ZIP	zip	Ultra	deflate	348	7-ZIP	zip	Ultra	deflate64	329
100	TRW	POD			514	TRW	POD			492	7-ZIP	zip	Ultra	deflate64	352	TRW	LAZ			403
101	TRW	RPC			2655	TRW	RPC			2521	TRW	RPC			15,604	TRW	RPC			10,149

In Table 8, where the longest-compressing data formats are included, three things are noteworthy. The first is the overwhelming dominance of 7-ZIP (33 out of 40 results), with 23 out of 33 results being ultra-operation. The second point to note is the longest conversion times, independent of the base file, for the *.RCP format from Trimble RealWorks. Significantly, the times of up to 44 and 42 min for ALS data, and 260 and 169 min for TLS data are typically five times longer than the previous ranked result. It remains a matter for future research to see whether the ‘problem’ lies with TRW or the *.RCP format itself. The third issue is Trimble RealWorks as one of the two programs in Table 8. However, it is worth bearing in mind that. Trimble RealWorks was designed for point cloud registration and 3D modelling, not as a converter or data compression software. The availability of multiple output formats should rather be read as a plus and as an additional capability.

The 3Deling’s proprietary *.3DL format deserves a separate paragraph of comment. Comparing the results obtained for the *.3dl format in terms of the CR yielded place, the rankings are as follows: 15 out of 101 for ALS_LOK with a value of 32.36%, 16th place for ALS_PL2000 with a value of 32.36%, 38th place for TLS_LOK with a value of 42.31% and 48th place for TLS_PL2000 with a value of 42.31%. Comparing these results to others obtained by commercial and/or long-established formats, it can be said that they are good.

In terms of time, however, rankings are as follows: 34th for ALS data and 46th for TLS data. It is worth noting, however, that these conversions were performed on a different computer (Hardware Unit C) and also required double conversion (*.las to *.pod and then *.pod to *.3dl). If one was to look only at the last conversion (*.pod to *.3dl), then with a time of 5 s for ALS data, it would be places 14 and 12, and for TLS data with a time of 12 s, it would be 26 and 25.

Compared to the other formats in terms of compression efficiency and disk space savings, *.3dl performs better than the mean for each of the four files, as well as being in the second quartile. In terms of time, it scores in the middle of the pack (around 50th out of 101). It is worth noting that *.3dl, in the compression ranking for the TLS_LOK file, was in first place as regards dedicated point cloud formats. For the TLS_PL2000 file, it achieved the same result in terms of CR, which demonstrates the ‘robustness’ of the format to changes in the ‘length’ of the coordinates: around zero for TLS_LOK and around 7 million and 5 million for X and Y in TLS_PL2000. This is important as the *.3dl format was created to work with and store TLS data. The added value, on the other hand, is the very high rankings of ALS data as the second format dedicated to point clouds, second only to the LAZ solution.

5. Discussion

In order to critically analyse the results obtained, they were compared with the results described in other works. It is difficult to find the results of converting LiDAR data to the same formats in different works. From all the formats forfeited, it was possible to select three for which data exist in publications to count CR in %; these are the LAZ, RAR and ZIP formats. Table 9 brings together the results from other publications and the present study.

Table 9. Comparison of the CR results of the current study with the literature values.

	LAZ		ZIP		RAR
Isenburg	15.6%		50.0%		22.2%
Kotb	16.6%		39.3%		20.2%
AW2014 Poznan	19.7%		46.5%		42.6%
this research
ALS	14.9%	33.3%	34.0%	44.3%	39.8%	38.3%
TLS	41.8%	42.7%	43.8%	53.3%	42.9%	45.5%
	from LASTOOLS	from TRW	from 7-ZIP	from WINRAR	RAR from WINRAR	RAR4 from WINRAR

In both works of [90,96], as well as in the author’s preliminary research (2014, Poznan), the test files were ALS clouds. Therefore, the CRs overlap with the values achieved within the present study in LASTOOLS. Performing the LAS-to-LAZ conversion using Trimble RealWorks, the CR data were twice as bad. In terms of TLS data, the CR values are considerably worse with both LASTOOLS and Trimble RealWorks, but still offer a reduction in file volume of more than half.

In terms of the ZIP format, the obtained averaged results from all methods and modes for both 7-ZIP and WINRAR are close to the literature values. Only the conversion of ALS data in 7-ZIP CR data was slightly better than in the cited publications. In the case of the RAR format, CR values worse than in the cited literature were achieved, which encourages further research into the properties of this format.

Looking at all 404 conversions, it can be concluded that ALS data compress better than TLS data. This is the case in approximately 77% of the cases.

It is worth noting that no new format has emerged in the last 10 years that would reduce the size of LiDAR files in a revolutionary way.

The data compression issues that arise in automotive topics operate on LiDAR data, but with completely different characteristics. These are data recorded in a different SLAM manner and can therefore be compressed at the single-frame level. In addition, automotive data are of relatively low density compared to TLS data or classic MLS solutions like Riegl VMZ, based on the TLS VZ series unit or VMQ/X/Y systems based on the VUX sensor. Another difference is the range of the data collected. In automotive data, as a rule, only geometry is acquired and can be reduced to three coordinates. On the other hand, in the case of TLS, MLS or ALS data, the intensity, RGB values, echo information, airstrip, class and, in the case of data from moving systems, GPS time are also recorded. Therefore, compression efficiency calculated in bpp will be inadequate when comparing between publications. The compression performed in this study reduced the bpp count from 272 bpp for ALS data to 40.7 bpp for the best LAZ format, and from 208 bpp for TLS data to around 70 bpp. These values are similar to those presented in the work of [106,107], despite the different perspectives on space and the different range of information collected in the final file.

As part of future research, it is planned to carry out the following:

• Make the base files available for download and conversion to formats not included in this study for all interested parties;
• Test two-stage and multi-stage conversions, e.g., LAS to intermediate format and then, e.g., to *.RCP, instead of direct LAS -> RCP;
• Develop a methodology for evaluating the compression of LiDAR data to a single point value, taking into account multiple parameters including compression rate, compression time, hardware specification/PC processing power, density of the point cloud etc.;
• Test the proposed solution, i.e., 3DL, on point clouds used in other publications/public datasets.

6. Conclusions

This paper presents a new file format for containing LiDAR point clouds named 3DL. Following the strategies shown in Figure 1, the solution is instead of just archiving the cloud, it should be converted to a new format, achieving a smaller volume while leaving the data usable all the time. The solution was benchmarked against 21 other formats, which, with different parameters, yielded 100 comparative solutions. The reference parameters were CR (compression ratio in %) and CT (compression time in seconds).

The newly developed 3DL format that was validated achieves very good results in CR. For the ALS test files, it ranks second in group 2 (CR about 32%), i.e., converted formats, i.e., reduced but still usable, second only to the LAZ format. The LAZ format, which was designed by Martin Isenburg for ALS data, outclasses the competition with a CR score of 15%, i.e., an almost seven-fold reduction in file size through conversion. It is puzzling that despite the passage of more than 10 years, a better solution for ALS than the LAZ format has still not been developed. For the TLS samples, the best solution from group 2 is the new 3DL format (CR approx. 42%) for TLS_LOK and LAZ (CR approx. 37%) and 3DL (CR approx. 42%) for the TLS_PL2000 cloud. These results are all the more significant because only group 1 (archiving) formats, which consume energy in both compression and decompression, are better by ‘only’ 3–8 percentage points.

Admittedly, the compression methods used in the archivers (group 1) are more versatile (good for both ALS and TLS data), but their ‘dual’-energy requirements (compression and decompression) and significantly higher CT values exclude them from being the preferred or recommended solutions.

The current disadvantage of the solution presented (3DL) is the need to switch from LAS to POD, and then from POD to 3DL. It is planned to develop a one-step LAS to 3DL conversion in the future.

The authors hope that the results presented here will encourage other researchers to make greater use of geospatial data in the context of multidisciplinary analyses related to energy transition or space–environment relationships.