gadomski/las-rs

Incorrect Start of First EVLR in Public Header Block

Closed this issue · 4 comments

but0n commented

The calculation of point data length is only valid when exporting las file, i.e. without compression

las-rs/src/header/mod.rs

Lines 708 to 710 in 34fd596

fn point_data_len(&self) -> u64 {
self.number_of_points * u64::from(self.point_format.len())
}

las-rs/src/header/mod.rs

Lines 679 to 685 in 34fd596

let start_of_first_evlr = self.point_data_len()
+ self.point_padding.len() as u64
+ u64::from(self.offset_to_point_data()?);
Ok(Some(raw::header::Evlr {
start_of_first_evlr,
number_of_evlrs: n as u32,
}))

I also found a typo here:

las-rs/src/raw/header.rs

Lines 417 to 419 in 34fd596

let elvr = self.evlr.unwrap_or_default();
write.write_u64::<LittleEndian>(elvr.start_of_first_evlr)?;
write.write_u32::<LittleEndian>(elvr.number_of_evlrs)?;

gadomski commented

I think that the calculation doesn't matter for compressed data, because we started ignore the offset_to_point_data in #76. Did you run into an error with reading or writing?

but0n commented

I'm using this library to generate COPC files. It is essentially a laz file with support of variable chunk size and two additional VLRs. However, it needs to know the offset to the first evlr. I found this error when using start_of_first_evlr. I think it would be handy to have a valid start_of_first_evlr.

gadomski commented

Right on, thanks @but0n. I believe the issue should be fixed by #91. I've done a large amount of refactoring as well, so the next release will be breaking. So you can test to make sure things are good (if you'd like), I'm going to release this as a beta version first (v0.9.0-beta.0) ... I'll update here when that's done.

  • 👍1