[−][src]Struct las::raw::header::Header
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
[src]
pub fn read_from<R: Read>(read: R) -> Result<Header>
[src]
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
[src]
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<()>
[src]
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
[src]
impl Debug for Header
[src]
impl Default for Header
[src]
impl PartialEq<Header> for Header
[src]
impl StructuralPartialEq for Header
[src]
Auto Trait Implementations
impl RefUnwindSafe for Header
impl Send for Header
impl Sync for Header
impl Unpin for Header
impl UnwindSafe for Header
Blanket Implementations
impl<T> Any for T where
T: 'static + ?Sized,
[src]
T: 'static + ?Sized,
impl<T> Borrow<T> for T where
T: ?Sized,
[src]
T: ?Sized,
impl<T> BorrowMut<T> for T where
T: ?Sized,
[src]
T: ?Sized,
fn borrow_mut(&mut self) -> &mut T
[src]
impl<T> From<T> for T
[src]
impl<T, U> Into<U> for T where
U: From<T>,
[src]
U: From<T>,
impl<T> ToOwned for T where
T: Clone,
[src]
T: Clone,
type Owned = T
The resulting type after obtaining ownership.
fn to_owned(&self) -> T
[src]
fn clone_into(&self, target: &mut T)
[src]
impl<T, U> TryFrom<U> for T where
U: Into<T>,
[src]
U: Into<T>,
type Error = Infallible
The type returned in the event of a conversion error.
fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>
[src]
impl<T, U> TryInto<U> for T where
U: TryFrom<T>,
[src]
U: TryFrom<T>,