I just noticed that r.bioclim rounds the values, resulting in an integer map. I realize that the toutscale parameter can be set to get the required precision. Still, would it be an idea to mention more explicitly in the help file that the output files are integer and that in order to ensure sufficient precision, one needs to set the toutscale? Perhaps also something to mention, only scale factor of a power of 10 make sense (given the rounding of the final results)?
A suggestion is (added text in italic) :
If the input temperatures are scaled, e.g. as input = Celsius *
10, then the inscale option must be set to 10. Similarly, the
outscale option is by default 10, and temperature output is
in this case Celsius * 10. Exceptions are BIO3, BIO4, and BIO15
which are always multiplied with 100 (see below). *The reason *
*outscale is set to 10 by default is that the output layers*
*are integers and a scaling factor of 10 (or higher power of 10)*
*ensures a minimum precision.*
p.s. why are all maps rounded? For me that would be something to leave up to the user (or to make integer maps as output optional)?
And let me take the opportunity to wish you all a happy 2016
On Sat, Jan 2, 2016 at 3:14 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
Hi Markus
I just noticed that r.bioclim rounds the values, resulting in an integer
map. I realize that the toutscale parameter can be set to get the required
precision. Still, would it be an idea to mention more explicitly in the help
file that the output files are integer and that in order to ensure
sufficient precision, one needs to set the toutscale? Perhaps also something
to mention, only scale factor of a power of 10 make sense (given the
rounding of the final results)?
A suggestion is (added text in italic) :
I have added your suggestion in slightly modified form in r67798.
...
p.s. why are all maps rounded? For me that would be something to leave up to
the user (or to make integer maps as output optional)?
I guess for the compatibility with WORLDCLIM (have added that, too).
The other Markus will know better
On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Jan 2, 2016 at 3:14 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
> Hi Markus
>
> I just noticed that r.bioclim rounds the values, resulting in an integer
> map. I realize that the toutscale parameter can be set to get the
required
> precision. Still, would it be an idea to mention more explicitly in the
help
> file that the output files are integer and that in order to ensure
> sufficient precision, one needs to set the toutscale? Perhaps also
something
> to mention, only scale factor of a power of 10 make sense (given the
> rounding of the final results)?
>
> A suggestion is (added text in italic) :
I have added your suggestion in slightly modified form in r67798.
Great
...
> p.s. why are all maps rounded? For me that would be something to leave
up to
> the user (or to make integer maps as output optional)?
I guess for the compatibility with WORLDCLIM (have added that, too).
The other Markus will know better
I still think it is really preferable to not round these numbers, but leave
that to the user (perhaps include it as an option though). But in any case,
the text you added makes things more explicit / clear, which is most
important.
On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler <neteler@osgeo.org> wrote:
I guess for the compatibility with WORLDCLIM (have added that, too).
The other Markus will know better
I still think it is really preferable to not round these numbers, but leave that to the user (perhaps include it as an option though). But in any case, the text you added makes things more explicit / clear, which is most important.
On Wed, Feb 10, 2016 at 1:16 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Feb 10, 2016 12:03 PM, "Paulo van Breugel" <p.vanbreugel@gmail.com>
wrote:
> On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler <neteler@osgeo.org>
wrote:
>> I guess for the compatibility with WORLDCLIM (have added that, too).
>> The other Markus will know better
>
> I still think it is really preferable to not round these numbers, but
leave that to the user (perhaps include it as an option though). But in any
case, the text you added makes things more explicit / clear, which is most
important.
Python patches are welcome!
I could give that a try (wasn't difficult if I remember well), but I rather
first hear from Markus (the other whether he thinks it is something
that could/should be changed
On Wed, Feb 10, 2016 at 2:39 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
On Wed, Feb 10, 2016 at 1:16 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Feb 10, 2016 12:03 PM, "Paulo van Breugel" <p.vanbreugel@gmail.com>
wrote:
> On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler <neteler@osgeo.org>
> wrote:
>> I guess for the compatibility with WORLDCLIM (have added that, too).
>> The other Markus will know better
>
> I still think it is really preferable to not round these numbers, but
> leave that to the user (perhaps include it as an option though). But in any
> case, the text you added makes things more explicit / clear, which is most
> important.
Python patches are welcome!
I could give that a try (wasn't difficult if I remember well), but I rather
first hear from Markus (the other whether he thinks it is something that
could/should be changed
It could be changed, but I am not sure if it is worth the trouble.
When I wrote the module, I used bioclim from worldclim as test suite
which also uses integer. That means when using worldclim as input, the
default settings produce output identical to worldclim's bioclim maps.
Instead of leaving the rounding to the user, you could also leave the
conversion to fp to the user. I prefer to have rounding to integer
because 1) users will not get the false impression of high accuracy
with floating point values, 2) it saves a lot of disk space.
On Sun, Feb 21, 2016 at 12:20 PM, Markus Metz <markus.metz.giswork@gmail.com
wrote:
On Wed, Feb 10, 2016 at 2:39 PM, Paulo van Breugel
<p.vanbreugel@gmail.com> wrote:
>
>
> On Wed, Feb 10, 2016 at 1:16 PM, Markus Neteler <neteler@osgeo.org>
wrote:
>>
>>
>> On Feb 10, 2016 12:03 PM, "Paulo van Breugel" <p.vanbreugel@gmail.com>
>> wrote:
>> > On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler <neteler@osgeo.org>
>> > wrote:
>> >> I guess for the compatibility with WORLDCLIM (have added that, too).
>> >> The other Markus will know better
>> >
>> > I still think it is really preferable to not round these numbers, but
>> > leave that to the user (perhaps include it as an option though). But
in any
>> > case, the text you added makes things more explicit / clear, which is
most
>> > important.
>>
>> Python patches are welcome!
>
>
> I could give that a try (wasn't difficult if I remember well), but I
rather
> first hear from Markus (the other whether he thinks it is something
that
> could/should be changed
It could be changed, but I am not sure if it is worth the trouble.
When I wrote the module, I used bioclim from worldclim as test suite
which also uses integer. That means when using worldclim as input, the
default settings produce output identical to worldclim's bioclim maps.
Instead of leaving the rounding to the user, you could also leave the
conversion to fp to the user. I prefer to have rounding to integer
because 1) users will not get the false impression of high accuracy
with floating point values,2) it saves a lot of disk space.
OK, that is clear. I think the most important is that this is now clearly
explained in the manual pages.
That might be a reasons to think about a general, unified option regarding integer, floating point or double output.
Markus`s solution in r.bioclim could be very useful in other modules too. Esp. those that produce a lot of data and default to double. Here I think e.g. about r.sun which can produce a lot of layers, where the digits often are insignificant. I know such an option is not especially easy to implement and would require quite some changes.
However, maybe it is worth it to think in that direction e.g. for GRASS 8?
On Wed, Feb 10, 2016 at 10:26 AM, Markus Neteler <neteler@osgeo.org>
wrote:
I guess for the compatibility with WORLDCLIM (have added that, too).
The other Markus will know better
I still think it is really preferable to not round these numbers, but
leave that to the user (perhaps include it as an option though). But in any
case, the text you added makes things more explicit / clear, which is most
important.
Python patches are welcome!
I could give that a try (wasn’t difficult if I remember well), but I rather
first hear from Markus (the other whether he thinks it is something that
could/should be changed
It could be changed, but I am not sure if it is worth the trouble.
When I wrote the module, I used bioclim from worldclim as test suite
which also uses integer. That means when using worldclim as input, the
default settings produce output identical to worldclim’s bioclim maps.
Instead of leaving the rounding to the user, you could also leave the
conversion to fp to the user. I prefer to have rounding to integer
because 1) users will not get the false impression of high accuracy
with floating point values,2) it saves a lot of disk space.
OK, that is clear. I think the most important is that this is now clearly explained in the manual pages.
whether he thinks it is something