On 06/10/14 17:19, Vaclav Petras wrote:
On Mon, Oct 6, 2014 at 10:52 AM, Markus Neteler <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Oct 6, 2014 at 4:05 PM, Vaclav Petras <[email protected]
<mailto:[email protected]>> wrote:
> On Mon, Oct 6, 2014 at 9:39 AM, Anna Petrášová <[email protected]
<mailto:[email protected]>>
>> On Mon, Oct 6, 2014 at 9:07 AM, Pietro <[email protected]
<mailto:[email protected]>> wrote:
>>> Perhaps we could add two new functions, like: rmin and rmax that stay
>>> for range min and range max that give this information, do you think
>>> could be useful?
>>
>> Yes, definitely, I was also missing this functionality.
...
> This should strictly work on computational region.
Yes (r.univar contains the respective code).
This would mean moving this code to the library.
I'm not going to stand in the way of those who really want to implement
this, but why is this necessary ?
eval(r.univar -g $map)
r.mapcalc new=old/$max
(and equivalent in other programming languages) works perfectly. Just
thinking that there are other priorities and that we are going further
from the KISS principle...
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
