Python Class Documentation

Warning

laspy https://github.com/grantbrown/laspy provides a pure-Python implementation that is compatible with libLAS’ API. Unless you are already using libLAS, we suggest that you utlize laspy for more complete Python LAS operations.

liblas.color.Color

class liblas.color.Color(red=0, green=0, blue=0, owned=True, handle=None)
__init__(red=0, green=0, blue=0, owned=True, handle=None)
Parameters:
  • red (integer) – Red value for the point
  • green (integer) – Green value for the point
  • blue (integer) – Blue value for the point
  • owned (boolean) – flag to denote whether or not the instance owns its shadow
  • handle – raw ctypes object
>>> from liblas import color
>>> c = color.Color()
>>> c.red
0
>>> c.green
0
>>> c.blue
0
>>> c = color.Color(red = 123, blue = 125, green = 124)
>>> c.red
123
>>> c.green
124
>>> c.blue
125

Note

RGB values should always be normalized to 16 bit values. For example, when encoding an 8 bit per channel pixel, multiply each channel value by 256 prior to storage in these fields. This normalization allows color values from different camera bit depths to be accurately merged.

__iter__()

Iterator support. Values are returned in [R,G,B] order

>>> for i in c:
...     print i
123
124
125
>>> list(c)
[123, 124, 125]
blue

Blue value of the color triple

green

Green value of the color triple

red

Red value of the color triple

liblas.file.File

class liblas.file.File(filename, header=None, mode='r', in_srs=None, out_srs=None)
__getitem__(index)

Index and slicing support

>>> out = f[0:3]
[<liblas.point.Point object at ...>,
<liblas.point.Point object at ...>,
<liblas.point.Point object at ...>]
__init__(filename, header=None, mode='r', in_srs=None, out_srs=None)

Instantiate a file object to represent an LAS file.

Parameters:
  • filename – The filename to open
  • header (an liblas.header.header.Header instance) – A header open the file with
  • mode (string) – “r” for read, “w” for write, and “w+” for append
  • in_srs (an liblas.srs.SRS instance) – Input SRS to override the existing file’s SRS with
  • out_srs (an liblas.srs.SRS instance) – Output SRS to reproject points on-the-fly to as they are read/written.

Note

To open a file in write mode, you must provide a liblas.header.Header instance which will be immediately written to the file. If you provide a header instance in read mode, the values of that header will be used in place of those in the actual file.

Note

If a file is open for write, it cannot be opened for read and vice versa.

>>> from liblas import file
>>> f = file.File('file.las', mode='r')
>>> for p in f:
...     print 'X,Y,Z: ', p.x, p.y, p.z
>>> h = f.header
>>> f2 = file.File('file2.las', header=h)
>>> for p in f:
...     f2.write(p)
>>> f2.close()
__iter__()

Iterator support (read mode only)

>>> points = []
>>> for i in f:
...   points.append(i)
...   print i 
<liblas.point.Point object at ...>
__len__()

Returns the number of points in the file according to the header

close()

Closes the LAS file

header

The file’s liblas.header.Header

Note

If the file is in append mode, the header will be overwritten in the file. Setting the header for the file when it is in read mode has no effect. If you wish to override existing header information with your own at read time, you must instantiate a new liblas.file.File instance.

input_srs

The input liblas.srs.SRS for the file. This overrides the liblas.header.Header.SRS. It is useful in cases where the header’s SRS is not valid or does not exist.

output_srs

The output liblas.srs.SRS for the file. Data will be reprojected to this SRS according to either the input_srs if it was set or default to the liblas.header.Header.SRS if it was not set. The header’s SRS must be valid and exist for reprojection to occur. GDAL support must also be enabled for the library for reprojection to happen.

read(index)

Reads the point at the given index

write(pt)

Writes the point to the file if it is append or write mode. LAS files are written sequentially starting from the first point (in pure write mode) or from the last point that exists (in append mode).

Parameters:pt (liblas.point.Point instance to write) – The point to write.

Note

At this time, it is not possible to duck-type point objects and have them be written into the LAS file (from say numpy or something). You have to take care of this adaptation yourself.

liblas.guid.GUID

class liblas.guid.GUID(key=None, handle=None)
__eq__(other)

Test GUID for equality against another liblas.guid.GUID instance

Parameters:other – The liblas.guid.GUID instance to test against
__init__(key=None, handle=None)
Parameters:
  • key (string) – GUID string to create with
  • handle – raw ctypes object
