Hamish wrote:
For average, median, variance, standard deviation and interspersion,
the output should always be floating-point (although I'm not entirely
certain about median).
why not for median? is there any other way to deal with even number of
values in the list? if value will often
Markus Metz wrote:
I would rather have DCELL output all the times, maybe keep the maptype
for min, max?
Retaining the type for mode, sum and range would also make sense, as
the result will always be an integer for integer inputs.
For diversity, the result is always an integer even for
Glynn:
For average, median, variance, standard deviation and interspersion,
the output should always be floating-point (although I'm not entirely
certain about median).
why not for median? is there any other way to deal with even number of
values in the list? if value will often be 0.5 then
Allar Haav wrote:
I noticed today that average method in r.neighbours gives an incorrect
value. Let me give you an example:
3) Judging from previous steps, it should be only logical that the
output raster has values from 0 to 1. However it seems that 0.5 has been
added:
When the
Right, explanation makes sense.
Also, thanks for the quick fix. Much appreciated!
Allar
On 11/07/2013 12:30, Glynn Clements wrote:
When the output is an integer map, the result of the average, variance
and stddev methods is supposed to be rounded to the nearest integer
(rather than towards
On Thu, Jul 11, 2013 at 1:30 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Allar Haav wrote:
I noticed today that average method in r.neighbours gives an incorrect
value. Let me give you an example:
3) Judging from previous steps, it should be only logical that the
output raster has
Hi,
I noticed today that average method in r.neighbours gives an incorrect
value. Let me give you an example:
1) I have a raster soiltype1 consisting of 0's and 1's:
r.univar map=soiltype1@soil percentile=100
total null and non-null cells: 3500
total null cells: 10299386
Of the non-null
