Struct las::raw::header::Header

pub struct Header {
    pub file_signature: [u8; 4],
    pub file_source_id: u16,
    pub global_encoding: u16,
    pub guid: [u8; 16],
    pub version: Version,
    pub system_identifier: [u8; 32],
    pub generating_software: [u8; 32],
    pub file_creation_day_of_year: u16,
    pub file_creation_year: u16,
    pub header_size: u16,
    pub offset_to_point_data: u32,
    pub number_of_variable_length_records: u32,
    pub point_data_record_format: u8,
    pub point_data_record_length: u16,
    pub number_of_point_records: u32,
    pub number_of_points_by_return: [u32; 5],
    pub x_scale_factor: f64,
    pub y_scale_factor: f64,
    pub z_scale_factor: f64,
    pub x_offset: f64,
    pub y_offset: f64,
    pub z_offset: f64,
    pub max_x: f64,
    pub min_x: f64,
    pub max_y: f64,
    pub min_y: f64,
    pub max_z: f64,
    pub min_z: f64,
    pub start_of_waveform_data_packet_record: Option<u64>,
    pub evlr: Option<Evlr>,
    pub large_file: Option<LargeFile>,
    pub padding: Vec<u8>,
}

A las header.

The documentation for each member is taken directly from the las 1.2 spec, except in cases where the field's usage has changed, in which case notes about its uses over versions are included, with particular attention paid to the latest version, 1.4.

Fields

file_signature: [u8; 4]

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

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.

global_encoding: u16

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

Bits	Field name	las versions	Description
0	GPS time type	1.2 and above	The meaning of GPS Time in the point records. If this bit is not set, the GPS time in the point record fields is GPS Week Time (the same as versions 1.0 through 1.2 of LAS). Otherwise, if this bit is set, the GPS Time is standard GPS Time (satellite GPS Time) minus 1 x 109 (Adjusted Standard GPS Time). The offset moves the time back to near zero to improve floating point resolution.
1	Waveform data packets internal	1.3	If this bit is set, the waveform data packets are located within this file (note that this bit is mutually exclusive with bit 2). This is deprecated in las 1.4.
2	Waveform Data Packets External	1.3 and above	If this bit is set, the waveform data packets are located externally in an auxiliary file with the same base name as this file but the extension *.wdp. (note that this bit is mutually exclusive with bit 1)
3	Return numbers have been synthetically generated	1.3 and above	If this bit is 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	WKT	1.4	If set, the Coordinate Reference System (CRS) is WKT. If not set, the CRS is GeoTIFF. It should not be set if the file writer wishes to ensure legacy compatibility (which means the CRS must be GeoTIFF)
5:15	Reserved	All	Must be set to zero

guid: [u8; 16]

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.

version: Version

The version number consists of a major and minor field.

The major and minor fields combine to form the number that indicates the format number of the current specification itself. For example, specification number 1.2 (this version) would contain 1 in the major field and 2 in the minor field.

system_identifier: [u8; 32]

The version 1.0 specification assumes that LAS files are exclusively generated as a result of collection by a hardware sensor. Version 1.1 recognizes that files often result from extraction, merging or modifying existing data files.

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

generating_software: [u8; 32]

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 16 characters, the remaining data must be null.

file_creation_day_of_year: u16

Day, expressed as an unsigned short, on which this file was created.

Day is computed as the Greenwich Mean Time (GMT) day. January 1 is considered day 1.

file_creation_year: u16

The year, expressed as a four digit number, in which the file was created.

header_size: u16

The size, in bytes, of the Public Header Block itself.

In the event that the header is extended by a software application through the addition of data at the end of the header, the Header Size field must be updated with the new header size. Extension of the Public Header Block is discouraged; the Variable Length Records should be used whenever possible to add custom header data. In the event a generating software package adds data to the Public Header Block, this data must be placed at the end of the structure and the Header Size must be updated to reflect the new size.

las 1.4

