Hi Glynn, Glynn Clements wrote: > In theory, the same logic could be used for anything which uses lib/stats, > i.e. r.neighbors, r.resamp.stats, r.series, r.series.interp, r3.neighbors, > and v.vect.stats.
Thanks for your reply, and sorry that mine took a while. Provided that I neither have an idea how much work it would be to implement that in a more general approach, nor the competence to do so, would you mind if I open an enhancement request in trac? I would consider it as a reasonable improvement, as it would help to both avoid that maps unnecessarily occupy hard disk space and speed up subsequent operations as well as it would spare users who care about the storage type from running a r.mapcal int() / float() and g.remove after one of the commands you named (maybe also r.in.xyz?). Finally, other modules like t.rast.aggregate would benefit from such an improvement as well. May be having a "type-option" in the named modules, like in r.in.xyz could be another solution which also covers the FCELL/DCELL difference? All the best, Stefan _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