>>> from liblas import guid
>>> from liblas import header
>>> g2 = guid.GUID(key='8388f1b8-aa1b-4108-bca3-6bc68e7b062e')
>>> g2
8388f1b8-aa1b-4108-bca3-6bc68e7b062e
>>> header = header.Header()
>>> header.guid = g2
>>> header.guid
8388f1b8-aa1b-4108-bca3-6bc68e7b062e
>>> header.project_id
'8388f1b8-aa1b-4108-bca3-6bc68e7b062e'
>>> g3 = guid.GUID(key='8388f1b8-aa1b-4108-bca3-6bc68e7b062e')
>>> g2 == g3
True

Note

In Python 2.5+, you can use the uuid module to control the creation of UUIDs in alternative ways. Otherwise, the GUID() constructor will create them for you, but rather simply.

__str__()

String representation of the GUID

liblas.header.Header

class liblas.header.Header(owned=True, handle=None, copy=False)
__len__()

Returns the expected number of point records in the file.

Note

This value can be grossly out of sync with the actual number of points in the file, because some some softwares are not careful to keep it up-to-date. If libLAS detects a case where it is not properly written, an exception will be thrown.

count

Returns the expected number of point records in the file.

Note

This value can be grossly out of sync with the actual number of points in the file, because some some softwares are not careful to keep it up-to-date. If libLAS detects a case where it is not properly written, an exception will be thrown.

data_format_id

The point format as an integer. See the specification for more detail.

It can be 3, 2, 1, or 0.

Note

Use liblas.schema.Schema and set the liblas.header.Header.schema object instead of using the dataformat_id directly. Otherwise, you will have to account for the liblas.header.Header.data_record_length.

data_offset

The number of bytes of offset between the end of the header and the start of the point data in the file. Set this to a large value if you plan to include many liblas.vlr.VLR‘s to the file.

Note

libLAS will manage this value for you as you add or remove VLRs or liblas.srs.SRS instances to the header. Make sure to adjust your header information before opening a new file to write, as that is when the header’s VLRs are written to the file, and they cannot be adjusted after that.

date

The header’s date from a datetime.datetime instance.

Parameters:valuedatetime.datetime instance or none to use the current time
>>> t = datetime.datetime(2008,3,19)
>>> hdr.date = t
>>> hdr.date
datetime.datetime(2008, 3, 19, 0, 0)

Note

LAS files do not support storing full datetimes in their headers, only the year and the day number. The conversion is handled for you if you use datetime.datetime instances, however.

encoding

Global encoding for the file.

From the specification:

This is a bit field used to indicate certain global properties about the file. In LAS 1.2 (the version in which this field was introduced), only the low bit is defined (this is the bit, that if set, would have the unsigned integer yield a value of 1). This bit field is defined as:

Global Encoding - Bit Field Encoding
Bits Field Name Description
0 GPS Time Type The meaning of GPS Time in the Point Records 0 (not set) -> GPS time in the point record fields is GPS Week Time (the same as previous versions of LAS) 1 (set) -> GPS Time is standard GPS Time (satellite GPS Time) minus 1 x 10^9 (Adjusted Standard GPS Time). The offset moves the time back to near zero to improve floating point resolution.
1 Waveform Data Packets Internal If this bit is set, the waveform data packets are located within this file (note that this bit is mutually exclusive with bit 2)
2 Waveform Data Packets External If this bit is set, the waveform data packets are located external to this file in an auxiliary file with the same base name as this file and the extension .wdp. (note that this bit is mutually exclusive with bit 1)
3 Return numbers have been synthetically generated If set, the point return numbers in the Point Data Records have been synthetically generated. This could be the case, for example, when a composite file is created by combining a First Return File and a Last Return File. In this case, first return data will be labeled ‘1 of 2’ and second return data will be labeled ‘2 of 2’
4:15 Reserved Must be set to zero
file_signature

The file signature for the file. It should always be ‘LASF’

From the specification:
The file signature must contain the four characters “LASF”, and it is required by the LAS specification. These four characters can be checked by user software as a quick look initial determination of file type.
file_source_id

File Source ID for the file.

From the specification:
This field should be set to a value between 1 and 65,535, inclusive. A value of zero (0) is interpreted to mean that an ID has not been assigned. In this case, processing software is free to assign any valid number. Note that this scheme allows a LIDAR project to contain up to 65,535 unique sources. A source can be considered an original flight line or it can be the result of merge and/or extract operations.
guid

