[GRASS-dev] [GRASS GIS] #3084: i.segment: allow more than 2147483647 cells (was: i.segment: notnullcells defined as long too limited)

[GRASS GIS]

#3084: i.segment: allow more than 2147483647 cells
--------------------------+-------------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.2.0
 Component:  Imagery      |    Version:  unspecified
Resolution:               |   Keywords:  i.segment variable type
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------------------
Changes (by mlennert):

 * milestone:  7.0.5 => 7.2.0
 * type:  defect => enhancement


Comment:

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:3084 mlennert]:
 > > In iseg.h, notnullcells is defined as long. On Windows this has a
 range of –2147483648 through 2147483647.
 > >
 > > We are working on a region that has over 7 billion pixels and so the
 nonnullcells variable overflows, becomes negative and i.segment fails with
 "insufficient number of non-null cells".
 > >
 > > Two reflections:
 > > * Shouldn't this be unsigned ?
 > > * Maybe a long long would be safer, seeing that pixel numbers don't
 stop increasing.
 >
 > For nonnullcells, long long would be ok. But i.segment is not prepared
 to handle raster maps with more than 2147483647 cells, at least the region
 IDs would also need to be changed, or handled differently. Variables for
 region ID as well as the region ID output is 32 bit signed integer, so
 there will be another integer overflow, particularly because in the
 beginning each cell gets a unique region ID.

 Ok, so I'll retype the ticket to enhancement request and change the title
 to reflect the demand for i.segment to handle over 2147483647 cells. Other
 than changing variable types, does this entail any other changes ?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3084#comment:2>
GRASS GIS <https://grass.osgeo.org>