|
|
Home | Docs | Bugs | FAQ | Download |
| Parameters: |
|
|---|
>>> 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.
Red value of the color triple
Green value of the color triple
Blue value of the color triple
Iterator support. Values are returned in [R,G,B] order
>>> for i in c:
... print i
123
124
125
>>> list(c)
[123, 124, 125]
Instantiate a file object to represent an LAS file.
| Parameters: |
|
|---|
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()
Closes the LAS file
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.
Reads the point at the given index
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.
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.
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.
Iterator support (read mode only)
>>> points = []
>>> for i in f:
... points.append(i)
... print i
<liblas.point.Point object at ...>
Index and slicing support
>>> out = f[0:3]
[<liblas.point.Point object at ...>,
<liblas.point.Point object at ...>,
<liblas.point.Point object at ...>]
Returns the number of points in the file according to the header
| Parameters: |
|
|---|
>>> 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.
String representation of the GUID
Test GUID for equality against another liblas.guid.GUID instance
| Parameters: | other – The liblas.guid.GUID instance to test against |
|---|
Major version number for the file. For all practical purposes, this is always ‘1’
Minor version for the file. [0, 1, 2] are currently supported.
The GUID/liblas.header.Header.project_id for the file.
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.
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.
The file signature for the file. It should always be ‘LASF’
File Source ID for the file.
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
| 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'
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'
The number of bytes that the header contains. For libLAS, this is always 227, and it is not configurable.
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.
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.
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
The point format as an integer. See the specification for more detail.
It can be 3, 2, 1, or 0.
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.
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.
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.
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]
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.
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]
The offset factors in [x, y, z] for the point data.
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]
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]
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]
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: |
|
|---|---|
| Return type: | liblas.point.Point object |
Note
Use obj:liblas.point.Point.x if you want the scaled x data.
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 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.
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
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.
Scan angle of the point.
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 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.
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.
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.
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.
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.
| 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.
| 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.
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
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 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.
Raw data for the point. Shoot yourself in the foot if you must!
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.
| Parameters: |
|
|---|
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: |
|
|---|
WKT description of the SRS
Returns the horizontal-only WKT for the SRS
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
Gets the WKT for the SRS with COMP_CS elements describing the vertical datum and other extra information
Sets the SRS description using GDAL‘s SetFromUserInput method
| Parameters: |
|
|---|
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'
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.
Description of this VLR instance (clipped to 32 bytes long)
The number of bytes long the VLR is
Record ID for the VLR
Reserved value for the VLR. Currently unused.
Raw data (in the form of an array of ctypes.c_ubyte)