The GUID/liblas.header.Header.project_id for the file.

header_length

The number of bytes that the header contains. For libLAS, this is always 227, and it is not configurable.

major

Major version number for the file. For all practical purposes, this is always ‘1’

max

The maximum values of [x, y, z] for the data in the file.

Note

libLAS does not manage these values automatically for you. You must cumulate and generate the histogram manually if you wish to keep these data up-to-date with what actually exists in the file.

>>> hdr.max
[0.0, 0.0, 0.0]
>>> hdr.max = [33452344.2333, 523442.344, -90.993]
>>> hdr.max
[33452344.2333, 523442.34399999998, -90.992999999999995]
min

The minimum values of [x, y, z] for the data in the file.

Note

libLAS does not manage these values automatically for you. You must cumulate and generate the histogram manually if you wish to keep these data up-to-date with what actually exists in the file.

>>> hdr.min
[0.0, 0.0, 0.0]
>>> hdr.min = [33452344.2333, 523442.344, -90.993]
>>> hdr.min
[33452344.2333, 523442.34399999998, -90.992999999999995]
minor

Minor version for the file. [0, 1, 2] are currently supported.

num_vlrs

Returns the number of user-defined header records in the header. libLAS will manage this value you for you as you add new liblas.srs.SRS or liblas.vlr.VLR instances to the header.

offset

The offset factors in [x, y, z] for the point data.

From the specification:
The offset fields should be used to set the overall offset for the point records. In general these numbers will be zero, but for certain cases the resolution of the point data may not be large enough for a given projection system. However, it should always be assumed that these numbers are used. So to scale a given X from the point record, take the point record X multiplied by the X scale factor, and then add the X offset.
Coordinates are calculated using the following formula(s):
  • x = (x_int * x_scale) + x_offset
  • y = (y_int * y_scale) + y_offset
  • z = (z_int * z_scale) + z_offset

Note

libLAS uses this header value when reading/writing raw point data to the file. If you change it in the middle of writing data, expect the unexpected.

>>> hdr.offset
[0.0, 0.0, 0.0]
>>> hdr.offset = [32, 32, 256]
>>> hdr.offset
[32.0, 32.0, 256.0]
project_id

ProjectID for the file. libLAS does not currently support setting this value from Python, as it is the same as liblas.header.Header.guid. Use that to manipulate the ProjectID for the file.

From the specification:
The four fields that comprise a complete Globally Unique Identifier (GUID) are now reserved for use as a Project Identifier (Project ID). The field remains optional. The time of assignment of the Project ID is at the discretion of processing software. The Project ID should be the same for all files that are associated with a unique project. By assigning a Project ID and using a File Source ID (defined above) every file within a project and every point within a file can be uniquely identified, globally.
return_count

The histogram of point records by return number for returns 0...8

Note

libLAS does not manage these values automatically for you. You must cumulate and generate the histogram manually if you wish to keep these data up-to-date with what actually exists in the file.

>>> hdr.point_return_count
[0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L]
>>> l = [1341235L, 3412341222L, 0L, 0L, 4321L, 0L, 0L, 0L]
>>> hdr.point_return_count = l
>>> hdr.point_return_count
[1341235L, 3412341222L, 0L, 0L, 4321L, 0L, 0L, 0L]
scale

The scale factors in [x, y, z] for the point data. libLAS uses the scale factors plus the liblas.header.Header.offset values to store the point coordinates as integers in the file.

From the specification:
The scale factor fields contain a double floating point value that is used to scale the corresponding X, Y, and Z long values within the point records. The corresponding X, Y, and Z scale factor must be multiplied by the X, Y, or Z point record value to get the actual X, Y, or Z coordinate. For example, if the X, Y, and Z coordinates are intended to have two decimal point values, then each scale factor will contain the number 0.01
Coordinates are calculated using the following formula(s):
  • x = (x_int * x_scale) + x_offset
  • y = (y_int * y_scale) + y_offset
  • z = (z_int * z_scale) + z_offset

Note

libLAS uses this header value when reading/writing raw point data to the file. If you change it in the middle of writing data, expect the unexpected.

>>> hdr.scale
[0.01, 0.01, 0.01]
>>> hdr.scale = [0.5, 0.5, 0.001]
>>> hdr.scale
[0.5, 0.5, 0.001]
schema

The liblas.schmea.Schema for this file

Use the schema to set whether or not color or time should be stored on the points:

