[GRASS-user] i.segment.stats memory usage error
Moritz Lennert
mlennert at club.worldonline.be
Mon Nov 7 05:25:33 PST 2016
On 07/11/16 08:16, Pietro wrote:
> On Fri, Nov 4, 2016 at 3:51 PM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at club.worldonline.be>> 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
More information about the grass-user
mailing list