[Liblas-devel] ReadPointAt bug

[Mateusz Loskot]

Mateusz Loskot wrote:
> Howard Butler wrote:
>> I'm not sure, and we would need a spec hound to verify, but I think 
>> that the file in question is not following the spec.  It *says* it is 
>> 1.0, but it has a 28 byte record length (this would imply a 1.1 
>> version file, right)?  So, who are we to believe?  The file version, 
>> like we were doing, or the record length, which in this case produces 
>> the correct results?
>>
>> Mateusz, do you have anything to add on this?
> 
> There are two identifiers that control LAS file processing:
> 
> 1. LAS File Version (1.0 or 1.1)
> 2. Point Format ID (0 or 1)
> 
> So, following combinations are valid:
> 
> - point record size is 20 bytes
> 1.0 & 0
> 1.1 & 0
> 
> - point record size is 28 bytes
> 1.0 & 1
> 1.1 & 1
> 
> The libLAS strongly depends on what's written to the header, so this 
> information must be as stated above, otherwise we are dealing with 
> invalid LAS file.
> 
> If the information in header is correct, then we likely are having a bug.
> 
> Which one is true?


OK, we know, we have a bug. We've discussed it with Hobu and use of the 
m_recordLength value should fix the problem:

[16:23]  <hobu> should we rework the code to explicitly pass the sizes 
around, or is caching the recordlength good enough?
[16:24]  <mloskot> I don't think we need to pass sizes
[16:24]  <mloskot> The m_recordLength is set correctly
[16:24]  <mloskot> according to the format ID
[16:24]  <mloskot> see LASHeader::GetDataRecordLength()
[16:25]  <hobu> ok
[16:25]  <mloskot> The m_recordLenght value is set when header is read
[16:25]  <mloskot> So, it is IMO fine to use this value for offset 
calculations


I'll take a closer look at it and run some tests.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net