>>> h = liblas.header.Header()
>>> f = liblas.schema.Schema()
>>> f.time = True
>>> f.color = True
>>> h.schema = f
>>> h.schema.color
True
>>> h.schema.time
True
>>> h.schema.size
34
>>> h.data_record_length
34

The following example demonstrates how to make a point schema that does not store color or time, but also provides 22 extra bytes to store liblas.point.Point.data

>>> h = liblas.header.Header()
>>> h.schema
<liblas.schema.Schema object at 0x100779f90>
>>> h.schema.time
False
>>> h.schema.color
False
>>> h.schema.size
20
>>> f = h.schema
>>> f.size = 42
>>> f.size
42
>>> f.color
False
>>> f.time
False
>>> h.schema = f
>>> h.schema.size
42
set_count(value)

Sets the number of point records expected in the file.

Note

Don’t use this unless you have a damn good reason to. As you write points to a file, libLAS is going to keep this up-to-date for you and write it back into the header of the file once the file is closed after writing data.

software_id

The software identifier. The value is truncated to 31 characters and defaults to ‘libLAS 1.LASVERSION’ (ie, libLAS 1.6 for the 1.6 release)

arg value:a string that will automatically be truncated to 31 characters
type value:string
From the specification:
This information is ASCII data describing the generating software itself. This field provides a mechanism for specifying which generating software package and version was used during LAS file creation (e.g. “TerraScan V-10.8”, “REALM V-4.2” and etc.). If the character data is less than 32 characters, the remaining data must be null.
>>> h.software_id
'libLAS 1.0'
>>> h.software_id = 'hobu'
>>> h.software_id
'hobu'
>>> h.software_id = 'hobu'*9
>>> h.software_id
'hobuhobuhobuhobuhobuhobuhobuhob'
system_id
The system identifier. The value is truncated to 31 characters and
defaults to ‘libLAS’
Parameters:value (string) – a string that will automatically be truncated to 31 characters

From the specification:

System Identifier
Generating Agent System ID
Hardware system String identifying hardware (e.g. ALTM 1210 or ALS50
Merge of one or more files MERGE
Modification of a single file MODIFICATION
Extraction from one or more files EXTRACTION
Reprojection, rescaling, warping, etc. TRANSFORMATION
Some other operation OTHER or a string up to 32 characters identifying the operation
>>> h.system_id
''
>>> h.system_id = 'MODIFICATION'
>>> h.system_id
'MODIFICATION'

liblas.point.Point

class liblas.point.Point(owned=True, handle=None, copy=False)
__init__(owned=True, handle=None, copy=False)

Instantiates a liblas.point.Point object. If you are creating and working with your own instances, you should normally not need to use any of the parameters.

Parameters:
  • owned – boolean A flag to denote whether or not the point owns itself and can destroy itself upon going out of scope. There are instances where liblas.file.File may actually own the point as it is read from or written to files.
  • handle – ctypes object reference A handle to an existing ctypes LASPointH object reference. Only internal liblas code should have to worry about using this.
  • copy – boolean A flag to denote whether or not to copy the point upon creation. Used in coordination with the handle parameter, and it should not normally be used.
Return type:

liblas.point.Point object

classification

The point’s classification as a raw byte value.

The following large section of information is verboten from the specification for your convenience:

This filed represents the “class” attributes of a point. If a point has never been classified, this byte must be set to zero. There are no user defined classes since all point formats 0 supply 8 bits per point for user defined operations.

Classification Bit Field Encoding
Bits Field Name Description
0:4 Classification Standard ASPRS classification as defined in the following classification table.
5 Synthetic If set then this point was created by a technique other than LIDAR collection such as digitized from a photogrammetric stereo model or by traversing a waveform.
6 Key-point If set, this point is considered to be a model key- point and thus generally should not be withheld in a thinning algorithm.
7 Witheld If set, this point should not be included in processing (synonymous with Deleted).

Note

Bits 5, 6 and 7 are treated as flags and can be set or clear in any combination. For example, a point with bits 5 and 6 both set to one and the lower five bits set to 2 (see table below) would be a ground point that had been Synthetically collected and marked as a model key-point.

ASPRS Standard LiDAR Point Classes
Classification Meaning
0 Created, never classified
1 Unclassified
2 Ground
3 Low Vegetation
4 Medium Vegetation
5 High Vegetation
6 Building
7 Low Point (noise)
8 Model Key-point (mass point)
9 Water
10 Reserved for ASPRS Definition
11 Reserved for ASPRS Definition
12 Overlap Points
13-31 Reserved for ASPRS Definition

Note

We are using both 0 and 1 as Unclassified to maintain compatibility with current popular classification software such as TerraScan. We extend the idea of classification value 1 to include cases in which data have been subjected to a classification algorithm but emerged in an undefined state. For example, data with class 0 is sent through an algorithm to detect man-made structures – points that emerge without having been assigned as belonging to structures could be remapped from class 0 to class 1

Note

Overlap Points are those points that were immediately culled during the merging of overlapping flight lines. In general, the Withheld bit should be set since these points are not subsequently classified.

color

Raw color value for the point as an liblas.color.Color instance.

Note

RGB values should always be normalized to 16 bit values. For example, when encoding an 8 bit per channel pixel, multiply each channel value by 256 prior to storage in these fields. This normalization allows color values from different camera bit depths to be accurately merged.

data

Raw data for the point. Shoot yourself in the foot if you must!

flightline_edge

Flightline edge flag for the point

From the specification:

The Edge of Flight Line data bit has a value of 1 only when the point is at the end of a scan. It is the last point on a given scan line before it changes direction.
number_of_returns

The number of returns for a given laser pulse.

From the specification:

The Number of Returns is the total number of returns for a given pulse. For example, a laser data point may be return two (Return Number) within a total number of five returns.
point_source_id

Point Source ID for the point.

From the specification:

This value indicates the file from which this point originated. Valid values for this field are 1 to 65,535 inclusive with zero being used for a special case discussed below. The numerical value corresponds to the File Source ID from which this point originated. Zero is reserved as a convenience to system implementers. A Point Source ID of zero implies that this point originated in this file. This implies that processing software should set the Point Source ID equal to the File Source ID of the file containing this point at some time during processing.
raw_time

Uninterpeted time value for the point.

Note

Because no header is available, no coordination is done with respect to the allowable LAS time types. You must coordinate with the liblas.header.Header.global_encoding to determine the actual time value for the point. See the ASPRS LAS 1.1-1.3 specifications for more detail.

return_number

The pulse return number for a given laser pulse.

From the specification:

The Return Number is the pulse return number for a given output pulse. A given output laser pulse can have many returns, and they must be marked in sequence of return. The first return will have a Return Number of one, the second a Return Number of two, and so on up to five returns.
scan_angle

Scan angle of the point.

From the specification:
The Scan Angle Rank is a signed one-byte number with a valid range from -90 to +90. The Scan Angle Rank is the angle (rounded to the nearest integer in the absolute value sense) at which the laser point was output from the laser system including the roll of the aircraft. The scan angle is within 1 degree of accuracy from +90 to -90 degrees. The scan angle is an angle based on 0 degrees being nadir, and -90 degrees to the left side of the aircraft in the direction of flight.
scan_direction

Scan direction for the point

From the specification:

The Scan Direction Flag denotes the direction at which the scanner mirror was traveling at the time of the output pulse. A bit value of 1 is a positive scan direction, and a bit value of 0 is a negative scan direction (where positive scan direction is a scan moving from the left side of the in-track direction to the right side and negative the opposite).
scan_flags

Scan flags for the point. This is a combination of the flightline_edge return_number number_of_returns and scan_direction. Use the individual methods for setting these values for convenience.

time

Interpeted (datetime.datetime instance) time value for the point.

Example:

>>> td = datetime.timedelta(hours=6) # my timezone is -6
>>> t = datetime.datetime(2008,3,19) - td
>>> p.time = t
>>> p.time
datetime.datetime(2008, 3, 19, 0, 0)

Note

Because no header is available, no coordination is done with respect to the allowable LAS time types. You must coordinate with the liblas.header.Header.global_encoding to determine the actual time value for the point. If you want to merely preserve existing point data, use liblas.point.Point.raw_time

user_data

User Data for the point. This is a single byte of data and and can be anything the software wants to attach to the point

x
The raw X coordinate of the point without its header’s scaling
applied.

Note

Use obj:liblas.point.Point.x if you want the scaled x data.

y

Y coordinate of the LAS point as a double (scale applied).

Note

Use obj:liblas.point.Point.raw_y if you want the unscaled y data.

z

Z coordinate of the LAS point as a double (scale applied).

Note

Use obj:liblas.point.Point.raw_z if you want the unscaled z data.

liblas.srs.SRS

class liblas.srs.SRS(owned=True, handle=None)

While the ASPRS specification mandates using GeoTIFF keys for its coordinate system description, these are unwieldy to use in an application. libLAS provides the most featureful access when by linking GDAL. The liblas.srs.SRS object can be set on the liblas.header.Header or it may be set on the liblas.file.File in various ways of controlling reprojection of input or output.

__init__(owned=True, handle=None)
Parameters:
  • owned – flag to denote whether or not the VLR owns itself
  • handle – raw ctypes object
get_proj4()

Returns a Proj.4 string that describes the SRS

get_wkt()

Returns the horizontal-only WKT for the SRS

get_wkt_compoundok()

Gets the WKT for the SRS with COMP_CS elements describing the vertical datum and other extra information

proj4

Returns a Proj.4 string that describes the SRS

set_proj4(value)

Sets the SRS description with a given Proj.4 string

set_userinput(value)

Sets the SRS description using GDAL‘s SetFromUserInput method

set_verticalcs(verticalCSType, citation='', verticalDatum=-1, verticalUnits=9001)

Sets the vertical coordinate system using geotiff key values. This operation should normally be done after setting the horizontal portion of the coordinate system with something like set_wkt(), set_proj4(), or set_userinput()

Parameters:
  • verticalCSType – An EPSG vertical coordinate system code, normally in the range 5600 to 5799, or -1 if one is not available.
  • citation – a textual description of the vertical coordinate system or an empty string if nothing is available.
  • verticalDatum – the EPSG vertical datum code, often in the range 5100 to 5299 - implied by verticalCSType if that is provided, or -1 if no value is available.
  • verticalUnits – the EPSG vertical units code, often 9001 for Metre.
set_wkt(value)

Sets the wkt for the SRS. An exception will be thrown if the WKT is invalid, GDAL can’t ingest it, or GDAL is not linked into libLAS

wkt

WKT description of the SRS

liblas.vlr.VLR

class liblas.vlr.VLR(owned=True, handle=None)
__init__(owned=True, handle=None)
Parameters:
  • owned – flag to denote whether or not the VLR owns itself. If it is owned, the underlying C object will be destroyed once it goes out of scope.
  • handle – raw ctypes object

From the specification:

The Public Header Block is followed by one or more Variable Length Records (There is one mandatory Variable Length Record, GeoKeyDirectoryTag). The number of Variable Length Records is specified in the “Number of Variable Length Records” (liblas.header.Header.records_count) field in the Public Header Block. The Variable Length Records must be accessed sequentially since the size of each variable length record is contained in the Variable Length Record Header. Each Variable Length Record Header is 60 bytes in length.
>>> from liblas import vlr
>>> v = vlr.VLR()
>>> v.reserved
0
>>> v.recordid
0
>>> v.recordid = 2
>>> v.recordid
2
>>> v.userid
''
>>> v.userid = 'liblas.org'
>>> v.userid
'liblas.org'
>>> v.description
''
>>> v.description = 'libLAS'
>>> v.description
'libLAS'
data

Raw data (in the form of an array of ctypes.c_ubyte)

description

Description of this VLR instance (clipped to 32 bytes long)

From the specification:
Optional, null terminated text description of the data. Any remaining characters not used must be null.
recordid

Record ID for the VLR

From the specification:
The Record ID is dependent upon the User ID. There can be 0 to 65535 Record IDs for every User ID. The LAS specification manages its own Record IDs (User IDs owned by the specification), otherwise Record IDs will be managed by the owner of the given User ID. Thus each User ID is allowed to assign 0 to 65535 Record IDs in any manner they desire. Publicizing the meaning of a given Record ID is left to the owner of the given User ID. Unknown User ID/Record ID combinations should be ignore
recordlength

The number of bytes long the VLR is

reserved

Reserved value for the VLR. Currently unused.

userid

User ID key for this VLR (clipped to 16 bytes long)

The User ID for libLAS is liblas, and it will be used for all extra VLRs that libLAS itself can interpret.

See also

VLR Key has more detail on the key and name.

From the specification:
The User ID field is ASCII character data that identifies the user which created the variable length record. It is possible to have many Variable Length Records from different sources with different User IDs. If the character data is less than 16 characters, the remaining data must be null. The User ID must be registered with the LAS specification managing body. The management of these User IDs ensures that no two individuals accidentally use the same User ID. The specification will initially use two IDs: one for globally specified records (LASF_Spec), and another for projection types (LASF_Projection). Keys may be requested at http://www.asprs.org/lasform/keyform.html