Archive for the ‘liblas’ Category

Kitware Developer blog launched

Thursday, January 28th, 2010

CMake - cross-platform build systemA few minutes ago, Bill Hoffman from Kitware posted short message to the CMake project mailing list with an interesting announce:

Kitware launched its first developer blog today with contributions from Company technical and business leaders.

The CMake build system is one of the main category of topics on the Kitware blog, so I presume it may be of interest of OSGeo Community as the CMake build system is slowly winning over more and more folks here :-)

First CMake-related post is about Deploying on Windows with DLL Manifest Issue

Another interesting post on the blog is Will Schroeder’s answer to the question Why Open Source Will Rule Scientific Computing? It’s really worth reading.

illegal token on right side of ‘::’

Wednesday, January 27th, 2010

libLAS - ASPRS LiDAR data translation toolsetOne of libLAS users reported that when use of #include <liblas/lasreader.hpp> in his application compiled with Visual C++ 10.0 from Visual Studio 2010 cause this error:

utility.hpp(253): error C2589: '(' : illegal token on right side of '::'

The error is an incarnation of a very well-known problem in Visual C++ when using the C++ Standard Library elements, especially the Standard Template Library, in Windows API-based programs. As libLAS library does use the C++ library, so does a user’s application if includes libLAS headers.

The problem is caused by conflicting definitions of min() and max() macros defined in windef.h header. Macros in C++ are scope-less evil, especially if defined in public headers using such extremely unique names as min or max. The fact that Microsoft defined it way before C++ was born absolves them at large, but for the Spirit sake, they should learn the lesson and disable it for good in C++ mode (but not yet another MS-specific way!). No one who’s sane need or want to use them!

Pie in the sky. In the meantime, C++ programmers as the libLAS user who reported this problem have to deal with it on their own. The easiest way is to check CodeProject or Q143208 or search (not google) for solution like #define NOMINMAX for Visual C++ compiler.

However, is another option is to apply a simple trick to call of *::min() or *::max() functions (i.e. std::min() or std::max() which effectively prevents macro substitution, so the Visual C++ compiler (or any other compiler with similar problem) does not complain about illegal token. The trick is to wrap function name, fully qualified name, with parentheses:

(std::min)(x, y);

In most cases of use of C++ Standard Library as described above, it is required for the following functions:

(std::min)(x, y);
(std::max)(x, y);
(std::numeric_limits<T>::min)();
(std::numeric_limits<T>::max)();

In case a user-defined type has a member function with exactly the same name as a macro present in global scope (macros always live in global scope!), it may be necessary to apply the very same trick when a member function is called on an object:

template <typename T, int Size>
struct Series
{
  T min() { return *(std::min_element(s, s + Size); }
  T& operator[](int index) { return s[index]; }
private:
  T s[Size];
};

Series<int, 3> s;
s[0] = 2;
s[1] = 3;
s[2] = 1;

int m = (s.min)(); // long way, but here is the trick

There is one side effect which may be an inconvenience. This trick disables argument dependent name lookup (ADL, aka Koenig lookup).

libLAS server migration

Saturday, December 5th, 2009

libLAS - ASPRS LiDAR data translation toolsetYesterday, Howard migrated libLAS project to new server. There should hopefully be no disruption other than the usual DNS stuff, but in case of problems let us know.

Testing libLAS with CMake

Sunday, October 25th, 2009

libLAS - ASPRS LiDAR data translation toolset As a part of CMake configuration for libLAS, I’ve enabled support CTest. It is CMake test driver program that can be used to run automated tests and perform continuous integration. I also registered libLAS at CDash testing server.

CDash aggregates, analyzes and displays the results of software testing processes submitted from clients located around the world

Check libLAS dedicated quality dashboard registration is required it is public project and available for anonymous visitors to browse the dashboard (thanks to Julien from Kitware for quick fix).

Anyone who is would like to build libLAS using CMake and run tests can find details on the CMake article on the Wiki. I would also encourage interested users to issue make Continuous to submit test results to the dashboard.

Feedback kindly wanted!

Co za CUDA!

Saturday, October 10th, 2009

The singular processing is dead. Long live the multiprocessing.

I can not even imagine effectiveness of exploitation of such a power by issuing little gdalwarp command. GDAL, libLAS, are we ready to squeeze out this CUDA’ny juice?

Co za CUDA! Yes, indeed!

libLAS package for Debian

Thursday, October 8th, 2009

Francesco Paolo Lovergine announced new libLAS packages:

Today, libLAS 1.2.1 entered the main archive, so it will be included in Squeeze. The Python binding will follow in the next days.

Kudos to Francesco for the great effort in spreading libLAS!

libLAS 1.2.1 Released

Friday, October 2nd, 2009

libLAS - ASPRS LiDAR data translation toolset Howard just posted announcement about patch of libLAS 1.2.1 release.

Detailed list of fixes includes:

  • #120 – support ‘comma’ as a separator in las2txt
  • #121 – las2txt and txt2las don’t work with the Point Source ID
  • #122 – las2las does not eliminate requested classifications
  • #124 – some files have pad bytes when they shouldn’t
  • #127 – Scan flags is order sensitive
  • #129 – Version.rc doesn’t make the release
  • #132 – Require libgeotiff when GDAL is requested
  • #133 – FreeBSD endian.hpp
  • #134 – GDAL transform translates the points incorrectly when there is a scale or translation on the points
  • #136 – Problem overwritting Reader’s dataoffset due to VLR
  • #139 – txt2las is not setting the point source id correctly for values > 255
  • #140 – liblas 1.2 linking problems due to –with-hide-internals gdal option
  • #141 – lasinfo in not reporting info about point source id
  • #143 – libLAS 1.2 requires GDAL 1.7 (unreleased)
  • #144 – Apps should take in filenames without -i argument
  • #145 – Memory leak from LASWriter / lasspatialreference assignment operator=
  • #148 – No prototype in core.py for LASPoint_Destroy

On behalf of the libLAS team, thanks to all who provided bug reports and patches!

Before delivering next major release of libLAS, there is one big issue that must be fixed. It is problem with large files under Windows 32-bit operating system – ticket #147. Volunteers are welcome to take care of it :-)

I would also like to see completed build configuration based on CMaketicket #52. It is already usable on Unix (GCC) and Windows (Visual C++), so testers are welcome to give it a try and give us feedback.