[GRASS-dev] r.series method=minimum yields float map when integer maps are used as input

Hi devs,

If I use a series of integer type maps as input to t.rast.series or r.series and select minimum as method, the output is a floating point map. I would have thought that if the input are integers then output should be integer as well. I realized when I made a plot of the map and got a smooth legend instead of integer numbers.

Here an example:

{{{

for i in seq 1 6 ; do r.mapcalc expression=“map${i} = ${i}” ; done
r.info map1 <<-- CELL
r.series input=g.list rast pat=map* sep=, method=minimum output=test_min
r.info test_min <<-- DCELL
}}}

Is this an expected behaviour?

best,
Vero

* Veronica Andreo <veroandreo@gmail.com> [2018-08-25 18:17:51 +0200]:

Hi devs,

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Here an example:

{{{
for i in `seq 1 6` ; do r.mapcalc expression="map${i} = ${i}" ; done
r.info map1 <<-- CELL
r.series input=`g.list rast pat=map* sep=,` method=minimum output=test_min
r.info test_min <<-- DCELL
}}}

Is this an expected behaviour?

Vero,

just guessing,

maybe it's similar to my question about 'count' in `r.stats.zonal` [0]:
use of DCELL allows for integers larger than CELL (32-bit).

Nikos

[0] https://lists.osgeo.org/pipermail/grass-dev/2018-August/089197.html

Hi Nikos,

El dom., 26 ago. 2018 13:16, Nikos Alexandris <nik@nikosalexandris.net> escribió:

Hi devs,

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Here an example:

{{{
for i in seq 1 6 ; do r.mapcalc expression=“map${i} = ${i}” ; done
r.info map1 <<-- CELL
r.series input=g.list rast pat=map* sep=, method=minimum output=test_min
r.info test_min <<-- DCELL
}}}

Is this an expected behaviour?

Vero,

just guessing,

maybe it’s similar to my question about ‘count’ in r.stats.zonal [0]:
use of DCELL allows for integers larger than CELL (32-bit).

Thanks for your answer. I can understand the storage of ‘count’ output as double since the count can exceed the length of input data type. But why minimum? If I input integer data, the minimum of a set of integer numbers should be integer, no? How can it exceed the CELL range if it is the minimum of that range?

Just thinking out loud

Cheers,
Vero

[0] https://lists.osgeo.org/pipermail/grass-dev/2018-August/089197.html

Le Dimanche 26 août 2018, Veronica Andreo a écrit :

Hi Nikos,

El dom., 26 ago. 2018 13:16, Nikos Alexandris <nik@nikosalexandris.net>
escribió:

> * Veronica Andreo <veroandreo@gmail.com> [2018-08-25 18:17:51 +0200]:
>
> >Hi devs,
> >
> >If I use a series of integer type maps as input to t.rast.series or
> >r.series and select minimum as method, the output is a floating point map.
> >I would have thought that if the input are integers then output should be
> >integer as well. I realized when I made a plot of the map and got a smooth
> >legend instead of integer numbers.
> >
> >Here an example:
> >
> >{{{
> >for i in `seq 1 6` ; do r.mapcalc expression="map${i} = ${i}" ; done
> >r.info map1 <<-- CELL
> >r.series input=`g.list rast pat=map* sep=,` method=minimum output=test_min
> >r.info test_min <<-- DCELL
> >}}}
> >
> >Is this an expected behaviour?
>
> Vero,
>
> just guessing,
>
> maybe it's similar to my question about 'count' in `r.stats.zonal` [0]:
> use of DCELL allows for integers larger than CELL (32-bit).

Thanks for your answer. I can understand the storage of 'count' output as
double since the count can exceed the length of input data type. But why
minimum? If I input integer data, the minimum of a set of integer numbers
should be integer, no? How can it exceed the CELL range if it is the
minimum of that range?

Just thinking out loud

Me too: among a long 'series' of minimums, maybe an extreme min?

:slight_smile:

Maybe a silly thought.

Nikos

Veronica Andreo wrote:

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Is this an expected behaviour?

The type of the output map is independent of the inputs, determined
solely by the method. The count, diversity, min_raster and max_raster
methods generate integer maps; all other methods generate
floating-point maps.

