<div dir="ltr"><div>Sorry, I pressed send earlier than intended...</div><div><br></div><div class="gmail_quote"><div dir="ltr">El mar., 28 ago. 2018 a las 13:45, Veronica Andreo (<<a href="mailto:veroandreo@gmail.com">veroandreo@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the explanation, Glynn :)<br></div><br><div class="gmail_quote"><div dir="ltr">El mar., 28 ago. 2018 a las 11:01, Glynn Clements (<<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Veronica Andreo wrote:<br>
<br>
> If I use a series of integer type maps as input to t.rast.series or<br>
> r.series and select minimum as method, the output is a floating point map.<br>
> I would have thought that if the input are integers then output should be<br>
> integer as well. I realized when I made a plot of the map and got a smooth<br>
> legend instead of integer numbers.<br>
<br>
> Is this an expected behaviour?<br>
<br>
The type of the output map is independent of the inputs, determined<br>
solely by the method. The count, diversity, min_raster and max_raster<br>
methods generate integer maps; all other methods generate<br>
floating-point maps.<br>
<br>
It probably wouldn't be particularly involved to add another flag to<br>
the method table to indicate that a particular method will always<br>
produce an integer result for integer inputs.<br></blockquote></div></blockquote><div><br></div><div>Is this worth an enhancement ticket? I do not know how to implement any of this myself.</div><div><br></div><div>thanks again,</div><div>Vero<br></div></div></div>