[GRASS-dev] [GRASS GIS] #3198: r.stats.quantile: hardcoded max number of categries in base map
GRASS GIS
trac at osgeo.org
Tue Nov 8 05:36:33 PST 2016
#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>
More information about the grass-dev
mailing list