I am trying to look into the tiling that is written in the readme section, but the files that are related are missing. It also failed to compile several of the "projects".

Hello,

LASlib is only available inside the LAStools package: will it be, at some point, available separately with a full installation mechanism?

So far the Makefile for LASlib only provides make, not make install and as far as I can see in the examples, the library is included/linked with hard coded gcc arguments/paths. It would be interesting to provide, for example, a laslib-config.cmake the same way liblas does.

Are there any plans for this kind of feature?

Running a simple las2las on Mac OS with --split-mb 15 fails with:

cannot understand argument '--split-mb'

On Linux, I installed using apt and it works.
On MacOS, I just ran make

I want to create a vcpkg package for LASlib. This requires a stable method to obtain a specific version of the library. Just a simple tag that represents the current state would be enough.

Using the precompiled las2las.exe, I'm getting nonsense intensity errors. When I recompile with mingw, the errors go away.
(I've reported this on the google forum but had no response)

.pts file looks like this with intensities in range -2048..2047

181204304
11661.296646 70527.929642 9.934738 -640
11661.184311 70527.957626 9.873734 -366
11661.173080 70527.958023 9.862625 -314
....

Batch file is this
las2las -i ../pts/westmid.pts ^
-v ^
-iparse xyzi ^
-ipts ^
-rescale 0.0001 0.0001 0.0001 ^
-olaz ^
-odir .

Error messages see https://s18.postimg.org/l22muizy1/las2las_errors.png
eg
WARNING: intensity 5.93139e+007 is out of range of unsigned short
WARNING: intensity 9.55139e+007 is out of range of unsigned short
WARNING: intensity 1.19514e+008 is out of range of unsigned short
WARNING: intensity -7.60098e+007 is out of range of unsigned short
WARNING: intensity 3.31139e+007 is out of range of unsigned short
.........
In file of 180 miillion points, 29 errors.
In file of 600 million, many more, I gave up and recompiled.
I don't have microsoft compilers, I used msys2/mingw64 and added -static -static-libgcc -static-libstdc++ to the linker options in the Makefile.
I'm on Windows 10.

I have used the LASlib library in my read and write routines. Now I had a data that I could not open. LAStools and PulseWaves opened it nicely. My reader gave library error that file signature is not LASF, it is. I can read the file with my older reader that is not using the LASlib library. The error comes in both windows and linux versions of my Matlab reader, both use 64 bit compilations of LASlib.

Joep Lijnen [email protected] wrote me the following a while ago:

For a C++ based project which processes some LAS point-clouds, which I am working on, we are using GIT as version control.

While there are several ways of adding in external code in GIT, one method often chosen is to create a submodule; that is to say, you can specify to GIT that it should download some other repository to a sub folder.
The benefit of this technique is that you can then create a dependency to a specific version of another GIT repository, for example as done here: https://github.com/openMVG/openMVG/tree/master/src/dependencies.

Ideally, I would like to have done this with LASlib and LASzip; so that I can refer to existing source code of a specific version, and perform a controlled upgrade to a new version. Unfortunately, the size of the LAStools repository simply makes this unfeasible; I just checked and downloading the GIT repository currently takes 472.51 MiB of network traffic and consumes 594 MB of disk space. (This will get worse in the future with updates to the binaries) This size - and the time taken to resolve deltas after download - are mostly caused by the presence of the Windows binaries.

From my understanding, the only way to overcome this is to use a downloaded version of the LASLib and LASzip, which I would then have add to GIT manually. I currently use these commands to download (the latest) version of only the files from GIT I require:
svn export https://github.com/LAStools/LAStools/trunk/LASlib/src LASLib/LASLib/src
svn export https://github.com/LAStools/LAStools/trunk/LASlib/inc LASLib/LASLib/inc
svn export https://github.com/LAStools/LAStools/trunk/LASzip/src LASLib/LASzip/src

This means that, despite LAStools having a maintained GIT repository I will still be missing out on the following traceability benefits a submodule would have had: There is no explicitly automated / documented link the specific version (commit) of LAStools was downloaded and added in the source (instead this will have to be manual, and documentation tends to get out of date, since people forget things) It will not be possible to quickly look at the history of files under my repo belonging to LASlib/LASzip, which bug fixes are present, or to determine quickly and unambiguously whether you are looking at the up-to-date version. It will be harder for someone in the future to decide whether or not to update to a newer version of LASlib/LASzip, more work is required to determine what the pro/cons of such a choice.

Additionally, other users running into this are less likely to make a submodule, so the GIT repository for LAStools is probably getting less links on the internet.

To overcome these problems, I would suggest creating a 'separate' GIT repository which contains only the LASzip and LASLib folders from LAStools; this would be ideal for my case.
This is potentially not too difficult if a complete clone is made of LAStools, placed into GitHub as a separate repository with the binaries surgically removed from its history using this technique from GitHub. (Of course, the original GIT repository should be left intact, rewriting history is a terrible practice if people have already cloned a repository, it is likely to cause complications... However, if left intact, it does mean that sources should be updated on separate locations..)

This would certainly make it quicker, more reliable, and/or easier for people to use LASlib in their GIT repositories.

Kind Regards,

Joep Lijnen

ITC Developer
Department of Earth Observation Science (ITC-EOS)

I downloaded the lastools-master and the laszip_api.c and laszip_api.h are both in LASzip/dll folder

Cannot open include file: 'laszip/laszip_api.h': No such file or directory

I want to compile LAStools. Tried it on two different platforms that worked before (OS X 10.11 and Ubuntu 14.04), but now both fail with a similar error(OS X uses clang and Ubuntu gcc):

OS X:

g++  -O3 -Wall lasexample.o -llas -o lasexample  -L../lib -I/usr/include -I../../LASzip/src -I../inc
Undefined symbols for architecture x86_64:
  "LASreadOpener::open(char const*)", referenced from:
      LASindex::append(char const*) const in liblas.a(lasindex.o)
     (maybe you meant: __ZN13LASreadOpener4openEPKcb)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Linux:

g++  -O3 -Wall -Wno-deprecated -DNDEBUG  laszip.o geoprojectionconverter.o -llas -o laszip  -L../LASlib/lib  -I../LASzip/src -I../LASlib/inc 
../LASlib/lib/liblas.a(lasindex.o): In function `LASindex::append(char const*) const':
lasindex.cpp:(.text+0xaf8): undefined reference to `LASreadOpener::open(char const*)'
../LASlib/lib/liblas.a(lasreadermerged.o): In function `LASreaderMerged::open()':
lasreadermerged.cpp:(.text+0x2ec5): undefined reference to `LASreaderLASrescale::LASreaderLASrescale(double, double, double)'
../LASlib/lib/liblas.a(lasreaderbuffered.o): In function `LASreaderBuffered::open()':
lasreaderbuffered.cpp:(.text+0x111e): undefined reference to `LASreadOpener::open(char const*)'
lasreaderbuffered.cpp:(.text+0x2272): undefined reference to `LASreadOpener::open(char const*)'
collect2: error: ld returned 1 exit status

I'm having problems compiling the library:

1>..\laszip_dll.cpp(4391): error C2660: 'LASindex::seek_next' : function does not take 2 arguments
I downloaded yesterday and checked the line in this master:
4931 while (laszip_dll->lax_index->seek_next(laszip_dll->reader, laszip_dll->p_count))

how to fix this?

Hi,

I am having a problem when reading the .las files to calculate the grid_metrics. It says that "WARNING: for LAS 1.3 header_size should at least be 235 but it is only 227". How can I solve it, your help will be highly appreciated.

Thanks and Regards,
Yogendra

Hello all,

Did anyone try to upgrade VC++6.0 projects to Visual Studio 2015? I tried to do it and am getting errors and it failed to upgrade projects. Please let me if any one has done this before successfully.

Thanks,
Suresh

In https://github.com/LAStools/LAStools/blob/master/src/las2las.cpp#L792 there is:

if (set_ogc_wkt) // maybe also set the OCG WKT 
{
    ....
} else if (set_ogc_wkt) // maybe only set the OCG WKT 
{
   **** this part will never execute ******
   ....
}

I'm not sure what the intent here was but the part in else if (set_ogc_wkt) branch will never execute.

If set_ogc_wkt is true, then one the first if () branch will execute. If it's false, then neither will execute.

/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: //usr/local/lib/liblas.a(laszip.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC

Hi,

Is there any tool or platform available which directly converts the rosbag pointcloud2 message into las file ?

Thanks

I've installed QGIS_2_14_1_toolbox as indicated, renaming
/usr/share/qgis/python/plugins/processing/algs/lidar/
to
/usr/share/qgis/python/plugins/processing/algs/lidar_orig
and copying the contents of zip files provided here to this renamed location.

However, QGIS initialization raised and error loading modules. So I renamed the folder back to its original name, so QGIS initialized normally. I've activated "Tools for LiDAR Data" in the processing>providers menu and indicated the locations of LASTools folder.

Then I've opened laszip tool in Processing Toolbox but and error message appeared in the log:
"LAStools console output
/bin/sh: /usr/share/qgis/python/plugins/processing/algs/lidar/lastools/bin/laszip: No such file or directory".

I know I've adapted the installation instructions to fit my Ubuntu systems since the installation instructions are given for Windows.
How could I successfully install Lastools for qgis?

Ubuntu 16.04
QGIS version 2.18.9

Compile error with Ubuntu 14.04 LTS g++ version 4.8.4:
lasreader_las.cpp:1466:35: error: ‘fabs’ was not declared in this scope
if (fabs(temp - header.min_x) > header.x_scale_factor)

Cause, starting at line 39:
`#ifdef _WIN32

include <fcntl.h>

include <io.h>

include <math.h>

endif

Fix:#include <math.h>`
needs to be outside #ifdef _WIN32 block.

Hi,

I'm currently packaging LASlib and LASzip up in an RPM and installing them on my system so that I can write out .laz files from my application. If I use UTM systems, this works great, as those are hard-coded into the coordinate conversion code. However, I'm trying to write the point clouds out in spherical mercator coordinates, which require a lookup to the pcs.csv file. Where should I be putting this file so that it can be found by the library? Would it be possible to make this a build-time configuration parameter? It would be awesome if I could just dump it in /usr/share/LAStools, where I'm also dumping some CMake config that I generated for the library.

Thanks,
Phil

LASlib uses a custom Makefile that does not compile with position independent code. It thus cannot be linked to shared libraries.

In order to change this the Makefile needs to be hand edited to add fPIC (which makes for maintenance problems to do that locally if there is some change here that would break it) as the Makefile does not allow the passing of user options through CFLAGS and CXXFLAGS.

This could be fixed by including these environmental variables to allow custom rolling. BITS is currently the only variable that is accessible and not clobbered. There would also be benefit to using ?= rather than = so the user can redefine COMPILER, AR, or COPTS

Hello! Normally I write all LAZ 1.4 files using the version-3 compressor, but I currently have a client that doesn't yet support the native 1.4 compression.

When I attempt to write my LAZ 1.4 file (PDRF=6) with compatibility mode enabled, the point record size never gets updated. laszip_open_writer() used to do this, but it doesn't seem to do so any more.

The point record size of my file should be 33 (28+5), but it's still 30 when written.

It seems that the number of "compatibility" extrabytes gets computed correctly around here...

https://github.com/LAStools/LAStools/blob/master/LASzip/src/laszip.cpp#L505

...and it seems to be used for the actual point record compression, but at no point does the header object get updated. Previous versions of LASzip would modify the header to set the version to LAS 1.2 and the point record size to 33.

Is this user error or a bug?

I'm running version 180617 if that matters.

I am trying to export the value of "raw_classification" from a las file to a CSV file. There is an option "c" for "-parse" to export the classification but in my las files, there is a filed "raw_classification" that has a different value. Any suggestions on how to get to the "raw_classification" values?

Hi everyone , from this repo i could not find the src_full directory while compiling laszip, So, any help? thanks

The readme claims that the Makefiles should work for Mac builds; however, the -soname flag is incorrect for creating dynamic libraries on OS X.

The paper, "LASzip: lossless compression of LiDAR data", says as follows:

the median of the five immediately preceding differences of points with the same return map m

(with the same current_context and m << 1 | gps_time_change in v3).

However, I think SM5 behaves differently from the description.

An example of changes of SM5's values is listed below.

0,0,0,0,0
0,0,0,0,25
0,0,0,22,25
0,0,22,22,25
-63,0,22,22,25
-63,-18,0,22,22
-63,-19,-18,0,22
-63,-19,-19,-18,0

According to the doc. , the sixth line should be [-63, -18, 22, 22, 25],
but actually is [-63, -18, 0, 22, 22]. 25 has been popped and 0 is still in the buffer.
This means SM5 doesn't hold the five immediately preceding differences.

I may be misunderstanding, but is this intended behavior ?

Using the command:
e572las -v -i "D:\Working\Fla\2.e57" -o Split.las -split_scans

I get repeats of this:
processing scan 1 of 33 ...
contains grid of 4895 by 2448 equaling 11982960 points
has quaternion (0.68435,-0.00868469,-0.00205505,0.729099) which is applied
has translation (2001.24,1003.56,102.434) which is applied
no x coordinates for scan 0. skipping ...

I have viewed the file in other softwares fine. Any ideas? maybe it a not combatible version of e57?

Hello,

I've been happily using your noise removal tool, but found that while RGB color is preserved in the output, Intensity values are removed. I've been going over the readme and don't see anything related to this, is there an argument required keep the Intensity?

Here's the command I've been using:
lasnoise64 -v -i Maeshowe.las -remove_noise -step 0.1

The file processed with cloudcompare's noise filter (preserves intensity)
https://pointcloud.ucsd.edu/Maeshowe.html

Processed with lasnoise64 (Intensity field is gone), I've checked to make sure the scalar wasn't just renamed, it's totally gone.
https://pointcloud.ucsd.edu/Maeshowe_lasnoise.html

Currently, when building with CMake in Linux, all tools names are appended with a 64 suffix, e.g., las2las64. Is this on purpose? Wouldn't be better to drop that suffix in the tools names?
The following change works for me:

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 7dd4c2e..98f7df5 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -32,6 +32,5 @@ endforeach(TARGET)
 foreach(TARGET ${ALL_TARGETS})
        target_link_libraries(${TARGET} LASlib)
        set_target_properties(${TARGET} PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/../bin64)
-       set_target_properties(${TARGET} PROPERTIES OUTPUT_NAME ${TARGET}64)
        install(TARGETS ${TARGET} RUNTIME DESTINATION bin)
 endforeach(TARGET)

When using lasinfo with argument -cd, the wording about the unit used is misleading.
Indeed, it seems that when the horizontal unit is unknown, the density is said to be in points per square unit. (This line in the code: https://github.com/LAStools/LAStools/blob/master/src/lasinfo.cpp#L4078)

Square unit is actually a unit that is defined as 100 square feet (as defined here: https://en.wikipedia.org/wiki/Square_(unit)).

Could you confirm that the square unit displayed in lasinfo does not correspond to the official square unit definition? Also, maybe a rewording could be done to avoid confusion.

Study case:
Input: A .laz file with elevation in feet.
My goal: Transforming the elevation to meters.

What I do:

I use the following command: las2las -i <my_original_file> -o <my_output_file> -elevation_feet -target_elevation_meter which from the documentation I understand as meaning: "I know that the elevation of the input file is in feet and I want it to be in meters". However, the output file has the exact same z values as the initial file. This might be a bug, in any case it would at least deserve a warning to the user when the elevation values remain unchanged

It seems to me that a workaround is to use -scale_z 0.3048.

The file I testes with is located at: ftp://rockyftp.cr.usgs.gov/vdelivery/Datasets/Staged/NED/LPC/Projects/FL_CharlotteCounty_2007/laz/
and named FL_CharlotteCounty_2007_000006.laz

Currently there is Definition which is your minimum compiler requirement to compile this project or which compiler are supported. Because I currently have a lot of trouble with compiling this project I would help you a bit to modernize a few things so it is compiling with even with modern compiler. But for this I need information which compiler should be all supported.

The only thing I know is that you are still using Visual Studio 6. But which minimum version of e.g., gcc you are supporting? Or doesn't this matter as long VS6 is working? In this case I would define C++98 as used language and compile it with clang & gcc to test if all is still compiling.

The file I'm using: https://coast.noaa.gov/htdata/lidar1_z/geoid12a/data/1434/20121114_ct40.laz

The code is latest from git, compiled on mac by running make.

When I run without -stdin option, everything works:

$ ./bin/lasinfo /Volumes/hd/data/lidar/source/noaa/noaa_1434/geoid12a/data/1434/20121114_ct40.laz
lasinfo (170313) report for /Volumes/hd/data/lidar/source/noaa/noaa_1434/geoid12a/data/1434/20121114_ct40.laz
reporting all LAS header entries:
  file signature:             'LASF'
  file source ID:             161
  global_encoding:            0
  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000
  version major.minor:        1.2
  system identifier:          'ALS60'
  generating software:        'Fugro Horizons LAS Lib v1.14'
  file creation day/year:     348/2012
  header size:                227
  offset to point data:       713
  number var. length records: 5
  point data format:          1
  point data record length:   28
  number of point records:    2608
  number of points by return: 2302 218 79 9 0
  scale factor x y z:         0.000000099999966 0.0000001 0.001
  offset x y z:               0 0 0
  min x y z:                  -73.380750787446232 41.0891644 -1.268
  max x y z:                  -73.380201487634963 41.0898975 25.251
variable length header record 1 of 5:
  reserved             43707
  user ID              'NIIRS10'
  record ID            4
  length after header  10
  description          'NIIRS10 Timestamp'
variable length header record 2 of 5:
  reserved             43707
  user ID              'NIIRS10'
  record ID            1
  length after header  26
  description          'NIIRS10 Tile Index'
variable length header record 3 of 5:
  reserved             43707
  user ID              'FugroHorizons'
  record ID            0
  length after header  128
  description          'FHZNInfo'
variable length header record 4 of 5:
  reserved             43707
  user ID              'NOAA_CSC'
  record ID            129
  length after header  2
  description          'Sort Order'
variable length header record 5 of 5:
  reserved             43707
  user ID              'LASF_Projection'
  record ID            34735
  length after header  48
  description          'Projection Parameters'
    GeoKeyDirectoryTag version 1.1.0 number of keys 5
      key 1024 tiff_tag_location 0 count 1 value_offset 2 - GTModelTypeGeoKey: ModelTypeGeographic
      key 2048 tiff_tag_location 0 count 1 value_offset 4269 - GeographicTypeGeoKey: GCS_NAD83
      key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree
      key 4096 tiff_tag_location 0 count 1 value_offset 5103 - VerticalCSTypeGeoKey: VertCS_North_American_Vertical_Datum_1988
      key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
the header is followed by 2 user-defined bytes
LASzip compression (version 2.1r0 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
  X          -733807760 -733802267
  Y           410891644  410898975
  Z               -1268      25251
  intensity           0         79
  return_number       1          4
  number_of_returns   1          4
  edge_of_flight_line 0          0
  scan_direction_flag 0          1
  classification      1          8
  scan_angle_rank     1          3
  user_data         204        210
  point_source_ID    38         38
  gps_time 37011731.478286 37011732.577899
WARNING: range violates GPS week time specified by global encoding bit 0
number of first returns:        2302
number of intermediate returns: 87
number of last returns:         2304
number of single returns:       2085
overview over number of returns of given pulse: 2085 278 213 32 0 0 0
histogram of classification of points:
             563  unclassified (1)
            1720  ground (2)
             325  keypoint (8)

When I use -stdin option on the same file, it crashes:

$ ./bin/lasinfo -stdin </Volumes/hd/data/lidar/source/noaa/noaa_1434/geoid12a/data/1434/20121114_ct40.laz
lasinfo (170313) report for piped input
reporting all LAS header entries:
  file signature:             'LASF'
  file source ID:             161
  global_encoding:            0
  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000
  version major.minor:        1.2
  system identifier:          'ALS60'
  generating software:        'Fugro Horizons LAS Lib v1.14'
  file creation day/year:     348/2012
  header size:                227
  offset to point data:       713
  number var. length records: 5
  point data format:          1
  point data record length:   28
  number of point records:    2608
  number of points by return: 2302 218 79 9 0
  scale factor x y z:         0.000000099999966 0.0000001 0.001
  offset x y z:               0 0 0
  min x y z:                  -73.380750787446232 41.0891644 -1.268
  max x y z:                  -73.380201487634963 41.0898975 25.251
variable length header record 1 of 5:
  reserved             43707
  user ID              'NIIRS10'
  record ID            4
  length after header  10
  description          'NIIRS10 Timestamp'
variable length header record 2 of 5:
  reserved             43707
  user ID              'NIIRS10'
  record ID            1
  length after header  26
  description          'NIIRS10 Tile Index'
variable length header record 3 of 5:
  reserved             43707
  user ID              'FugroHorizons'
  record ID            0
  length after header  128
  description          'FHZNInfo'
variable length header record 4 of 5:
  reserved             43707
  user ID              'NOAA_CSC'
  record ID            129
  length after header  2
  description          'Sort Order'
variable length header record 5 of 5:
  reserved             43707
  user ID              'LASF_Projection'
  record ID            34735
  length after header  48
  description          'Projection Parameters'
    GeoKeyDirectoryTag version 1.1.0 number of keys 5
      key 1024 tiff_tag_location 0 count 1 value_offset 2 - GTModelTypeGeoKey: ModelTypeGeographic
      key 2048 tiff_tag_location 0 count 1 value_offset 4269 - GeographicTypeGeoKey: GCS_NAD83
      key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree
      key 4096 tiff_tag_location 0 count 1 value_offset 5103 - VerticalCSTypeGeoKey: VertCS_North_American_Vertical_Datum_1988
      key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
the header is followed by 2 user-defined bytes
LASzip compression (version 2.1r0 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
Segmentation fault: 11

Are the e572las source codes avaiable online? If yes could you send me link?

In lasreaditemcompressed_v3.cpp you defined LASpoint14. There is another definition of LASpoint14 in laswriteitemcompressed_v3.cpp that is slightly different. The same in v4.cpp. This violate the one definition rule of C++. See this post for more details on possible consequences.

I cannot fix it because I don't know if it is an error in the struct definition or an error in the choice of names. I think you missed in the two reader files these attributes.

  U8 legacy_synthetic_flag : 1;
  U8 legacy_keypoint_flag  : 1;
  U8 legacy_withheld_flag  : 1;

If the differences were intentional, then the two definitions should not share the same name.

Best

In the file laszip.cpp is a #define:

#if defined(_MSC_VER) && (_MSC_FULL_VER >= 150000000)
#define CopyString _strdup
#else
#define CopyString strdup
#endif

@rapidlasso What about putting that in a more central header and replacing the strdup all over the place? I could do that if you agree. It could also be called LASstrdup.

Doing that would avoid lots of warnings for VC++.

https://github.com/LAStools/LAStools/blob/master/LASlib/src/fopen_compressed.cpp#L331 uses strstr to look at filenames when trying to determine if they are compressed data. This also triggers if uncompressed files are stored in a directory with e.g. ".zip" in its name.

You can test like:

mkdir /tmp/test.zip
touch /tmp/test.zip/foo.xyz
txt2las -i /tmp/test.zip/foo.xyz ...

I have no idea about C++ but I guess strstr matches anywhere in the string. The solution would be to make it match only at the end, à la ".zip$" if it was a regular expression.

When writing extra bytes laslib have a memory error (no error writing regular data). This might be reproduced with your example file running it with valgrind

valgrind --tool=memcheck --leak-check=full ./lasexample_write_only_with_extra_bytes test.las

This is the report I get. I guess the error comes either from laswriter_las.cpp:74 or laswriter_las.cpp:920

==15274== Memcheck, a memory error detector
==15274== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15274== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==15274== Command: ./lasexample_write_only_with_extra_bytes test.las
==15274== 
==15274== Syscall param write(buf) points to uninitialised byte(s)
==15274==    at 0x54D52C0: __write_nocancel (syscall-template.S:84)
==15274==    by 0x5456BFE: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1263)
==15274==    by 0x5458408: new_do_write (fileops.c:518)
==15274==    by 0x5458408: _IO_do_write@@GLIBC_2.2.5 (fileops.c:494)
==15274==    by 0x54591CE: _IO_switch_to_get_mode (genops.c:177)
==15274==    by 0x5456509: _IO_file_seekoff@@GLIBC_2.2.5 (fileops.c:1012)
==15274==    by 0x5454E68: fseeko (fseeko.c:36)
==15274==    by 0x41447E: ByteStreamOutFile::seek(long long) (in /home/jr/Téléchargements/LAStools/LASlib/example/lasexample_write_only_with_extra_bytes)
==15274==    by 0x40A154: LASwriterLAS::update_header(LASheader const*, bool, bool) (in /home/jr/Téléchargements/LAStools/LASlib/example/lasexample_write_only_with_extra_bytes)
==15274==    by 0x401D3C: main (in /home/jr/Téléchargements/LAStools/LASlib/example/lasexample_write_only_with_extra_bytes)
==15274==  Address 0x5ac3918 is 280 bytes inside a block of size 4,096 alloc'd
==15274==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15274==    by 0x544B1D4: _IO_file_doallocate (filedoalloc.c:127)
==15274==    by 0x544DFFA: setvbuf (iosetvbuf.c:60)
==15274==    by 0x411C3B: LASwriterLAS::open(char const*, LASheader const*, unsigned int, int, int, int) (in /home/jr/Téléchargements/LAStools/LASlib/example/lasexample_write_only_with_extra_bytes)
==15274==    by 0x407473: LASwriteOpener::open(LASheader const*) (in /home/jr/Téléchargements/LAStools/LASlib/example/lasexample_write_only_with_extra_bytes)
==15274==    by 0x401AB8: main (in /home/jr/Téléchargements/LAStools/LASlib/example/lasexample_write_only_with_extra_bytes)
==15274== 
==15274== 
==15274== HEAP SUMMARY:
==15274==     in use at exit: 72,704 bytes in 1 blocks
==15274==   total heap usage: 25 allocs, 24 frees, 79,041 bytes allocated
==15274== 
==15274== LEAK SUMMARY:
==15274==    definitely lost: 0 bytes in 0 blocks
==15274==    indirectly lost: 0 bytes in 0 blocks
==15274==      possibly lost: 0 bytes in 0 blocks
==15274==    still reachable: 72,704 bytes in 1 blocks
==15274==         suppressed: 0 bytes in 0 blocks
==15274== Reachable blocks (those to which a pointer was found) are not shown.
==15274== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==15274== 
==15274== For counts of detected and suppressed errors, rerun with: -v
==15274== Use --track-origins=yes to see where uninitialised values come from
==15274== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Both the make and cmake builds fail in the current master with the following error:

[...]
cd example && make
make[2]: Entering directory '/home/me/src/lastools-git/LASlib/example'
g++  -c -O3 -Wall -Wno-strict-aliasing -Wno-unused-result -I/usr/include -I../../LASzip/src -I../inc lasexample.cpp -o lasexample.o
g++  -O3 -Wall -Wno-strict-aliasing -Wno-unused-result lasexample.o -llas -o lasexample  -L../lib -I/usr/include -I../../LASzip/src -I../inc
../lib/liblas.a(lasreader.o): In function `LASreadOpener::parse(int, char**, bool)':
lasreader.cpp:(.text+0x58af): undefined reference to `LASignore::parse(int&, int, char**)'
lasreader.cpp:(.text+0x6091): undefined reference to `LASignore::LASignore()'
lasreader.cpp:(.text+0x63b8): undefined reference to `LASignore::LASignore()'
lasreader.cpp:(.text+0x63c0): undefined reference to `LASignore::usage() const'
lasreader.cpp:(.text+0x63cd): undefined reference to `LASignore::~LASignore()'
lasreader.cpp:(.text+0x6e63): undefined reference to `LASignore::~LASignore()'
lasreader.cpp:(.text+0x785b): undefined reference to `LASignore::~LASignore()'
collect2: error: ld returned 1 exit status
Makefile:19: recipe for target 'lasexample' failed
make[2]: *** [lasexample] Error 1
make[2]: Leaving directory '/home/me/src/lastools-git/LASlib/example'
Makefile:2: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/me/src/lastools-git/LASlib'
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 2

I was able to fix it by including lasignore.o in LASlib/src/Makefile to the OBJ_LAS.

In addition, the signature of a function in header lasignore.hpp is wrong. It reads
BOOL unparse(CHAR* string) const;
but the return type is actually I32.

We have a las file created according to the Topo-Bathy Lidar. This dictates a triple field for sigma_xyz.
I saw discussion on removing this, but haven't seen any updated specification.

You removed support for these fields in on 14-Sep2018.
However, even if I now only want to extract a field after that particular field, its offset is off.

Can we at least in: LASattribute.get_size() return the correct size multiplied with the dimensions?
That way all other fields can be extracted correctly.

matlab.las.base64.txt

When I attempt to compile this on Visual Studio 2013 I get a compile error here:

It appears that you #include <unordered_map> but then typedef using hash_map. Shouldn't this use the unordered_map class? If so, I'll fix this throughout and submit a pull request.

LASpoint::is_zero() checks the first few fields via pointer manipulation to make sure they are all zeroed out.

But LASpoint::zero() doesn't zero out return_number or number_of_returns (both set to 1).

Since is_zero() is not used within LAStools I'm guessing the issue is there and that zero() is correct.

I plan to write a pull request to fix is_zero(), but I'm not sure if return_number and number_of_returns should be checked to see if they are 1, or just unchecked.

I'm using MSVC2017, in case the byte packing is the issue here.

Compiling with gcc v > 6.4 (I tested with 7.2.0) which seems more conservative by default, I got some warnings relative to format-overflow. I not sure how serious this is. Overflow is never a good things in computer science 😉

warning: ‘sprintf’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
warning: ‘ bytes’ directive writing 6 bytes into a region of size between 5 and 18 [-Wformat-overflow=]

Here with the context.

../../LASzip/src/laszip.cpp: In member function ‘bool LASzip::check_items(U16, const LASitem*, U16)’:
../../LASzip/src/laszip.cpp:274:6: warning: ‘ bytes’ directive writing 6 bytes into a region of size between 5 and 18 [-Wformat-overflow=]
 bool LASzip::check_items(const U16 num_items, const LASitem* items, const U16 point_size)

../../LASzip/src/laszip.cpp: In member function ‘bool LASzip::check(U16)’:
../../LASzip/src/laszip.cpp:294:6: warning: ‘ bytes’ directive writing 6 bytes into a region of size between 5 and 18 [-Wformat-overflow=]
 bool LASzip::check(const U16 point_size)

laswriter_las.cpp: In function ‘BOOL LASwriterLAS::open(ByteStreamOut*, const LASheader*, U32, I32, I32)’:
laswriter_las.cpp:126:6: warning: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Wformat-overflow=]

Thanks

I want to grab small subsections of lidar and analyze them,

I have an .las and a .lasx but I assume the lasx is just a lax.

Was looking through other issues, examples, and the code itself, still a little iffy on how to approach reading data. I've been reading entire files and just snagging the ones within my bounding box, but it's drastically slower then I think I can achieve and I need to do this roughly 20k times, so I need to improve the algorithm or it will take weeks as opposed to what I would assume could be just hours.

/build/LAStools/LASzip/src/laszip_dll.cpp: In function 'laszip_I32 laszip_read_point(laszip_POINTER)':
/build/LAStools/LASzip/src/laszip_dll.cpp:4220:91: error: lvalue required as left operand of assignment
((U16)(point->rgb[3])) = ((U16)(point->extra_bytes + laszip_dll->start_NIR_band));

See comment on file in commit 7e7a3f3

Hi,
I'm accessing a PLY file generated with CloudCompare but I get this message as a blocking error. I guess it comes from LASlib, even if I do not imagine to what it might be related.
The point cloud is a 3x3 metres scan derived from photogrammetry with local coordinates, and 0,0 in the centre of the point cloud.
Thank you very much in advance for any hint!

parsed: format binary_little_endian 1.0
parsed: comment Created by CloudCompare v2.11 alpha (Anoia)
parsed: comment Created 30/04/2020 13:47
unknown header item: obj_info Generated by CloudCompare!
not implemented. contact [email protected]
parsed: obj_info Generated by CloudCompare!
parsed: element vertex 161617
parsed: property float x
parsed: property float y
parsed: property float z
parsed: property uchar red
parsed: property uchar green
parsed: property uchar blue
parsed: property float nx
parsed: property float ny
parsed: property float nz
Error in C_reader(ifiles, ofile, select, filter, filter_wkt) : 
  c++ exception (unknown reason)```

Hi!
Is it possible to create a LAZ file without creating a LAS file and converting it?
It is said in the README that it is possible but I didn't find any clue how?

Should I put the flag is_compressed to true in the header and rename the file .laz?

Thanks a lot!
Best regards!

R.S

I'd like to use LAStools to interface to my geospatial display library. My library is open source, so it presents me no real problem, but I know my users won't pay attention to the license of anything I use. I have to pay attention for them.

My question is if you have an L-GPL exemption for static linking on iOS. The dynamic replacement requirement of that license is really impossible to meet on shipping iOS apps.

The variable context is defined here,

BOOL LASwritePoint::write(const U8 * const * point)
{
  U32 i;
  U32 context = 0;

and is set to current_context only if 'scanner channel' has changed from that of the previous encoded point.

if (changed_values & (1 << 6))
{
    U32 diff = dec_channel_returns_XY->decodeSymbol(contexts[current_context].m_scanner_channel); // curr = last + (sym + 1)
    U32 scanner_channel = (current_context + diff + 1) % 4;
    // maybe create and init entropy models and integer compressors
    if (contexts[scanner_channel].unused)
    {
      // create and init entropy models and integer decompressors
      createAndInitModelsAndDecompressors(scanner_channel, contexts[current_context].last_item);
    }
    // switch context to current scanner channel
    current_context = scanner_channel;
    context = current_context; // the POINT14 reader sets context for all other items

    // get last for new context
    last_item = contexts[current_context].last_item;
    ((LASpoint14*)last_item)->scanner_channel = scanner_channel;
}

However, this is neither a static variable nor a global variable, and thus is initialized to zero whenever a point is encoded, which means that, for example, context is still 0 even if current_context of POINT14 and the previous 'scanner channel' are 1.
Because all subsequent layers use context set by POINT14, their current_contexts will be set to this incorrect context (scanner channel).
This is not the same behavior as the past global_current_context, right ?

I tried building the project on my Linux machine (gcc 7.2.0), but it fails when building lasunzipper.
My procedure was as instructed, aka cd LAStools and make.

[...]
make[2]: Entering directory '[...]/LAStools/LASzip/example'
g++  -O3 -Wall -Wno-strict-aliasing laszippertest.o ../src/laszip.o ../src/laszipper.o ../src/lasunzipper.o ../src/lasreadpoint.o ../src/lasreaditemcompressed_v1.o ../src/lasreaditemcompressed_v2.o ../src/lasreaditemcompressed_v3.o ../src/laswritepoint.o  ../src/laswriteitemcompressed_v1.o ../src/laswriteitemcompressed_v2.o ../src/laswriteitemcompressed_v3.o ../src/integercompressor.o ../src/arithmeticdecoder.o ../src/arithmeticencoder.o ../src/arithmeticmodel.o -o laszippertest   -I/usr/include -I../src
../src/lasunzipper.o: In function `LASunzipper::open(_IO_FILE*, LASzip const*)':
lasunzipper.cpp:(.text+0x7c): undefined reference to `LASreadPoint::LASreadPoint()'
../src/lasunzipper.o: In function `LASunzipper::open(std::istream&, LASzip const*)':
lasunzipper.cpp:(.text+0x293): undefined reference to `LASreadPoint::LASreadPoint()'
collect2: error: ld returned 1 exit status

However, these methods are declared in LASzip/src/lasreadpoint.hpp and defined in LASzip/src/lasreadpoint.cpp. Maybe the Makefile is broken?

We can add another function.
After that,we can install it on Linux system with make install, and open the readme file under bin directory with man .