It probably wouldn't be particularly involved to add another flag to
the method table to indicate that a particular method will always
produce an integer result for integer inputs.

Also, the use of weights= forces the output to floating-point even if
the method doesn't actually support the use of weights.

--
Glynn Clements <glynn@gclements.plus.com>

Thanks for the explanation, Glynn :slight_smile:

El mar., 28 ago. 2018 a las 11:01, Glynn Clements (<glynn@gclements.plus.com>) escribió:

Veronica Andreo wrote:

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Is this an expected behaviour?

The type of the output map is independent of the inputs, determined
solely by the method. The count, diversity, min_raster and max_raster
methods generate integer maps; all other methods generate
floating-point maps.

It probably wouldn’t be particularly involved to add another flag to
the method table to indicate that a particular method will always
produce an integer result for integer inputs.

Also, the use of weights= forces the output to floating-point even if
the method doesn’t actually support the use of weights.


Glynn Clements <glynn@gclements.plus.com>

Sorry, I pressed send earlier than intended…

El mar., 28 ago. 2018 a las 13:45, Veronica Andreo (<veroandreo@gmail.com>) escribió:

Thanks for the explanation, Glynn :slight_smile:

El mar., 28 ago. 2018 a las 11:01, Glynn Clements (<glynn@gclements.plus.com>) escribió:

Veronica Andreo wrote:

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Is this an expected behaviour?

The type of the output map is independent of the inputs, determined
solely by the method. The count, diversity, min_raster and max_raster
methods generate integer maps; all other methods generate
floating-point maps.

It probably wouldn’t be particularly involved to add another flag to
the method table to indicate that a particular method will always
produce an integer result for integer inputs.

Is this worth an enhancement ticket? I do not know how to implement any of this myself.

thanks again,
Vero

On Tue, Aug 28, 2018 at 1:49 PM Veronica Andreo <veroandreo@gmail.com> wrote:

Sorry, I pressed send earlier than intended…

El mar., 28 ago. 2018 a las 13:45, Veronica Andreo (<veroandreo@gmail.com>) escribió:

Thanks for the explanation, Glynn :slight_smile:

El mar., 28 ago. 2018 a las 11:01, Glynn Clements (<glynn@gclements.plus.com>) escribió:

Veronica Andreo wrote:

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Is this an expected behaviour?

The type of the output map is independent of the inputs, determined
solely by the method. The count, diversity, min_raster and max_raster
methods generate integer maps; all other methods generate
floating-point maps.

It probably wouldn’t be particularly involved to add another flag to
the method table to indicate that a particular method will always
produce an integer result for integer inputs.

Is this worth an enhancement ticket? I do not know how to implement any of this myself.

Please try trunk r73206.

Markus M

thanks again,
Vero


grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

El mié., 29 ago. 2018 a las 22:37, Markus Metz (<markus.metz.giswork@gmail.com>) escribió:

On Tue, Aug 28, 2018 at 1:49 PM Veronica Andreo <veroandreo@gmail.com> wrote:

Sorry, I pressed send earlier than intended…

El mar., 28 ago. 2018 a las 13:45, Veronica Andreo (<veroandreo@gmail.com>) escribió:

Thanks for the explanation, Glynn :slight_smile:

El mar., 28 ago. 2018 a las 11:01, Glynn Clements (<glynn@gclements.plus.com>) escribió:

Veronica Andreo wrote:

If I use a series of integer type maps as input to t.rast.series or
r.series and select minimum as method, the output is a floating point map.
I would have thought that if the input are integers then output should be
integer as well. I realized when I made a plot of the map and got a smooth
legend instead of integer numbers.

Is this an expected behaviour?

The type of the output map is independent of the inputs, determined
solely by the method. The count, diversity, min_raster and max_raster
methods generate integer maps; all other methods generate
floating-point maps.

It probably wouldn’t be particularly involved to add another flag to
the method table to indicate that a particular method will always
produce an integer result for integer inputs.

Is this worth an enhancement ticket? I do not know how to implement any of this myself.

Please try trunk r73206.

Works as expected :slight_smile:

Thanks a million, Markus!

Cheers,

Vero