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
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/liblas-devel
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
