[Liblas-devel] ReadPointAt bug

[Howard Butler]

On Apr 22, 2008, at 9:30 AM, Mateusz Loskot wrote:
> 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.


Ok, I have fixed this with http://liblas.org/changeset/572 and http://liblas.org/ticket/34

I will make a new release later tonight.

Howard