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]

property blue¶: Blue value of the color triple

property green¶: Green value of the color triple

property 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

property 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.

property 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.

property 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)¶

__init__(owned=True, handle=None, copy=False)¶: Initialize self. See help(type(self)) for accurate signature.

__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.

property 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.

property 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.

property 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.

property date¶

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

Parameters: value – datetime.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.

property 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

property 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.

property 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.

property guid¶: The GUID/liblas.header.Header.project_id for the file.

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

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

property 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]

property 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]

property minor¶: Minor version for the file. [0, 1, 2] are currently supported.

property 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.

property 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]

property 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.

property 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]

property 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]

property 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.

property 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'

property 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

property 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.

property 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.

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

property 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.

property 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.

property 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.

property 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.

property 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.

property 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.

property 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).

property 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.

property 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

property 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

property 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.

property 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.

property 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

property 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

property 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'

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

property 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.

property 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

property recordlength¶: The number of bytes long the VLR is

property reserved¶: Reserved value for the VLR. Currently unused.

property 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.

Python Class Documentation¶

liblas.color.Color¶

liblas.file.File¶

liblas.guid.GUID¶

liblas.header.Header¶

liblas.point.Point¶

liblas.srs.SRS¶

liblas.vlr.VLR¶

Table of Contents

This Page