For LAS 1.4 this size is 375 bytes. In the event that the header is extended by a new revision of the LAS specification through the addition of data at the end of the header, the Header Size field will be updated with the new header size. The Public Header Block may not be extended by users.

offset_to_point_data: u32

The actual number of bytes from the beginning of the file to the first field of the first point record data field.

This data offset must be updated if any software adds data from the Public Header Block or adds/removes data to/from the Variable Length Records.

number_of_variable_length_records: u32

This field contains the current number of Variable Length Records.

This number must be updated if the number of Variable Length Records changes at any time.

point_data_record_format: u8

The point data format ID corresponds to the point data record format type.

LAS 1.2 defines types 0, 1, 2 and 3. LAS 1.4 defines types 0 through 10.

point_data_record_length: u16

The size, in bytes, of the Point Data Record.

All Point Data Records within a single LAS file must be the same type and hence the same length. If the specified size is larger than implied by the point format type (e.g. 32 bytes instead of 28 bytes for type 1) the remaining bytes are user-specific “extra bytes. The format and meaning of such “extra bytes” can (optionally) be described with an Extra Bytes VLR (see Table 24 and Table 25).

number_of_point_records: u32

This field contains the total number of point records within the file.

number_of_points_by_return: [u32; 5]

This field contains an array of the total point records per return.

The first unsigned long value will be the total number of records from the first return, and the second contains the total number for return two, and so forth up to five returns.

x_scale_factor: f64

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.

y_scale_factor: f64

z_scale_factor: f64

x_offset: f64

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.

Xcoordinate = (Xrecord * Xscale) + Xoffset

Ycoordinate = (Yrecord * Yscale) + Yoffset

Zcoordinate = (Zrecord * Zscale) + Zoffset

y_offset: f64

z_offset: f64

max_x: f64

The max and min data fields are the actual unscaled extents of the LAS point file data, specified in the coordinate system of the LAS data.

min_x: f64

max_y: f64

min_y: f64

max_z: f64

min_z: f64

start_of_waveform_data_packet_record: Option<u64>

las 1.3 and 1.4: This value provides the offset, in bytes, from the beginning of the LAS file to the first byte of the Waveform Data Package Record.

Note that this will be the first byte of the Waveform Data Packet header. If no waveform records are contained within the file, this value must be zero. It should be noted that LAS 1.4 allows multiple Extended Variable Length Records (EVLR) and that the Waveform Data Packet Record is not necessarily the first EVLR in the file.

evlr: Option<Evlr>

large_file: Option<LargeFile>

padding: Vec<u8>

Implementations

impl Header

pub fn read_from<R: Read>(read: R) -> Result<Header>

Reads a raw header from a Read.

Generally very permissive, but will throw an error if a couple of things are true:

• The file signature is not exactly "LASF".
• The point data format is not recognized. Note that version mismatches are allowed (e.g. color points for las 1.1).
• The point data record length is less than the minimum length of the point data format.

Examples

use std::fs::File;
use las::raw::Header;
let mut file = File::open("tests/data/autzen.las").unwrap();
let header = Header::read_from(&mut file).unwrap();

pub fn offset_to_end_of_points(&self) -> u64

Returns the total file offset to the first byte after all of the points.

Examples

use las::raw::Header;
assert_eq!(227, Header::default().offset_to_end_of_points());

pub fn write_to<W: Write>(&self, write: W) -> Result<()>

Writes a raw header to a Write.

Examples

use std::io::Cursor;
use las::raw::Header;
let mut cursor = Cursor::new(Vec::new());
let header = Header::default();
header.write_to(&mut cursor).unwrap();

Trait Implementations

impl Clone for Header

fn clone(&self) -> Header

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Header

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for Header

fn default() -> Header

Returns the "default value" for a type.

impl PartialEq<Header> for Header

fn eq(&self, other: &Header) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Header) -> bool

This method tests for !=.

impl StructuralPartialEq for Header