Point Clouds Data Formats
Point clouds are datasets of vertex data in a three-dimensional coordinate system, usually defined by X, Y, and Z coordinates. The most common method for obtaining point cloud data is the use of 3D laser scanners or photogrammetric image processing techniques in software.
3D scanners use LiDAR technology, a remote sensing technology that uses laser pulses to collect data. The LiDAR system calculates how long it takes for the laser light wave to reach the target and return to the scanner using the speed of light, which is 299 792 458 m/s.
The measurement principles used in 3D scanners are pulsed and phase distance measurement methods, as well as a direct angular sweep method (triangulation method).
Laser 3D scanning technology is the most common method for obtaining point clouds.
Supported Formats of Point Cloud Files
There are several file formats for storing point cloud data, which, in addition to 3D coordinates, can carry additional information - metadata (attributes). Some metadata are the result of the scanner operation (scan color, intensity, echo number, scan angle, end-of-beam, edge of flightline, source ID, time), and some are added to 3D coordinates when working with the cloud (class, normal, deviations, geometry).
Initially, lidar data are received exclusively in ASCII format. With the accumulation of large amounts of lidar data, a binary format called LAS began to be used for work and became the standard format for organizing and distributing laser data. Lidar data in LAS format is quite common nowadays. LAS is the most suitable format because files in this format contain more information and, being binary, they can be read more efficiently when imported.
LAS is an industry standard developed and used by the American Society for Photogrammetry and Remote Sensing (ASPRS). LAS is a standard file format for exchanging lidar data. It stores specific information related to lidar data. It is a way of exchanging data for suppliers and consumers, and storing all information specific to this data.
Each LAS file contains lidar metadata in a header block, followed by an individual entry for each laser pulse. The header portion of each LAS file contains attribute information about the lidar survey: data extents, date of flight, number of points recorded, number of echo points, any additional data, and applied scale factors. The following lidar point data attributes are stored in the LAS file for each laser pulse: X, Y, Z coordinates, GPS time, intensity, echo number, echo count, point classification values, scan angle, additional RGB values, scan direction, edge of flightline, user data, point source ID, wave information. The processed LAS file can include points classified as Ground, Low Vegetation, High Vegetation, Building, and so on.
Classification codes for LAS versions 1.1 – 1.4 assigned by ASPRS
Classification value |
Meaning |
0 |
Never classified |
1 |
Not assigned |
2 |
Ground |
3 |
Low Vegetation |
4 |
Medium Vegetation |
5 |
High Vegetation |
6 |
Building |
7 |
Low Point |
8 |
Reserved* |
9 |
Water |
10 |
Rail |
11 |
Road surface |
12 |
Reserved* |
13 |
Wire – Guard (Shield) |
14 |
Wire - Conductor (Phase) |
15 |
Transmission Tower |
16 |
Wire Structure Connector (Insulator) |
17 |
Bridge Deck |
18 |
High Noise |
19-63 |
Reserved |
LAZ – LASzip- LAS format file compressed without data loss.
Format of Terrasolid company.
The file structure looks as follows:
Point cloud attributes are stored in blocks: first a point coordinate block, then a time block, then an intensity block, etc.
The advantages of block storage:
· Possibility to read only the necessary attributes of points, this saves RAM and reduces the time for reading a file;
· You can save only the required attributes;
· Time stamps are now stored in GPS Standard Time format.
Format of Leica company, Cyclone program.
A simple text file for storing point cloud data. Consists of a series of header lines followed by lines consisting of vertices (X, Y, Z), scalar coordinates, and R, G, B color values, each ranging from 0 to 255 (sometimes floating).
The Leica header looks as follows.
number of columns
number of rows
st1 st2 st3 ; scanner registered position
sx1 sx2 sx3 ; scanner registered axis 'X'
sy1 sy2 sy3 ; scanner registered axis 'Y'
sz1 sz2 sz3 ; scanner registered axis 'Z'
r11 r12 r13 0 ; transformation matrix
r21 r22 r23 0 ; this is a simple rotation and translation 4x4 matrix
r31 r32 r33 0 ; just apply to each point to get the transformed coordinate
tr1 tr2 tr3 1 ; use double-precision variables
All point clouds in PTX format usually have brightness information, so every cloud will have this attribute. Color data is determined if there are seven elements on the dot line.
The coordinates of cloud points are calculated using the position recorded by the scanner, as well as the position of the scanner and the transformation matrix.
If the scanner position is specified in the user interface, the transformation matrix in the PTX header is still used to calculate the points coordinates.
The most common file format for storing and exchanging 3D laser scanning data.
In general, an E57 file consists of a 48-byte header, a series of data blocks, and an XML section. The entire file, including the header, is divided into 1024-byte "pages", 1020-byte data, and 4 bytes at the end as a checksum. This chunk nature even applies to the XML text / readable section after all chunks of data.
Example:
struct E57FileHeader {
char fileSignature[8];
uint32_t majorVersion;
uint32_t minorVersion;
uint64_t filePhysicalLength;
uint64_t xmlPhysicalOffset;
uint64_t xmlLogicalLength;
uint64_t pageSize;
}
The E57 data format is supported by static and mobile 3D scanners, which are used to calculate point coordinates.
With mobile devices, point clouds and trajectory data are linked using time stamps. Therefore, at least one E57 scan should contain a field for timestamps. Trajectory information is required to import scan results from mobile devices. The trajectory file should contain a list of scanner positions associated with timestamps. The positions should be specified in the same coordinate system as the point cloud coordinates, and the trajectory timestamps should match the timestamps of the points.
Trajectory example:
Time;X;Y;Z
189321.10;15.96;-52.12;133.68
189321.20;15.21;-51.21;134.01
189321.30;14.75;-50.37;134.35
189321.40;14.10;-49.50;134.31
189321.10;13.78;-48.69;134.43
...
This is a simple text file obtained from LIDAR scanners. The first line contains the number of lines. Each subsequent line has 7 values, the first three are the coordinates (X, Y, Z) of the point, the fourth is the “intensity” value, and the last three are the color estimates (R, G, B). The R, G, B values range from 0 to 255 (one unsigned byte). The intensity value is an estimate of the fraction of incident radiation reflected by the surface at that point.
Example:
253730194
-0.41025 -2.0806 8.00981 55 52 44 65
-0.63016 -1.84527 6.59447 228 228 230 225
-0.4766 -2.14446 7.91288 60 56 54 68
-0.52017 -1.51698 7.91458 60 58 50 71
-0.626 -2.46051 7.35187 152 140 160 161
-0.62371 -1.53502 7.46876 168 163 175 175
-0.62829 -2.27286 6.34905 208 204 213 212
-0.62614 -2.48739 7.36484 151 144 155 159
: : :
: : :
: : :
The format is created to optimize point cloud data, currently the latest version is 0.7 (PCD_V7).
Each PCD file contains a header that identifies and declares specific properties of the point cloud data stored in the file. The PCD header must be ASCII encoded. Header entries must be listed in the exact order shown below:
VERSION
FIELDS
SIZE
TYPE
COUNT
WIDTH
HEIGHT
VIEWPOINT
POINTS
DATA
Simple text format of 3-dimensional coordinates, separated by spaces, contains at least 3 columns of data (X, Y, Z).
This is a simple text format for the coordinates of 3-dimensional points, separated by spaces, containing 7 fields per point. The problem is that due to the lack of specifications for the content of the point cloud file, the content of the fields can vary depending on where and by whom it was created. The main thing is that the first 3 columns always represent the X, Y, Z coordinates, and the rest of the columns represent some scalar field associated with this point (R, G, B or Nx, Ny, Nz, etc.).
XYZ format can be presented in both text and binary types.
The binary format of the XYZ file. It can also contain attribute data in addition to the coordinates of points.
A polygonal storage format for graphic objects that are described as a set of polygons. The file format has two representations - text and binary. The PLY format contains the description of vertices, faces and other elements, their properties such as color, surface normal, textures, transparency, and various properties for the top and bottom surfaces of polygons. Typical information contains only two elements: the coordinates (X, Y, Z) for the points vertices and the vertex indices for each face.
The PLY format supports the creation of new properties for objects, but if new properties are not understood or defined in third-party software, they can be ignored.
The structure of a typical PLY file:
Header
Vertex List
Face List
(lists of other elements)
NPC (nanoCAD Point Cloud Storage Format)
It is the main format for storing and exchanging point cloud data in the nanoCAD environment.
The NPC format is a spatially indexed optimized container for a single point cloud with support for levels of detail. The format is capable of storing not only the cloud geometry, but also meta-information: the echo intensity, the number of echoes, signs of the scanning system position for the data obtained during laser scanning, the point color, the point class, its belonging to geometric shapes, the data source ID and the time of its registration, as well as calculated information: normal and curvature at a point. The structure of the container allows you to work with it by partially projecting data into memory.
Point cloud storage format of the Autodesk ReCap software after importing scanned point cloud files into it (formats that are indexed in ReCap: ASC, CL3, CLR, E57, FLS, FWS, ISPROJ, LAS, PCG, PTG, PTS, PTX, RDS (3D only), TXT, XYB, XYZ, ZFS, ZFPRJ). Point cloud data saved in RCS format are in meters.
The file format is a project file that groups multiple scan files at the same time. RCS, which actually contains links to individual RCS files and contains information about them and preview files. The result of indexing a source format file is a .RCP file and one or more .RCS files. The internal structure of the file is xml.