#2625: r.stats's nsteps is not region-sensitive
--------------------------+-----------------------------
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.0.2
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.stats, nsteps
CPU: Unspecified | Platform: Unspecified
--------------------------+-----------------------------
Comment (by mlennert):
Replying to [comment:2 martinl]:
> Any opinion / feedback? Thanks.
Both region-specific bins and map-specific bins can be useful. The latter
allow easier comparison between different subregions, whereas the former
allow getting the number of bins asked for in each subregion.
So, the ideal solution IMHO would be to have both. In the meantime, the
fact that bins are calculated on the entire map's value range should be at
least documented explicitly.
+1 Between the two options, I would prefer it to respect the region (following the common approach in GRASS). But I agree that having both options would even be better. The documentation now says that “analysis uses the current geographic region (g.region) and mask settings (r.mask)”. So the fact that does not respects this is an exception apparently (and it is an exception to the general GRASS GIS approach), which should indeed by very clearly documented.
···
On 14-09-15 11:39, GRASS GIS wrote:
#2625: r.stats's nsteps is not region-sensitive
--------------------------+-----------------------------
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.0.2
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.stats, nsteps
CPU: Unspecified | Platform: Unspecified
--------------------------+-----------------------------
Comment (by mlennert):
Replying to [comment:2 martinl]:
> Any opinion / feedback? Thanks.
Both region-specific bins and map-specific bins can be useful. The latter
allow easier comparison between different subregions, whereas the former
allow getting the number of bins asked for in each subregion.
So, the ideal solution IMHO would be to have both.
In the meantime, the
fact that bins are calculated on the entire map's value range should be at
least documented explicitly.