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



Never classified


Not assigned




Low Vegetation


Medium Vegetation


High Vegetation




Low Point








Road surface




Wire – Guard (Shield)


Wire - Conductor (Phase)


Transmission Tower


Wire Structure Connector (Insulator)


Bridge Deck


High Noise




LAZ – LASzip- LAS format file compressed without data loss.

BIN (Terrasolid format)

Format of Terrasolid company.

The file structure looks as follows:

CAD drafting Point Clouds Data Formats 0

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.

PTX (Leica Cyclone 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.


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:









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.



-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:












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.

XYB (Faro)

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:


  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 echos, 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.

RCS (ReCap Format)

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.

RCP (Autodesk Native Format)

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


We collect Cookies
We use cookies to ensure that we give you the best experience on our website. By clicking “Accept”, you agree to our website’s cookie use as described in our Privacy Statement.