#2472: v.in.lidar gives negative point count on large las files
-----------------------+---------------------------------------------
Reporter: dnewcomb | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Resolution: | Keywords: v.in.lidar point initial count
CPU: x86-64 | Platform: Unspecified
-----------------------+---------------------------------------------
Comment (by wenzeslaus):
There was one more issue with the formatting, two cases of `unsigned long`
were still formatted as `%d` instead of `%lu`. Fixed in r66344. (There
rest was already `%lu` and `%llu` accordingly.)
The info messages and percentage counts might be still wrong with large
number of points as it is using what is obtained as point count from
[http://www.liblas.org/ libLAS]. This is the limitation of the library. It
uses `uint32_t` in `LASHeader_GetPointRecordsCount` according to
[https://github.com/libLAS/libLAS/blob/master/src/c_api.cpp#L1383 source
code on GitHub] and `unsigned int` according to the
[http://www.liblas.org/doxygen/liblas_8h.html#ab595c92aa03146db561376ff9d2e2bd3
documentation]. I made some changes to improve the situation and warn
about the possible problem in r66345. The changes assume that libLAS will
actually read the points correctly anyway and that the LAS format actually
supports more than "4,294,967,296 - 1" points (32 bit unsigned integer). I
did a quick look to libLAS but I made no conclusion.
Also, thanks to r66344 ''v.in.lidar'' now catches the case when we it runs
out of categories as these are limited by `GV_CAT_MAX` (2,147,483,647) in
[source:grass/trunk/include/vect/dig_defines.h dig_defines.h]:
{{{
#define PORT_INT_MAX 2147483647
#define GV_CAT_MAX PORT_INT_MAX
}}}
Moreover, thanks to r66343 one can use return or class number as category
value or not to use categories at all.
I wonder why the limit there is so low (for example, why not at least
unsigned?), but on the other hand, it is an issue mainly for the point
clouds where we are not interested in numbering individual features (using
category as an ID) anyway.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2472#comment:5>
GRASS GIS <https://grass.osgeo.org>