[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