<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt><br>
Hello Mateusz,<br>
<br>
Thank you for looking at that so quickly. As long as I am making
suggestions, I have two more both relating to building with MSVC
version 9, SP1 using makefile.vc and nmake.opt:<br>
<br>
1) Please consider removing /GR from OPTFLAGS. Using a non-default
calling convention produces somewhat puzzling linker errors when
attempting to statically link against libLas.<br>
<br>
2) Please consider using /Z7 for debug info in OPTFLAGS instead of
/Zi. /Z7 produces C7 style debugging information which is directly
embedded in the library eliminating the need for a separate .pdb file.
<br>
<br>
Cordially,<br>
<br>
Erik<br>
<br>
</tt><br>
On 9/25/2008 12:23, Mateusz Loskot wrote:
<blockquote
cite="mid:58193.195.24.248.244.1222363409.squirrel@loskot.net"
type="cite">
<pre wrap="">Erik Jacobsen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello All,
First, I would like to thank the developers for this excellent library.
It has been easy to use, particularly after the addition of makefile.vc.
I have been trying it with various data sets and have discovered what
appears to be a bug. The data set in question contains points that are
below sea level (i.e. z values are negative). After reading with
liblas, the z values are instead ~4 billion. This was with 1.0.0b1, so
I downloaded trunk-r878 and duplicated the problem. When stepping
through the code I discovered that the coordinates are being stored in a
uint32_t instead of an int32_t. The LAS 1.1 specification for "POINT
DATA RECORD FORMAT 0" states that X, Y and Z are stored in "long" which
is defined to be a signed 4 byte quantity (page 6). The following patch
solves the problem and produces sane results:
C:\dev\LAS\trunk\include\liblas\detail>"C:\Program Files
(x86)\GnuWin32\bin\diff.exe" util
ity.hpp C:\dev\las\utility.hpp
185,187c185,187
< int32_t x;
< int32_t y;
< int32_t z;
---
> uint32_t x;
> uint32_t y;
> uint32_t z;
Please consider including it in the trunk.
Thank you,
Erik
</pre>
</blockquote>
<pre wrap=""><!---->
Erik,
Thank you for this report and patch.
Certainly, your analysis is correct and we have a bug in libLAS.
I've submitted your report as ticket on the libLAS Trac adding your e-mail
to CC:
<a class="moz-txt-link-freetext" href="http://liblas.org/ticket/76">http://liblas.org/ticket/76</a>
I will fix it tonight when I'm back home.
Best regards,
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Erik Jacobsen, Power Line Systems, Inc.
Email: <a class="moz-txt-link-abbreviated" href="mailto:jacobsen@powline.com">jacobsen@powline.com</a>
Phone: (608) 238-2171 x104
Fax: (608) 238-9241
Web: <a class="moz-txt-link-freetext" href="http://www.powline.com/">http://www.powline.com/</a>
</pre>
</body>
</html>