Lidar LAS files of version 1.4 crash ParaView 5.7.0

LidarView, Lidar, and SLAM
1

I have some LAS Lidar point cloud files that are of version 1.4 of the LAS format that cause ParaView to crash. For the moment I have the ability to down-covert these files to version 1.3 (or 1.2) of the file format, and ParaView handles these. So I’m just reporting this as a bug because ParaView should do something other than crashing when encountering these files. Ideally it should handle the newer format, but at the very least just report that the format isn’t handled and use an earlier LAS format in the console window.

This is tested on Linux, MS-Windows and MacOS.

Here’s the relevant part of the crash output when running on Linux:
% paraview
[load 1.4 LAS file]
terminate called after throwing an instance of ‘std::out_of_range’
what(): version minor out of range

Loguru caught a signal: SIGABRT
Stack trace:
62            0x40772d paraview() [0x40772d]

the “version minor out of range” message probably comes from the LAStools, or whatever LAS library is being used.

 Bill
2

Could you share a 1.4 and a 1.3 file please ?

3

Yes, here are two versions of a smallish Lidar PointCloud.
Bill
pt000025_v13.las (699.8 KB) pt000025_v14.las (741.1 KB)

4

@utkarsh.ayachit @danlipsa We should check if these files still crash 5.8.0.

5

pt000025_v13.las loads with 5.8, but pt000025_v14.las crashes as follows:

.....
10      0x7f2be42a3a5a vtkLASReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 586
9       0x7f2bd32b5062 liblas::ReaderFactory::CreateWithStream(std::istream&) + 98
8       0x7f2bd3308d31 liblas::detail::reader::Header::ReadHeader() + 545
7       0x7f2bd32c0f7d liblas::Header::SetVersionMinor(unsigned char) + 109
6       0x7f2bf7dc2d54 /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92d54) [0x7f2bf7dc2d54]
....
2       0x7f2c021ba801 abort + 321                                                  
1       0x7f2c021b8e97 gsignal + 199                                                                                                          
0       0x7f2c021b8f20 /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f2c021b8f20]                                 
(  14.861s) [paraview        ]                       :0     FATL| Signal: SIGABRT

Issue reported here

6

William,
Another possibility to read your las files is to compile ParaView with PDAL support. I believe liblas (which is used in our reader) is not maintained anymore. Unfortunately PDAL support is not yet built into the ParaView binary.

Dan

7

It doesn’t seem dead quite yet (last commit was merging a PR of mine in November). But yes, development activity is very low.

8

Interesting background on libLAS, LAStools and PDAL here, the first two answers.

https://gis.stackexchange.com/questions/306418/difference-between-lastools-liblas-and-pdal

Summary:

libLAS was modeled after LAStools which was closed source at the time when libLAS was created. Then, the maintainer moved on and created PDAL.

libLAS does not support version 1.4

1 Like
9

Hey everyone,

Thanks for checking back on this issue. And yes, the base issue is that ParaView is built with liblas, which doesn’t handle LAS v1.4, and does not-handle-it very ungracefully.
I would still hope however that ParaView wouldn’t crash when attempting to load LAS v1.4 files. I would still consider that a bug for ParaView.
I haven’t looked much at PDAL, so I don’t know whether ParaView could just use it as a drop-in replacement.

BTW, the two solutions I’ve tried are:

  1. Use LAStools to convert .las files from version 1.4 to version 1.3

  2. Use LAStools to convert .las files into ASCII format and then pipe the output through a script that makes legacy VTK files from it.

(I’ve since been playing with the eVTK Python library, so that might be another solution, but would also include converting files to ASCII first.)

Bill
10

VTK/ParaView have PDAL support, but we don’t add it to our binary packages. @utkarsh.ayachit