[Liblas-devel] Point Scale/Offset Behavior, Possible Bug.

[Howard Butler]

On Jun 17, 2011, at 9:24 AM, Black, Tim wrote:

> On a quick side note, what is the procedure for submitting bug reports? I went to the “Bugs” link, but I couldn’t see a way to submit without being able to log in to the site.

You would normally register for a login, but I started getting lots of spam on the Trac instance.  I presume it needs to be updated with better captcha, but I haven't had the time.  If you want a login really bad, join #liblas on irc.freenode.net, and I'll coordinate turning on the registration for a bit while you get a login, and then I'll shut it off again.

> However, looking at the point.cpp code, it looks as though the data is only updated if the point format(And subsequently, the size of the point data) is changed. 

I agree what you're describing demonstrates a bug.  The coordinate data still need to be rescaled with respect to the old header in the case case where the two header's scale/offset values are different. I'll file one on the Trac instance and attempt to fix it.

Coincidently, I was just spinning up the machine to prep for the libLAS 1.7.0 release. I'll see what I can do here. Can you pull today's source and rebuild?  I have removed the shared_ptr that was being attached to every point and instead replaced this with a boost::optional<liblas::Header>.  The shared_ptr was causing some serious non-linear performance issues (I obviously mis-applied the usage of shared_ptr in this case). The performance win for large files (>20mil points) is dramatic. Sorry.




>  
> While working on modifying (Mainly reprojection and conversion of units) some point data, I came across some odd behavior. First, I would read the data in from File A and make any adjustments required. Next, I would write the file out to File B with updated header information. However, when I subsequently read the data in from File B, the values would be incorrect. After some trial and error, I realized that the problem was with differences in the offset and scale in the headers of File A and File B. Normally, the point data is stored with the scale and offset applied. When a new header is assigned to the pointer, it should be updated to reflect the new values. Otherwise, it returns before reaching the code that updates the coordinates. The section of code below is taken from line 366+ of the point.cpp class. I am currently running 1.6.1, but it also appears that the problem will still occur in the current trunk.(I have not built and tested the latest version, so I can’t say for certain) The problem occurs in the else block of code. If the point format is the same but the offset has changed, the return there prevents the XYZ coordinates from being updated with the new offset.
>  
> [After determining data size of new header]
> if (wanted_length != m_data.size())
>     {
>         // Manually copy everything but the header ptr
>         // We can't just copy the raw data because its
>         // layout is likely changing as a result of the
>         // schema change
>       [Snipped copying of metadata for space]
>     } else
>     {
>         m_header_new = header;
>         return;
>     }
>  
>     double x;
>     double y;
>     double z;
>    
>     if (bSetCoordinates)
>     {
>         x = GetX();
>         y = GetY();
>         z = GetZ();       
>     }
>    
>     // The header's scale/offset can change the raw storage of xyz. 
>     // SetHeaderPtr can result in a rescaling of the data.
>     m_header_new = header;
>  
>     if (bSetCoordinates)
>     {
>         SetX(x);
>         SetY(y);
>         SetZ(z);
>     }
>  
> Tim Black
> Ball Aerospace
> 571-357-2158
>  
> This message and any enclosures are intended only for the addressee.  Please  
> notify the sender by email if you are not the intended recipient.  If you are  
> not the intended recipient, you may not use, copy, disclose, or distribute this  
> message or its contents or enclosures to any other person and any such actions  
> may be unlawful.  Ball reserves the right to monitor and review all messages  
> and enclosures sent to or from this email address.
> 
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel