[GRASS-dev] [GRASS GIS] #2472: v.in.lidar gives negative point count on large las files

[GRASS GIS]

#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>