Peder reported problems with setting classification flags GetClassification() et al. . It turns out Point::SetClassification sets 8 bits of classification only with class index missing the other three bits from 5 to 7. The bug has been confirmed.

(testing @github issues reporting my very first issue)

Hi,
My apologies if this is not a bug but just ignorance on my part. I am calling las2las --t_srs and it seems to work for some coordinate systems but not others. I have built it with GDAL and Geotiff and I have gone through the source code but I am not sure where the coordinate systems transformation is being called. I have included a detailed explanation of what I am doing below.

I have multiple lidar data sets and I am trying to reproject them using liblas. They are missing the coordinate system in the header information so I assign them an SRS using las2las --a_srs:

las2las -v input.las --a_srs EPSG:28992
The result is an updated header:

Spatial Reference:
LOCAL_CS["Amersfoort / RD New",
GEOGCS["Amersfoort",
DATUM["unknown",
SPHEROID["unretrievable - using WGS84",6378137,298.257223563],
TOWGS84[565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
AUTHORITY["EPSG","28992"],
UNIT["metre",1]]
I then try and convert them to my preferred projection (WGS84) using t_srs:

las2las -v assigned.las --t_srs EPSG:4326
and I get the following error:

ERROR 1: No PROJ.4 translation for source SRS, coordinate
transformation initialization has failed.
ERROR 10: Pointer 'hTransform' is NULL in 'OCTTransform'.

Normally the error is caused by an incorrect path for GDAL or PROJ4 but I have explicitly defined them (/usr/share/gdal/1.11 and /usr/shar/proj respectively).

Even more strange is if it works if I try the data in the test/data folder. If I try and convert between EPSG:3857 and EPSG:4326, or between NAD83 and EPSG:4326 that works fine. This would mean it is not a path problem but that it cannot access the correct transformation.

I also checked the proj folder to see if it contained the correct transformation, it had it in two separate files:

epsg:<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs <>
esri:<28992> +proj=stere +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs no_defs <>
Any idea what might be causing this error? Any help would be greatly appreciated!

If you want some of the source data, I took it from the Dutch point cloud website: http://3dsm.bk.tudelft.nl/matahn

Some parameters (like "${libLAS_SOURCE_DIR}/cmake/modules" and "${LIBLAS_HEADERS_DIR}/exception.hpp") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like spaces.

I would recommend to apply advices from a Wiki article.

las2las -c -i Whitehorse_07.las -o Whitehorse_07.laz

las2las (libLAS 1.7.0 with GeoTIFF 1.3.0 GDAL 1.8.1 LASzip 2.1.0) installed via Osgeo4W 32bit, this morning.

X:\>lasinfo Whitehorse_07.las
---------------------------------------------------------
  Header Summary
---------------------------------------------------------

  Version:                     1.3
  Source ID:                   0
  Reserved:                    1
  Project ID/GUID:             '00000000-0000-0000-0000-000000000000'
  System ID:                   'EXTRACTION'
  Generating Software:         'RiPROCESS 1.6'
  File Creation Day/Year:      294/2014
  Header Byte Size             235
  Data Offset:                 425
  Header Padding:              0
  Number Var. Length Records:  2
  Point Data Format:           1
  Number of Point Records:     12494692
  Compressed:                  False
  Number of Points by Return:  12491511 3177 4 0 0
  Scale Factor X Y Z:          0.0003 0.0003 0.0003
  Offset X Y Z:                498197.0000 6728367.0000 653.0000
  Min X Y Z:                   495138.9100 6727527.5575 625.7375
  Max X Y Z:                   498620.1875 6736013.2100 714.0650
  Spatial Reference:
LOCAL_CS["NAD83, GRS80, NAD83 / UTM zone 8N",
    GEOGCS[,
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    UNIT["metre",1]]

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTCitationGeoKey (Ascii,34): "NAD83, GRS80, NAD83 / UTM zone 8N"
      GeogLinearUnitsGeoKey (Short,1): Linear_Meter
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      End_Of_Keys.
   End_Of_Geotiff.


---------------------------------------------------------
  VLR Summary
---------------------------------------------------------
    User: 'LASF_Projection' - Description: 'GeoKeyDirectoryTag (mandatory)'
    ID: 34735 Length: 48 Total Size: 102
    User: 'LASF_Projection' - Description: 'GeoASCIIParamsTag (optional)'
    ID: 34737 Length: 34 Total Size: 88
---------------------------------------------------------
  Schema Summary
---------------------------------------------------------
  Point Format ID:             1
  Number of dimensions:        13
  Custom schema?:              false
  Size in bytes:               28

  Dimensions
---------------------------------------------------------
  'X'                            --  size: 32 offset: 0
  'Y'                            --  size: 32 offset: 4
  'Z'                            --  size: 32 offset: 8
  'Intensity'                    --  size: 16 offset: 12
  'Return Number'                --  size: 3 offset: 14
  'Number of Returns'            --  size: 3 offset: 14
  'Scan Direction'               --  size: 1 offset: 14
  'Flightline Edge'              --  size: 1 offset: 14
  'Classification'               --  size: 8 offset: 15
  'Scan Angle Rank'              --  size: 8 offset: 16
  'User Data'                    --  size: 8 offset: 17
  'Point Source ID'              --  size: 16 offset: 18
  'Time'                         --  size: 64 offset: 20

---------------------------------------------------------
  Point Inspection Summary
---------------------------------------------------------
  Header Point Count: 12494692
  Actual Point Count: 12494692

  Minimum and Maximum Attributes (min,max)
---------------------------------------------------------
  Min X, Y, Z:          495138.9115, 6727527.5595, 625.7395
  Max X, Y, Z:          498620.1855, 6736013.2080, 714.0630
  Bounding Box:         495138.9115, 6727527.5595, 498620.1855, 6736013.2080
  Time:                 94432886.026351, 94433134.664127
  Return Number:        1, 3
  Return Count:         1, 3
  Flightline Edge:      0, 1
  Intensity:            5734, 65535
  Scan Direction Flag:  1, 1
  Scan Angle Rank:      -38, 39
  Classification:       0, 0
  Point Source Id:      0, 0
  User Data:            0, 0
  Minimum Color (RGB):  0 0 0
  Maximum Color (RGB):  0 0 0

  Number of Points by Return
---------------------------------------------------------
        (1) 12491511    (2) 3177        (3) 4

  Number of Returns by Pulse
---------------------------------------------------------
        (1) 12488334    (2) 6346        (3) 12

  Point Classifications
---------------------------------------------------------
        12494692 Created, never classified (0)
  -------------------------------------------------------
        0 withheld
        0 keypoint
        0 synthetic
  -------------------------------------------------------

I'm waiting on an enquiry if it's okay to share the source file.
Any other useful information I could provide?

LASINFO crashes when used with LAZ files.
System info: Dell Precision T7600, 16GB RAM, Windows 7x64 SP1 Ultimate.
Steps to reproduce:

1. Follow steps found here to install from OSGeo4W: http://www.liblas.org/osgeo4w.html
   *** Note that I am using the current release, which is newer than what is shown in the screen shots. Also note that I included the liblas development package.
2. From the libLAS OSGeo4W shell prompt, invoke lasinfo as follows:
   lasinfo -i TO_core_last_zoom.laz

I obtained the file TO_core_last_zoom.laz from online after trying to use lasinfo with some of my own laz files, thinking that my laz files may not be valid. It turns out that lasinfo crashes with any laz file I use. Other software packages, such as Quick Terrain Reader x64, v7.1.6 build 50592, are able to read these same laz files.

I will be happy to provide the laz files and the crash dump if necessary.

The routines to find and link to gdal are broken for me after the switch to cmake.

What I'm seeing is an error like:

make[2]: *** No rule to make target `/out/build-cpp03-libstdcpp-x86_64/lib/libibstdcpp-x86_64/libgdal.dylib', needed by `bin/Release/liblas.2.2.0.dylib'.  Stop.
make[2]: *** Waiting for unfinished jobs....

This appears to happening because the path to my custom built GDAL has a lib in a directory name. I'm seeing that GDAL exists at

out/build-cpp03-libstdcpp-x86_64/lib/libgdal.dylib

but is trying to be linked incorrectly at:

out/build-cpp03-libstdcpp-x86_64/lib/libibstdcpp-x86_64/libgdal.dylib

If I visit http://www.liblas.org/docs.html and click on C++ Class API (in the panel
on the left) I get taken to http://www.liblas.org/doxygen/annotated.html and a
message saying 404 Not Found. I'm sure this is some simple misconfiguration!
Please fix...

--Charles

Hi,

I'm just working through the osgeo live dvd trying to find space wherever I can, and I notice that the liblas PNG images are compressible by ~15-40%. could you pre-shrink those in your repo?

apt-get install optipng
optipng -o5 *.png

thanks,
Hamish

Using libLAS master from yesterday, I get an assertion when trying to write compressed laz files:

Assertion failed: data->size() == m_zipPoint->m_lz_point_size, file ....\src\detail\writer\zipwriter.cpp, line 123

It is exactly as described in http://lists.osgeo.org/pipermail/liblas-devel/2013-May/001575.html

It seems that data->size() is always 34, whereas m_zipPoint->m_lz_point_size changes according to the sizeof() a point as set with DataFormatId. So liblas::ePointFormat0 is 20, liblas::ePointFormat1 is 28, and liblas::ePointFormat3 works, because its 34.

I use msvc 2012 on windows 7 x64. Using self-built las2las to write compressed laz files works.

when running las2txt I get the following message,

Peters-Mac-mini:f14 peter$ las2txt -v --parse xyzai -i f14_014_018.laz -o stdout --keep-scan-angle "<=100"
Opening f14_014_018.laz to fetch Header
Keeping scan angles with values: <=100
error: bad lexical cast: source type value could not be interpreted as target

Some problem in laskernel.cpp maybe?

This is built with boost version 1.52.0 version string from las2txt

las2las (libLAS 1.7.0 with GeoTIFF 1.4.0 GDAL 1.9.2 LASzip 2.1.0)

Some of the utilities documented here were removed from libLAS, and should either be removed, individually edited to reflect this situation, or be moved to a different section in doc/utilities/index.txt.

These historic utilities include:

• lasmerge
• lasdiff
• las2tindex

Hi
i have problem when building

 $ make
 [ 52%] Built target las
 [ 53%] Built target las_c 
 Linking CXX executable ../bin/Release/bigfile_boost_iostreams_test
 ../bin/Release/liblas.so.2.3.0: undefined reference to `GTIFAllocDefn'
 ../bin/Release/liblas.so.2.3.0: undefined reference to `GTIFFreeDefn'
 collect2: error: ld returned 1 exit status
 make[2]: *** [bin/Release/bigfile_boost_iostreams_test] Error 1
 make[1]: *** [apps/CMakeFiles/bigfile_boost_iostreams_test.dir/all] Error 2
 make: *** [all] Error 2

I look forward to any suggestions

The functions LASReader_GetNextPoint and LASReader_GetPointAt are declared as having the return type const LASPointH, and both contain qualifier-discarding casts from Point const*. The const here is ignored by the compiler, and indeed, is not present in the header. Given that LASPointH is LASPointHS*, I suspect the const is intended to make the return type to be rather LASPointHS const*. (And this is why I personally abhor ever placing const to the left of a type, but we needn't go there 😄.)

I'd love to make a pull-request with a fix, but I'm not sure what is the intent here. Should the return type be a pointer-to-const? Or should the const-ness be cast away?

We regularly get LAS data (especially older files) which were compressed with zip or rar (rather than being stored as LAZ).

Since there doesn't seem to exist reading from stdin (allowing to pipe the output of the uncompressor into liblas tools), could the open function of liblas be modified to read these files directly?

Unrar code reference:

• https://en.wikipedia.org/wiki/Unrar#GNA_UnRAR

Unzip code reference:

• http://sourceforge.net/projects/infozip/files/

Hey,
the module to find proj4 seems to be missing. I downloaded a similar module from another project but now I am having problems changing projections and maybe this is the cause. Is there a reason why this package was left out?

Sorry just found it, and don't have yet time to patch it.
Creating documentation and just seen
Current Release(s)
• 2012-01-06
• libLAS-1.7.0-src.tar.gz (md5)
• libLAS-1.7.0-src.zip (md5)
• See OSGeo4W for Windows release.

Need to be fixed

When I try to run LAS 1.4 files through libLAS I get an error that the minor version is out of range.
If I just change the files' header information, all works well.

I suggest that libLAS will accept LAS 1.4 files too, with previous functionality.

I'm not suggesting that libLAS would handle waveform data, although it would be nice if the lasinfo tool would also present the additional header information in LAS 1.4.

Best regards,
/Peder Axensten

(libLAS 1.8.0 with GeoTIFF 1.4.0 GDAL 1.11.1 LASzip 2.2.0)

I am attempting to merge multiple las files into one las file using lasmerge from libLAS. After the merge I notice that the point inspection summary has Min X,Y,Z as negative values. However, lasinfo of the source files reports a positive Min X,Y,Z for each. I can provide more details if necessary. The reason this appears to be a problem is that the extent/clip functionality las2las doesn't appear to work with these merged data. Does anyone have a suggestion for me? I am using libLAS installed with OSGeo4w.

Thanks,
Roland

It would be cool to have libLAS as a conda package (http://technicaldiscovery.blogspot.com/2013/12/why-i-promote-conda.html, http://conda.pydata.org/docs/build.html) so that folks using conda could just do:

conda install liblas

This would require building boost as a conda package also, but that would be useful in it's own right.

The sentence: "libLAS builds upon by Martin Isenburg and Jonathan Shewchuk of LLNL/UC Berkeley in their LAStools project to do a number of things." at http://www.liblas.org/ is not written in proper English.

Currently I've found that two things prevent easily linking against a libgdal.a with the new cmake scripts:

1. The dynamic library extention is hardcoded currently for both OS X and Linux at:

   libLAS/cmake/modules/FindGDAL.cmake

   Lines 247 to 251 in 59709b3

   	IF(APPLE)
   	SET(GDAL_LIBRARY ${GDAL_LINK_DIRECTORIES}/lib${GDAL_LIB_NAME}.dylib CACHE STRING INTERNAL)
   	ELSE()
   	SET(GDAL_LIBRARY ${GDAL_LINK_DIRECTORIES}/lib${GDAL_LIB_NAME}.so CACHE STRING INTERNAL)
   	ENDIF()

   . @mloskot mentions here that perhaps a GDAL_USE_STATIC_LIB option could be added to instead choose .a. However: I wonder why GDAL is different than other libs in this case? The libzip.a and libgeotiff.a I am using are found just fine currently.
2. Potential duplicate symbols from gt_wkt_srs.cpp because it is also included in libgdal.a. I've solved this in my case by completely avoiding building gt_wkt_srs.cpp: https://github.com/mapnik/mapnik-packaging/blob/master/osx/patches/liblas-skip-gt_wkt_srs.diff. This avoids the linking error:

duplicate symbol _GTIFGetOGISDefn in:
    CMakeFiles/las.dir/gt_wkt_srs.cpp.o
    /Users/dane/projects/mapnik-packaging/osx/out/build-cpp03-libstdcpp-x86_64/lib/libgdal.a(gt_wkt_srs.o)

I have patches to the cmake configuration for libLAS 1.7.0 (roughly in
order of importance):

(1) Add support for find_package(libLAS). Installation adds a file
liblas-config.cmake to the installation tree and find_package will use
this to determine the include directories and library paths.

(2) Fix FindGeoTIFF.cmake so that it works for Linux (PATH_PREFIXES
should be PATH_SUFFIXES and libgeotiff needs to be search as will as
geotiff).

(3) Remove -pedantic compilation option for Unix because it causes
compilation to fail with boost 1.15.0 under Linux (because of a comma at
the end of an enum list).

(4) Add runtime library path to libLAS utilities for Unix.

(5) Remove -Wcast-qual, -Wfloat-equal, and -Wredundant-decls compilation
options for Unix to reduce the number of compilation warnings.

If I'm allowed to upload the patches somewhere, I'll do that. Otherwise
I can E-mail them to a maintainer.

--Charles

Trying to compile for Mac OS X using cmake -G "Xcode" ..

Unable to find the requested Boost libraries.

Boost version: 1.52.0

Boost include path: /Users/oskarlin/Downloads/boost_1_52_0

The following Boost libraries could not be found:

      boost_program_options
      boost_thread

No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.

Hi there,

I am trying to make a simple classification filter. I am new to liblas, so I'm using the tutorial on the liblas website as a guide (http://www.liblas.org/tutorial/cpp.html#applying-filters-to-a-reader-to-extract-specified-classes). Unfortunately I am getting a couple of compile errors when building this.

Firstly, the line in the code:

std::vector<liblas::uint8_t> classes;

Gives a compile error because uint8_t is not a member of liblas - I change this line to

std::vector<boost::uint8_t> classes;

and the compile error disappears (but maybe the problem doesn't?!).

However, then there is a compilation error associated with the line:

liblas::FilterPtr class_filter = liblas::FilterPtr(new liblas::ClassificationFilter(classes));

which I have included below:
liblas_test.cpp: In function int main(int, char**):
liblas_test.cpp:34: error: no matching function for call to liblas::ClassificationFilter::ClassificationFilter(std::vector<unsigned char, std::allocator >&)
/usr/include/liblas/filter.hpp:135: note: candidates are: liblas::ClassificationFilter::ClassificationFilter(const liblas::ClassificationFilter&)
/usr/include/liblas/filter.hpp:128: note: liblas::ClassificationFilter::ClassificationFilter(liblas::ClassificationFilter::class_list_type)

Is anyone aware of a solution to this problem? I guess that since this is one of the tutorials, people will have come across a similar problem.

Many thanks,

David

As of 7d00246, liblas can no longer be configured if GDAL is not found. The unconditional search for the package, combined with unconditional use of the libraries and include paths, results in CMake errors due to trying to link to "GDAL_LIBRARY-NOTFOUND".

(It looks like c60f4ce tries to fix this, but is missing similar operations for the GDAL variables. Also... unset 😄.)

The 'conflicting types' discussed in the comments of #33 breaks 1.7.0 (and 1.7.1b1). The break was fixed by b8799e5.

Would it be possible to tag (and release?) a new version, possibly 1.7.2, that includes the fix? I ask so we can bump the version included in Homebrew, since right now brew install liblas fails (though liblas can be installed via brew install liblas --HEAD).

On a mac OSX build, lasinfo and las2las both fail to open qfit-format files:

lasinfo 20100526_132941.atm4bT2.qi
error: invalid file signature

Running lasinfo on the demo data set from lastools (xyzrgb_manuscript.las) gives reasonable-looking results.

Hi,

I am trying to install liblas on a Windows machine from the OsGEO set of tools. The installation works but I get an error 'cannot start program because MSVCR120D.dll missing on your computer' when i run lasinfo or las2las.
Any ideas on why this is happening?

The tutorial at

http://www.liblas.org/tutorial/cpp.html#creating-a-compressed-laz-file-from-a-las-file

has a few minor bugs, more specifically it does not compile. I had to do the following fixes to make it work:

1. Add

 #include <liblas/iterator.hpp>
using namespace liblas;

1. Instead of

header.Compressed(true);

use

header.SetCompressed(true);

I am new to this forum, and this is my first issue.
Am using MS Visual Studio 2013. Using the library to sequentially read a .las file.

This bug is an issue when the actual .las file contains less data than returned by the GetPointRecordsCount () call.

The debug version is able to read from begin to end, stopping properly at EOF, even if the last record is only partially complete.

The release version, however, will give you one extra record depending:

1. If the last record in the file is complete, ReadNextPoint() will return a duplicate.
2. If the last record in the file is incomplete, ReadNextPoint() will return a record that will contain portions of the previous record.

I have traced the problem to the check_stream_state() function where the error detection mechanism is disabled in the release build.

Please verify. Thanks.

Hi, when I’m trying import liblas, I have an error:
File "C:\Python34\lib\site-packages\liblas__init__.py", line 2, in
from core import get_version
ImportError: No module named 'core'
Do you have any idea how to fix it?
PS. I have file core.py

There's no git tag for the 1.7.0 release.

Hey folks. Thank you for the good work. Just a note: the download link at

http://www.liblas.org/download.html

for version 1.8 does not work. It can be fixed by replacing .gz with .bz2.

Thanks!

A small fix is needed in

http://www.liblas.org/tutorial/cpp.html#writing-using-liblas-writer

The line

liblas::Point point;

no longer compiles with the released liblas. What is needed is something like:

liblas::Point point(&header);

lasblock --help
...
For more information, see the full documentation for lasblock at:
http://liblas.org/utilities/block.html
--> should be: http://liblas.org/utilities/lasblock.html

One more:
http://liblas.org/utilities/las2ogr.html
A "lasdiff compares two LAS..." sentence leaked into this part, maybe it should not be there?

And one more:
http://liblas.org/index.html
--> the left side menu "Bugs" link points to the expired trac rather than git

I am using libLAS with C#, saving a list of LASPoints in a concurrent dictionary to be used later.
When I access them later they are all corrupted.

Any idea why this happens,

Regards,

print_header() is defined differently multiple times.

Would it make sense to add the prototype to lascommon.h?

Or at least consistently use the same prototype, e.g.:

--- a/apps/las2las-old.c
+++ b/apps/las2las-old.c
@@ -30,7 +30,7 @@
 LASPointSummary* SummarizePoints(LASReaderH reader);
 void print_point_summary(FILE *file, LASPointSummary* summary, LASHeaderH header);
 void print_point(FILE *file, LASPointH point);
-void print_header(FILE *file, LASHeaderH header, const char* file_name, int bSkipVLR);
+void print_header(FILE *file, LASHeaderH header, const char* file_name, int bSkipVLR, int bWKT);
 void repair_header(FILE *file, LASHeaderH header, LASPointSummary* summary) ;

 #define LAS_FORMAT_10 0
--- a/apps/las2txt.c
+++ b/apps/las2txt.c
@@ -18,7 +18,7 @@

 #include "liblas.h"

-void print_header(FILE *file, LASHeaderH header, const char* file_name);
+void print_header(FILE *file, LASHeaderH header, const char* file_name, int bSkipVLR, int bWKT);

 void usage()
 {
--- a/apps/lasmerge.c
+++ b/apps/lasmerge.c
@@ -22,7 +22,7 @@

 LASPointSummary* SummarizePoints(LASReaderH reader);
 void print_point_summary(FILE *file, LASPointSummary* summary, LASHeaderH header);
-void print_header(FILE *file, LASHeaderH header, const char* file_name, int bSkipVLR);
+void print_header(FILE *file, LASHeaderH header, const char* file_name, int bSkipVLR, int bWKT);

 void usage()
 {

As reported in Debian Bug #749403 by Michael Tautschnig:

During a rebuild of all packages in a clean sid chroot (and cowbuilder+pbuilder)
the build failed with the following error. Please note that we use our research
compiler tool-chain (using tools from the cbmc package), which permits extended
reporting on type inconsistencies at link time.

[...]
/usr/bin/cc  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2    -Wl,-z,relro CMakeFiles/las2txt-old.dir/lascommon.c.o CMakeFiles/las2txt-old.dir/las2txt.c.o  -o ../bin/None/las2txt-old -rdynamic ../bin/None/liblas_c.so.2.2.0 ../bin/None/liblas.so.2.2.0 -ltiff -lgeotiff -lgdal -lboost_program_options -lboost_thread -lboost_system -lpthread -Wl,-rpath,/srv/jenkins-slave/workspace/sid-goto-cc-liblas/liblas-1.7.0+dfsg/obj-x86_64-linux-gnu/bin/None: 

error: conflicting function declarations "print_header"
old definition in module lascommon file /srv/jenkins-slave/workspace/sid-goto-cc-liblas/liblas-1.7.0+dfsg/apps/lascommon.c line 407
void (struct _IO_FILE *file, struct LASHeaderHS *header, const char *file_name, signed int bSkipVLR, signed int bWKT)
new definition in module las2txt file /srv/jenkins-slave/workspace/sid-goto-cc-liblas/liblas-1.7.0+dfsg/apps/las2txt.c line 21
void (struct _IO_FILE *, struct LASHeaderHS *, const char *)
apps/CMakeFiles/las2txt-old.dir/build.make:122: recipe for target 'bin/None/las2txt-old' failed
make[4]: *** [bin/None/las2txt-old] Error 64

Indeed there is some variety to be found here. The implementation requires 5
arguments, all of which are actually used (the last ones to make branch
decisions, which will entirely undefined in the following setting):

http://sources.debian.net/src/liblas/1.7.0+dfsg-5/apps/lascommon.c?hl=407#L407

Then there's the 3-argument version here:

http://sources.debian.net/src/liblas/1.7.0+dfsg-5/apps/las2txt.c?hl=21#L21

And a 4-argument version here:

http://sources.debian.net/src/liblas/1.7.0+dfsg-5/apps/lasmerge.c?hl=25#L25

Function calls for all versions exist, so some good amount of undefined
behaviour to be observed.

Best,
Michael

This is not an issue, but I couldn't find any contact information on the liblas website.

I just wanted to let you know that you can easily install liblas via Home brew on Mac using terminal command "brew install liblas".

Pehaps you should update your website with this information!

I am trying to create a new LASPoint that is a copy of a second one. The LASPoint constructor has two signature:

1- LASPoint point = new LASPoint();
2- LASPoint point = new LASPoint(System.IntPtr);

Can some one please tell me how to use the second constructor in C#.

Thanks,

The las 1.2 specification allows the low-order bit of the LAS header's reserved field to be set to 1, to denote that time values are in absolute GPS time, rather than GPS week time. There doesn't seem to be a way to set this flag when supplying absolute GPS time values to txt2las. Perhaps an alternate character would be appropriate, for example:

'--parse txyz', represents GPS week time
'--parse sxyz' represents GPS absolute time.

Perhaps also lasinfo could state through xml and standard out whether the time is absolute or weekly.

I will also attempt to patch as soon as I can.

I'm not sure if this issue is because I was building with mingw-w64 chain or because I'm building with a new boost or because I don't have my boost installed in system folders, anyrate compiling liblas failed at the linker phase.

I had to add system to the list of required libraries

Line 184: libLAS 1.7.0 CMakeLists.txt

Changed from: find_package(Boost 1.38 COMPONENTS program_options thread REQUIRED)

To:
find_package(Boost 1.38 COMPONENTS program_options system thread REQUIRED)

without the above change, I get this error:

Linking CXX shared library ../bin/Release/libliblas.dll
CMakeFiles/liblas.dir/objects.a(indexoutput.cpp.obj):indexoutput.cpp:(.text.star
tup+0x1b): undefined reference to boost::system::generic_category()' CMakeFiles/liblas.dir/objects.a(indexoutput.cpp.obj):indexoutput.cpp:(.text.star tup+0x25): undefined reference toboost::system::generic_category()'

The member function "set_header" in the class "File" in the "file.py"

def set_header(self, header):
"""Sets the liblas.header.Header for the file. If the file is in
append mode, the header will be overwritten in the file."""
# append mode
if mode == 2: # <<<=== should be if self.mode ==2:

Regards,

Yu

I am on Ubuntu 12.04 and have tried the default liblas version, the last stable version (1.7.0) and the current github version.
The issue is that with one small part of a las file, some points with all 0s are produced with a combination of --keep-classes 2 and --extent (this only happens with one specific part of the area).
If I first extract a small part with las2las --extent and then run
las2las test0.las --output test0ground.las --keep-classes 2
some points with all 0s are produced.
When running the --keep-classes command on the complete las file, no points with all 0s are produced.
The result of las2txt for the result of the above command is:

605601.24,6782590.87,736.75,2,2,1,2
605600.18,6782590.82,736.55,2,2,17,2
605604.52,6782592.45,736.81,2,2,14,2
605603.94,6782594.85,736.78,1,1,0,2
0.00,0.00,0.00,0,0,0,0
0.00,0.00,0.00,0,0,0,0
0.00,0.00,0.00,0,0,0,0

If I try to first run las2las --keep-classes 2 on the complete file, and then do las2las --extract for this area, I also get some points with all 0s:

605601.24,6782590.87,736.75,2,2,1,2
605600.18,6782590.82,736.55,2,2,17,2
605604.52,6782592.45,736.81,2,2,14,2
605603.94,6782594.85,736.78,1,1,0,2
605601.76,6782593.89,736.71,1,1,0,2
0.00,0.00,0.00,0,0,0,0
0.00,0.00,0.00,0,0,0,0

I will try to attach the extract of the las file (test0.las) that causes the problems.

We should check methods that create streams to make sure they clean up in cases where a file is not found.

When I compile laszip-2.1.0 with:

./configure --prefix=someDir; make; make install

the header file ends up in

include/laszip.hpp

However, liblas looks for them in

laszip/laszip.hpp

and cannot find them. Am I doing something wrong? Thanks.

Hi,
I have issue, in my script everything items of file las saved (x, y, z, intensity), but not color RGB.
I used this link: http://lists.osgeo.org/pipermail/liblas-devel/2010-July/000904.html

from liblas import file
from liblas import header
from liblas import color
import liblas

LASin = r"D:\SHP\PyLAS\PG1.las"
LASout = r"D:\SHP\PyLAS\PG2.las"
h = header.Header()
h.data_format_id = 1
h.minor_version = 2

LASinr = file.File(LASin, mode="r")
a = 0
LASoutw = file.File(LASout, mode="w", header=h)
new = liblas.point.Point()
for point in LASinr:
classy = point.classification
if classy == 2:
new.x = point.x
new.y = point.y
new.z = point.z
new.intensity = point.intensity
new.return_number = point.return_number
new.number_of_returns = point.number_of_returns
new.scan_direction = point.scan_direction
new.flightline_edge = point.flightline_edge
new.classification = point.classification
new.scan_angle = point.scan_angle
new.user_data = point.user_data
cr = point.color
rr = cr.red
bb = cr.blue
gg = cr.green
new.color = color.Color(red = rr, blue = bb, green = gg)
LASoutw.write(new)
a += 1
LASoutw.close()

libLAS-1.8.0/src/gt_citation.cpp:158:19: warning: ordered comparison of pointer with integer zero [-Wextra]

Source code is

while( p2>0 && (p2[0] == ' ' || p2[0] == '\0' || p2[0] == '\n') )

Also,

libLAS-1.8.0/src/gt_citation.cpp:201:19: warning: ordered comparison of pointer with integer zero [-Wextra]

while( p2>0 && (p2[0] == ' ' || p2[0] == '\0' || p2[0] == '\n') )

When I try to set -maxx It get the error message: error: boost::bad_any_cast.

I checked the source code and I found a bug in laskernel.cpp. The line 541 is:

if (vm.count("maxx")) 

and should be:

if (vm.count("maxy")) 

Hi there.

I am using LibLAS in C++ to read in .las files for further analysis. Unfortunately, when I try to obtain the point coordinates, the outputs are in integers. I really need the output to have greater precision than this.

An example of the code is:

vector x_coordinates;
vector y_coordinates;
vector z_coordinates;

while (reader.ReadNextPoint())
{
liblas::Point const& p = reader.GetPoint();
x_coordinates.push_back( p.GetX() );
y_coordinates.push_back( p.GetY() );
z_coordinates.push_back( p.GetZ() );
}

If someone could tell me why this is returning integers/how to read in points differently, so that the coordinates have double precision rather than integer, then that would be greatly appreciated.

Many thanks!

Latest liblas compiles well with laszip 2.1, but not with laszip 2.2. The latter installs headers in include/, while liblas looks for them in include/laszip. Perhaps I am not dong something right. Thanks.