liblas / liblas Goto Github PK
View Code? Open in Web Editor NEWC++ library and programs for reading and writing ASPRS LAS format with LiDAR data
Home Page: http://liblas.org
License: Other
C++ library and programs for reading and writing ASPRS LAS format with LiDAR data
Home Page: http://liblas.org
License: Other
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
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.
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?
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:
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.
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
).
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.
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?
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.
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!
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)
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);
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
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,
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.
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
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?
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:
Unzip code reference:
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
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 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
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
๐.)
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
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,
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.
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 to
boost::system::generic_category()'
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.
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.
Currently I've found that two things prevent easily linking against a libgdal.a
with the new cmake scripts:
libLAS/cmake/modules/FindGDAL.cmake
Lines 247 to 251 in 59709b3
.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.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)
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.
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
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!
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.
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') )
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
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
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
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)
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
LASINFO crashes when used with LAZ files.
System info: Dell Precision T7600, 16GB RAM, Windows 7x64 SP1 Ultimate.
Steps to reproduce:
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.
We should check methods that create streams to make sure they clean up in cases where a file is not found.
There's no git tag for the 1.7.0 release.
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.
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()
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,
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:
#include <liblas/iterator.hpp>
using namespace liblas;
header.Compressed(true);
use
header.SetCompressed(true);
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
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 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
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 declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.