[GRASS-dev] [GRASS GIS] #3198: r.stats.quantile: hardcoded max number of categries in base map

[GRASS GIS]

#3198: r.stats.quantile: hardcoded max number of categries in base map
--------------------------+---------------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.2.1
 Component:  Raster       |    Version:  unspecified
Resolution:               |   Keywords:  r.stats.quantile MAX_CATS
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+---------------------------------------

Comment (by mmetz):

 Replying to [comment:2 mlennert]:
 > Replying to [comment:1 glynn]:
 > > [...]
 > >
 > > There's no fundamental reason why the limit can't be raised; or even
 abolished, if you don't mind an unsuitable choice of base map resulting in
 "unable to allocate" errors, or just taking forever.
 >
 > A warning was maintained. At least the user is made aware and can stop
 the module.

 FWIW, I tested with more than a million categories in the base map and the
 module finished within 19 seconds (on an old laptop).
 >
 > > Consider putting a limit on num_cats*num_slots; a map with many
 categories should presumably require fewer bins (assuming that the data
 isn't concentrated into a handful of categories).
 >
 > In r69776 MarkusM introduce dynamic bins, although I don't really
 understand what this means ;-).

 For example, if there are only 10 cells for a given basemap category, it
 does not make sense to allocate 1000 bins for that category, instead a
 single bin is sufficient. With many basemap categories and only few values
 for each category, memory consumption can be reduced by 90% down to 10% of
 the previous version of r.stats.quantile. Still, with many basemap
 categories and many cells per category, the module will be slow and will
 need a lot of memory.

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