On 07/11/16 08:16, Pietro wrote:
On Fri, Nov 4, 2016 at 3:51 PM, Moritz Lennert
<[email protected] <mailto:[email protected]>> wrote:
On 04/11/16 12:24, James Duffy wrote:
Moritz, have you seen the reply on the bug rep?
https://trac.osgeo.org/grass/ticket/3197
<https://trac.osgeo.org/grass/ticket/3197>
<https://trac.osgeo.org/grass/ticket/3197
<https://trac.osgeo.org/grass/ticket/3197>>
Do you think the alternative r.univar2 could be used in your
function?
Yes, I saw the answer. As Pietro said, r.univar2 was not ported to
grass7 and I don't have time for that now. I also don't really know
why the module is faster, but ideally the changes should be merged
into r.univar instead of creating a second, similar module.
r.univar2 was developed for grass7. Anyway it seems that now there are
better tools for this task.
Sorry, I read too quickly over your phrase "It was not backported to
trunk" in the ticket. So, it was developed for grass7.0, but not for trunk ?
@Pietro: could you maybe explain how you changed the logic to see
how difficult it would be to integrate this into r.univar ?
It starts looking how many zones exists and how many cells per zone are
present in the region. In this way it allocates only what is needed, and
using the extended statistics free the memory after each zone is done.
Probably this free rule should be moved also in the case user is not
computing the extending statistics. In this way I was able to
characterize the zones of the i.segment module.
Thanks for the explanation !
Moritz
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
