Open landam opened 5 years ago
Comment by neteler on 3 Jun 2014 07:13 UTC Original discussion link (since nabble servers tend to change their name over time):
http://lists.osgeo.org/pipermail/grass-dev/2014-April/068247.html
Comment by neteler on 5 May 2016 14:08 UTC Milestone renamed
Comment by neteler on 28 Dec 2016 15:04 UTC Ticket retargeted after milestone closed
Modified by @landam on 5 May 2017 20:40 UTC
Comment by @landam on 1 Sep 2017 20:28 UTC All enhancement tickets should be assigned to 7.4 milestone.
Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed
Modified by neteler on 12 Jun 2018 20:48 UTC
Comment by @landam on 25 Sep 2018 16:51 UTC All enhancement tickets should be assigned to 7.6 milestone.
Comment by @landam on 25 Jan 2019 21:07 UTC Ticket retargeted after milestone closed
Reported by sbl on 3 Jun 2014 06:40 UTC Recently Glynn implemented a logic for assigning the moste suitable output type (integer / float) to maps produced in r.neighbors.
Basically, all modules which use lib/stats would benefit from such a logic, like r.resamp.stats, r.series, r.series.interp, https://trac.osgeo.org/grass/changeset/3.neighbors, v.vect.stats and possibly r.in.xyz, as well all modules which are based on them (e.g. t.rast.aggregate).
Implementing Glynns logic on library level would help to both avoid that maps produced with these modules 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 r.mapcalc int() / float() and g.remove after one of the named commands.
Not sure how FCELL/DCELL differences for float output could/should be tackled...
For the original discussion see: http://osgeo-org.1560.x6.nabble.com/G7-r-neighbors-changes-data-type-from-CELL-to-DCELL-tt5134367.html
Migrated-From: https://trac.osgeo.org/grass/ticket/2321